What is the Object Transporter tool in Workday?

If you've dealt with conventional ERP systems before switching to the Workday cloud, you know how difficult it can be to move artifacts from one instance to another. Creating LDTs, writing shell files, executing commands from the UNIX shell, keeping the migration sequence right, and so on.

Fortunately, when it comes to object migration, Workday makes it a lot simpler. We have a new function called object transporter in Workday release 26 that works like magic. I recently used this method and was very pleased with its performance.

Previously, there were two ways to migrate artifacts in Workday, each with its own set of advantages and disadvantages.

Both Workday collaborators and clients may use Workday Implementation Tools. This is to effectively customize their programs to meet their requirements and desires. The Object Transporter is one of the many instruments available in the consumer central guide. These instruments assist in the construction of tenants as well as serving as services during the development process.

Object transporter

The Object Transporter is a Workday tool with migrating capabilities. Thus, it aids in the relocation of specific objects and their dependencies between two separate tenants. It also aids in the execution of various types of analysis, such as dependence, prerequisite, and differential analysis.

Benefits of Object Transporter

• It's a user-friendly tool with a variety of functionality that even a first-time user can manage.
• Instances are fully automatic, so they don't require any manual effort from the resident.
• Before jumping to the performance of OX migration, it conducts different types of analysis such as dependency testing, prerequisite checking by searching for existing data in the tenant, and diff analysis.
• It aids in the relocation of instances and makes the process even more straightforward.
• Via the construction of a configuration kit, OX may be used to migrate a single instance or a group of instances. However, because of the 45-minute rough time-out, it is often preferable to work on massive or complex structures in smaller groups. The success of the OX may be harmed if there are other loads present inside the occupant. As a result, it's important to be aware of the tenant's other procedures and to understand the time-outs encountered during relocation so that the setup packages can be broken down into smaller ones for the next time.

A Single Instance Migration is a method of migrating a single instance of a database.

The development of a user-based protection community is required to use the object transporter. It is suggested that you call it Migration Administrator by Workday. After this category is created, it must be applied to the special OX services or the non-implementer domains to create a policy for both. To begin, go to the launch object migration page and pick your target tenant before clicking start. Take a diff report if possible after logging into your target resident, or merge the new object directly if there are no collisions. To begin loading the instance into the specified tenant, select the save option.

In the extended view of the folder, information about the parent object and dependent objects will be shown. The source and goal tenants will also view information about report description and configuration values. You may use diff reports to test certain dependent items by clicking on them and doing the analysis. If there are major discrepancies, go back to the original occupant to settle them. If the transfer is efficient, the object will be available in the destination tenant.

Migration Configuration Packages Development and Migration

It's usually a good idea to split larger setup packages into smaller ones if other loading processes are running in the tenant or if you run into a time-out during a migration. You can move a group of around 100 objects in a single configuration box. Using the ‘add implementation type' option, you can add one or more implementation styles to the kit.

You can modify and filter the implementation rules after choosing the implementation type by defining requirements. You can filter an application form based on situation rules and adjust instances for it. After you've made the improvements you want, you should save the setup kit and get ready to migrate it.

Stages of migration

The first few stages of migration are similar to those of instance migration. However, after inspecting the contents of the configuration kit or viewing the diff for objects, you will make adjustments. If there are some variations in values between the source and goal tenants, go back to the source tenant to fix them before migrating again.

You will be able to check any discrepancies before migrating or merging the values between tenants after choosing the ‘migrate' option. Finally, you should apply the kit for finalization and migration to your preferred tenant. The migrated objects would be available to the target tenant in no time if the process is efficient. It's important to keep in mind that the object transporter can't move transactional or reference data. Only the elements, their cases, and their dependencies may be transferred.

Relocation

Furthermore, relocation between preview and non-preview tenants should be avoided because there is a high chance of various gaps in web systems and data templates. You can learn more by enrolling in Workday Training courses provided by reputable organizations which offer a comprehensive HCM course in this framework. The object transporter tool is used not only in Workday HCM, but also in other Workday modules such as Finance, Studio, Integration, BIRT, Reporting, and so on.

Ox limitations

Based on my own experiences, I've identified some of OX's known flaws and weaknesses.

Case in point:

As implementers, we're using OX in a project for tenant migration. In most cases, we use the Bypass SSO alternative. There's a plan now to give client users access to OX, and in that case, SSO will be preferable. However, when evaluated, SSO did not work properly.

As you use SSO (and the Bypass SSO alternative is unchecked), you are brought to the target tenant's home page instead of the next measures.

Cause:

This reduced support for target tenants allowed with SSO is due to an existing constraint at the Workday infrastructure stage.

As a result, migrations from Implementation to Implementation and Implementation to Sandbox Tenants will be routed to the target's home screen if the target is allowed with SSO.

Workday is mindful of this drawback, and the latest solution is to use an account in the target tenants that will circumvent SSO. As a result, SSO is currently unavailable for OX migrations in impl to impl and impl to sandbox tenants. This framework is always looking at possible options at the moment. There is no current ETA for the solution since it is a current system constraint that they are attempting to solve.

Final thoughts

The object transporter tool is used not only in Workday HCM, but also in other Workday modules such as Finance, Studio, Integration, BIRT, Reporting, and so on. Workday Training is needed to gain a thorough understanding of this method. Workday HCM Training is available to help you learn about the functionality and techniques in Workday, as well as the fundamentals. There are also specialized modules in HCM that are useful for a W’Day Consultant. As a Workday professional specialist, it is required that you learn all of the tenant deployment methods and develop expertise over them through realistic project practice.

I am a Digital Marketing Analyst working in cynix it