Migrate Configuration Changes with Configuration Change Tracker

Administrator Guide

Download PDF

Set up access to migrate Advance configuration packages on the

Maintain Access to Customer Central Tooling

task.

See Manage Access to Customer Central Implementation Tools.

Set up access to Customer Central Object Transporter migration.

See Steps: Configure Access to Customer Central and Object Transporter.

Set up access to Configuration Change Tracker

See Configure Security for Configuration Change Tracker.

Use

Configuration Change Tracker

migration to synchronize configurations between tenants. To migrate, you start in

Configuration Change Tracker

and create a report of configuration changes made by specific users and in the timeframes you specify. This report is your change list, from which you create a configuration package. You can modify the package until you have only the instances you want to migrate.

Before Change Tracker redirects you to Customer Central and Object Transporter, you can run validation checks to resolve possible missing IDs, ID conflicts, or exception errors. In Object Transporter, you can complete the migration process, with much of the work already done by Configuration Change Tracker.

Access the

Configuration Change Tracker

task.

Depending on your security permissions, you can:

View and create reports of your own changes,

View and create reports of others' changes.

Create and edit your own Advanced configuration packages.

Edit others' Advanced configuration packages.

Migrate your own Advanced configuration packages.

Migrate others' Advanced configuration packages.

On the

Configuration Change Tracker

page, create a change list of the configuration changes to migrate:

Option	Description
From Moment To Moment	Select the date and time range for the configuration changes you want to capture.
Filtered by Users	Select 1 or more users who made the changes you want to capture.
Include Changes Made via Web Services	Select this check box if any of the selected users made configuration changes by a Workday SOAP web service.
Include Changes Made via REST	Select this check box if any of the selected users made configuration changes by a Workday REST service.

You can further filter your change list by implementation type in

Additional Filters

, or you can select an existing report from the

Latest Reports

Workday automatically saves your change list as a

Configuration Change Tracker

report.

Click

Refresh

or wait for the report to populate.

On the

Report Criteria

page for your report, review the change list for the users and timeframe you selected.

Click

View Changes

for an instance to review its attribute details. You can package instances listed on the

Ready to Migrate

tab without further action.

Workday doesn't include instances on the

Not Ready to Migrate

tab in configuration packages. You must manually add them when you modify the package on the

Configure Package Instances

page, although most

Not Ready to Migrate

instances don't make sense to add. Examples: Do Not Use (DNU) or deleted instances.

You can view a complete list of reasons why instances display on the

Not Ready to Migrate

tab.

See Concept: Configuration Change Tracker.

Click

Create Configuration Package

to create an Advanced configuration package of the instances listed on the

Ready to Migrate

tab.

You can rename the package or add a description or an external change request ID.

Select to include all instances, or only new or modified ones:

Option	Description
All Instances	Includes all instances from the Ready to Migrate tab of Configuration Change Tracker and matches the previous behavior. This is the default selection.
New Instances Only	Includes only the new instances created in the specified date range by the selected users. Selecting this option creates a targeted package, enabling you to more efficiently synchronize configurations between tenants and lower the risk of errors that can result from manually editing large packages.
Modified Instances Only	Includes only the instances edited in the specified date range by the selected users. Selecting this option creates a targeted package, enabling you to more efficiently synchronize configurations between tenants and lower the risk of errors that can result from manually editing large packages.

When Object Transporter migrates Advanced configuration packages, it migrates only the instances that you select for the package. It doesn't add other dependent instances after migration starts, as it does with standard configuration packages. This method narrows the migration scope to known instances, ensuring a less problematic migration.

When ready, click

Configure Package Instances

to create the package.

On the

Configure Package Instances

page, add or remove instances and implementation types until you have the only instances that you want to migrate.

If you’ve identified any instances from the

Not Ready to Migrate

tab that you want to add, do so here.

To add or remove an instance, click

Edit Instances

Add Instances

Edit Instances

Remove Instances

and select 1 or more instances to add or remove.

To add or remove an implementation type, click

Edit Implementation Types

Add Implementation Type(s)

Edit Implementation Types

Remove Implementation Type(s)

and select 1 or more types to add or remove.

Click

Save and Continue

Workday updates the Advanced configuration package with your changes.

On the

Review and Prepare for Migration

page, complete validation checks:

Click

Run Blank Reference IDs

to list instances with a missing reference ID.

Click

View and Fix Errors

to automatically populate the blank reference IDs. Workday assigns no reference IDs to some instances and therefore doesn't report them in this validation check.

Click

Run System Generated Ref IDs

to list instances with auto generated numeric sequences for reference IDs.

While these aren't incorrect, they may cause overwrite issues when you migrate to a tenant that has the same system generated reference ID for another instance that isn’t a match. Change these reference IDs only if you are concerned that migration may:

Overwrite an instance in the target tenant unintentionally.

Create an instance in the target tenant instead of modifying one.

Click

Run Exception Audits

to run these audit reports on the instances on your package:

Business Process Exception

Security Exception

Calculation Exception

Calculated Field Exception

Integration Exception

Custom Report Exceptio

Benefits Condition Rule Exception

Condition Rule Exception

Organization Exception

Organization Type Exception

Position Group Exception

Report Specific Calculated Field Exception

Worklet Mappings Exception

Payroll Exception

Click

Prepare for Migration

Workday redirects you to Customer Central.

Click

Launch Object Transporter in Customer Central

to sign into the Customer Central tenant and Object Transporter workflow as a Customer Central administrator or user.

On the

Migrate with Object Transporter

page, select the

Target Tenant

Select the

Include Translations?

checkbox to include translated attribute values for instances in your package that contain them.

Because you're migrating an Advanced configuration package from a

Configuration Change Tracker

report, Workday lists

Dependency Support

for the package as manual. This means that Object Transporter doesn't automatically add dependencies to your package after migration starts, as it does with standard configuration packages. You can manually add dependent instances to resolve missing ones if Object Transporter later reports them in the

Pre-Migration Diff

report. Advanced configuration packages don't usually have missing or mismatched dependent instances, however, unless instances in the package have been updated or incorrectly configured since you created the package.

Click

On the

Pre-Migration Status

page, click

Refresh

or wait for Workday to complete the premigration check of the configuration data in scope for migration.

Some instances have prerequisites that must exist in the target tenant for migration to succeed. Example: A calculated field. When Workday:

Finds missing prerequisites, it generates a

Pre-Migration Check

report.

Finds no missing prerequisites, it skips the

Pre-Migration Check

report and generates a

View Pre-Migration Diff

report.

If Workday displays the

Diff Report Not Generated

page, click

View Pre-Migration Check Report

to review the

Errors

table.

The table lists missing prerequisites that you must resolve before migration can proceed. Workday flags a prerequisite as missing if it has:

No corresponding instance on the target tenant.

A missing Reference ID.

A mismatched Reference ID.

You must resolve the first 50 prerequisites listed in the table before Workday can identify and display any additional issues. As you resolve missing prerequisites, ensure Reference IDs match across both tenants.

Determine the resolution path for missing prerequisites and resolve unmappable prerequisites.

Review the

Non Mappable

and

Map to Instance in Target (optional)

columns to identify the necessary fix for each listed prerequisite:

If the

Non Mappable

column is Yes, sign in to the target tenant and manually resolve the issue:

Missing instance: Create the instance in the target tenant and ensure the Reference ID matches the source.

Missing or mismatched ID: If the instance exists, add or update the Reference ID to match the source.

If the

Map to Instance in Target (optional)

column displays a

Map Instance

button, you can map the instance through tailored loading, or you can resolve the prerequisite manually like a non mappable instance. For tailored loading, go to the next step.

If the

Non Mappable

column is empty, no action is necessary.

For WD Setup migrations, you can only modify or map to existing target tenant instances.

Use tailored loading to automatically map an unmatched source instance to a compatible instance on the target tenant:

In the

Map to Instance in Target (optional)

column, click.

Map Instance

. You must have the Reference ID of a compatible instance on the target tenant to map to it.

Enter the Reference ID of a compatible instance on the target tenant and click

In the search results, select the check box for the compatible instance. If Workday displays multiple instances, select the one that is the same implementation type and most compatible with the source.

Click

Apply Mapping

(Optional) To view details of the mapped instance, click the link in the

Mapping to

column.

(Optional) To delete a mapping, click

Remove

After addressing the prerequisites through manual updates or mapping:

Click

Rescan Target

if you updated or mapped target instances.

Click

Retry Migration

if you updated the source tenant.

Once you resolve prerequisites, including any discovered after the initial 50, Workday generates and displays the

Pre-Migration Diff Report

page.

If you're migrating any instances with effective dates, click

Set Effective Date Strategy

On the

Set Date for Package

prompt, first select a strategy for all instances in the migration.

You can apply a default effective date of 01/01/1900 or manually select a date. If you’re migrating a single instance, any dependencies of the instance inherit the date you select here.

If an instance without an effective date has dependencies with effective dates, the dependencies inherit the date of migration as their effective date during the migration process.

You can always change effective dates after migration. You can also further refine your effective date strategy by selecting different dates for instances and dependencies individually, or as a group, by implementation type.

To apply different effective dates at the implementation type or instance level, click

Save and Continue Editing

To select a different effective date for all instances of an implementation type, select a date in the

Set Effective Date By Implementation Type

column.

To change the year, enter it directly in the field.

To change the effective date of 1 or more unique instances or dependencies, click

Set Effective Date by Instance

Select a new effective date for an instance in the

Set Effective Date by Instance

column.

Workday displays both instances and their dependencies as separate rows in the table. To change the year for an instance or dependent instance, enter the year directly in the field.

Some implementation types enable you to enter effective dates in the future. If you enter a future date, Object Transporter proceeds with the migration and reports any errors.

(Optional) If your package contains domain or business process security policies that differ from the corresponding policies on the target tenant, click

Edit Migration Behavior

and select a migration behavior for all or some of the modified security policies. Workday merges security policies by default unless you use this option to override security policies on the target tenant.

Workday only enables this option when it detects 1 or more modified security policies.

Option	Description
Merge (Recommended)	Default behavior. Combines permission-holding components such as security groups and roles from all modified source security policies with those in the corresponding target security policies. Merges are additive. Workday removes nothing, making it the safest option. Consider this option when you need to: Prioritize target tenant integrity. Migrate routine updates from a preview, sandbox, or development environments to production, where the goal is to introduce new configurations without disturbing existing ones. Mitigate the risk of inadvertently removing permissions or security groups that are critical for target tenant operation. Protect target-specific changes. Because Merge is non destructive by default, it reduces time spent on checking for potential overwrites, enabling you to focus more on verifying the additions.
Override	Replaces all security policies on the target tenant with the corresponding modified ones on the source tenant. When replacing, Workday discards the previous corresponding policies on the target tenant and implements only the modified security policies from the source tenant. Consider this option when you need to: Treat the source tenant as the authoritative source for security policies. Perform initial deployments or tenant refreshes. Intentionally replace target security policies fully. Ensure absolute consistency with the source. When you migrate a single instance, Workday replaces only the corresponding instance on the target tenant.
Manual Selection	Provides the most granular control, enabling you to review each modified security policy in the package individually. In the Migration Behavior per Instance column, select Merge or Override for each modified security policy. Consider this option when you need to: Handle complex migrations with diverse policy-specific needs. Address mixed requirements in a single package where different policies need different merge or override behavior applied to them. Operate in sensitive environments that demand meticulous control over each policy. Manage phased rollouts or policies handled by different teams. Achieve maximum precision and flexibility, tailoring action to each policy.

(Optional) To view the attributes for a modified instance, click

View Attribute Diff

to examine the individual attributes in the modified dependency object.

On the

Attribute Diff

page, Workday provides a status icon for each attribute of a

Modified

instance. The following table describes how Workday categorizes the differences between source and target attributes:

Attribute Status	Description
Change	Source and target attributes exist but aren’t identical. Migration overwrites the target attribute with the source attribute. If a source attribute belongs to a security policy instance, Workday adds it to the target tenant, unless you’ve selected the Override option when you edited migration behavior for security policies.
New	No attribute exists on the target tenant. Workday adds the source attribute to the target tenant.
Not Matching	Source and target attributes have different translation values. Workday merges the target translation value with the source translation value. Example: The source attribute has a Polish translation value and the target attribute has an English translation value. Migration adds the Polish translation value to the target attribute without changing the English value.
Removal	Attribute exists in target tenant but not in source. Migration removes the target attribute. Workday doesn’t assign Removal status to attributes that are part of domain or business process security policies.

When you've reviewed and understand the changes that migration will make to your target tenant, click

Proceed with Migration

to view a final summary of the instances to migrate.

Click

Start Migration

When the migration completes, click

View Post Migration Report

to see a summary of the changes in the target tenant.

Postmigration summary reports remain available for 2 years.

(Optional) On the

Post-Migration Report

page, click

Run Tenant Compare

to compare instances of implementation types between 2 tenants.

You can save the comparisons as

Tenant Compare

reports.