Skip to main content
Documentation
Documentation
Administrator Guide
Last Updated: 2026-04-03
Migrate Configuration Catalog Content with Object Transporter

Migrate Configuration Catalog Content with Object Transporter

Configure access and security for Customer Central and Object Transporter
You can use the
Tenant Dashboard
 in Customer Central or the
Configuration Catalog
 task to migrate a Configuration Catalog package or 1 or more instances of the package to your implementation or sandbox tenant.
After you select a target tenant and a configuration package in the catalog, Workday compares the instances you've selected in the catalog with the corresponding instances on the target tenant and launches a series of checks to prepare the migration.
If you're migrating reports, consider the downstream impact to edited reports in lower level tenants so that you don't migrate potential issues. Workday recommends that you validate reports after migrating them and consider the downstream impact to alerts and other processes.
When Workday completes the migration, you can view the
Post Migration
 report, or create a
Tenant Compare
 report to compare the differences between tenants after migration.
  1. Sign in to Customer Central as a Customer Central user or administrator.
  2. Access the
    Configuration Catalog
     task.
    The task is also available from the
    Tenant Dashboard
     worklet.
  3. From the
    Target Tenant
    prompt, select the tenant to which to migrate the Configuration Catalog content.
  4. Select a configuration package.
    You can click the
    Name
     column heading and filter to find your package.
  5. Click
    Configure Package Instances
    .
  6. Select 1 or more instances to migrate.
    To migrate the entire package, select the check box in the table header.
  7. 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.
  8. 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.
  9. 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:
    1. 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.
    2. 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.
    3. 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.
  10. Use tailored loading to automatically map an unmatched source instance to a compatible instance on the target tenant:
    1. 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.
    2. Enter the Reference ID of a compatible instance on the target tenant and click
      Search
      .
    3. 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.
    4. 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
        .
  11. 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.
  12. If your selected content in the Configuration Catalog contains instances with effective dates, click
    Set Effective Date Strategy
    .
    1. 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.
    2. To apply different effective dates at the implementation type or instance level, click
      Save and Continue Editing
      .
    3. 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.
    4. To change the effective date of 1 or more unique instances or dependencies, click
      Set Effective Date by Instance
      .
    5. 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.
  13. (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 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.
  14. Click
    Refresh
     or wait for Workday to display
    View Diff Report
     and click it.
    The
    Pre-Migration Diff Report
     page displays all instances in scope for migration, grouped by the implementation type of the top-level instance, and organized by migration behavior these tabs:
    Tab
    Description
    All Instances
    Lists all instances that your configuration package, or configuration extract contains. When you migrate a single instance, the tab displays 1 top level instance and any dependent objects it may contain.
    Modified
    Status icon: Orange
    Lists instances that exist in both the source and target tenants but differ because of a previous modification. During migration, Workday overwrites the target instance with the source instance unless it is a security policy.
    By default, Workday merges security policies from a source tenant with the corresponding security policy on the target tenant. You can change default behavior for security policy migration by using the
    Edit Migration Behavior
     option to overwrite the tenant security policy.
    New
    Status icon: Blue
    Lists instances that don't yet exist exist in the target tenant. During migration, Workday adds the instance from the source tenant to the target tenant.
    No Change
    Status icon: Gray
    Lists instances that are identical in the source and target tenants. No migration is necessary.
    Excluded
    Lists top-level instances that you've excluded from the migration.
    If you haven't excluded anything, Workday doesn't display this tab.
    You can select a tab to filter by migration behavior. On the tab, you can expand an implementation type to review the top-level instances in scope for migration. The same inplementation type can appear on multiple tabs, but the instances listed under it only relate to a particular migration behavior. Example: You select the
    Modified
    tab and see the same implementation type that you saw on the
    New
    tab. You expand the implementation type and see a unique set of of top-level instances from the instances on the
    New
     tab. The
    Modified
    tab lists instances with differences between the source and target instances. The
    New
    tab lists instances that don't yet exist on the target tenant.
    The number beside the
    Modified
    status indicates the total number of top-level modified instances in scope for migrtation. The number beside the
    New
    status indicates the total number of top-level instances that Workday will add to the target tenant.
    Pre-Migration Diff
     reports for migrations that don't proceed remain available for 30 days
    .
  15. (Optional) Review the dependencies of the new or modified instance or instances:
    1. Navigate to the
      Modified
      or
      New
      tab and expand the implementation type.
    2. In the
      Dependencies
      column of the table, click
      View Dependencies
       for the instance with dependencies you want to review.
      Workday recommends that you examine the dependent objects in new or modified instances.
      Like top-level instances, Workday provides a status icon for each dependent instance:
      Modified
      ,
      New
      , or
      No Change
      .
      When Workday encounters a circular dependency, it stops loading any more dependencies for the instance. Workday migrates circular dependencies. To prevent repetitive reporting of the same dependency, it only displays the first occurrence of the dependency and flags it with a circular dependency icon.
  16. (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.
  17. (Optional) When the migration contains
    Modified
    instances, click
    Manage Modified Instances
     on the
    Dependencies Diff
    page to exclude a modified instance or one of its dependencies from migration.
    1. In the
      Instances to Migrate
       table, clear the check box for the instance that you want to exclude. Excluding a top-level instance also excludes its dependencies from migration.
    2. (Optional) In the
      Dependencies
      column, click
      View
       to view the dependencies of an instance again.
    3. Click
      Save Changes
       and confirm that you want to save your selection. Once saved, you can’t undo the exclusion. To undo the exclusion, start a new migration.
    On the
    Dependencies Diff
    page, Workday displays the instance as excluded in the table of instances. When you exclude a top-level instance, Workday reports the top-level instance as
    Excluded
    and its dependencies as
    Excluded by Parent.
     Workday doesn’t exclude dependencies that are also dependencies of another implementation type if that implementation type is part of the same migration.
    You can also verify the excluded instance on the
    Excluded
    tab on the
    Pre-Migration Diff Report
     page.
  18. 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.
  19. Click
    Start Migration
    .
  20. 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.
  21. (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.
When you’ve refined your configuration content to meet your customers' requirements, you can migrate the Configuration Catalog content from your sandbox tenant to the Production tenant.