When a Workday Object Transporter (OX) migration stops with Diff Report Not Generated, Workday has blocked the package during its pre-migration prerequisite check because a dependent object is missing in the target tenant or has a missing or mismatched Reference ID. Workday displays only the first 50 missing prerequisites at a time; you must resolve or map that initial batch and run Rescan Target (or Retry Migration if you fixed the source) before Workday reveals any remaining prerequisite failures and generates the View Pre-Migration Diff report.
This guide covers the four-stage Object Transporter workflow in Customer Central, the exact causes of prerequisite and Reference ID failures, supported tenant-to-tenant migration paths, and how OX handles effective dates and security policies.
The four-stage Object Transporter workflow
Whether you start from the source tenant or from the Object Transporter (OX) worklet in a Customer Central tenant using the Migrate with Object Transporter or Migrate Configuration Extract tasks, Workday runs four steps in order:
- Error check: Workday scans the source package for structural errors that block migration outright and displays the View Errors page if any exist.
- Prerequisites check: Workday verifies that every configuration prerequisite required by your top-level instances and their dependencies exists in the target tenant with a matching Reference ID. If any prerequisite fails, Workday stops before generating a diff and shows the Pre-Migration Check Report.
- Premigration differences check: Once all prerequisites pass, Workday generates the Pre-Migration Diff Report (retained for 30 days for migrations that do not proceed), grouping instances by implementation type across five status tabs: All Instances, Modified (orange), New (blue), No Change (gray), and Excluded.
- Migration and post-migration verification: Workday migrates the current version of each tenanted object (minus any modified instances you excluded) and produces a Post Migration Report (retained for 2 years), from which you can launch Run Tenant Compare.
Resolving Diff Report Not Generated and the 50-prerequisite cap
A configuration package rarely fails because of the top-level report or business process you selected; it fails on a nested dependency such as a calculated field, condition rule, security group, or custom object whose prerequisite is absent or has a different Reference ID in the target tenant.
When you open View Pre-Migration Check Report, check two columns on the Errors table for each row:
| Column state | What it means | How to fix it |
|---|---|---|
| Non Mappable = Yes | The prerequisite cannot be mapped inside Object Transporter. | Sign in to the target tenant, create the missing instance with the exact Reference ID from the source tenant (or edit the existing target instance's Reference ID to match), and click Rescan Target. If the source Reference ID was blank or wrong, fix it in the source tenant and click Retry Migration. |
Map to Instance in Target (optional) shows Map Instance |
You can use tailored loading to bind the source prerequisite to an existing compatible target instance without editing the target tenant first. | Click Map Instance, enter the Reference ID of the compatible target instance of the same implementation type, select it, and click Apply Mapping, then Rescan Target. |
Because Workday caps the initial error table at 50 prerequisites, fixing all 50 and clicking Rescan Target may surface a second batch. Repeat the cycle until Workday skips the Pre-Migration Check Report and opens the Pre-Migration Diff Report.
Supported tenant migration paths and where OX refuses to run
Before building a package in Object Transporter or an advanced configuration package in Configuration Change Tracker, confirm two things: first, run the Object Transporter Supported Objects (OX) report in your tenant to verify that the implementation type is supported; second, verify that your source-to-target tenant pair is an allowed migration path.
| Source tenant | Allowed target tenants | Key restriction documented by Workday |
|---|---|---|
| Implementation | Implementation, Sandbox, Preview | Migrating a configuration extract from an Implementation tenant to a Workday App Development tenant is not supported and returns an error. |
| Sandbox | Implementation, Sandbox, Preview | Standard path for promoting tested configuration between non-production environments. |
| Preview | Implementation, Sandbox | If your package relies on functionality, web service versions, or data models delivered to Preview that have not yet reached non-Preview tenants, wait until the Production delivery cycle completes before migrating. |
| Production | Sandbox, Implementation, Preview | Workday supports package migrations from Production to non-production tenants, but does not support migrating single instances from Production tenants. |
| Wdsetup (Configuration Catalog) | Implementation, Sandbox | You can only modify or map to existing target tenant instances. |
| Workday App Development tenant | Implementation | Supported when migrating a configuration extract to an Implementation tenant. |
Notice what is absent from the target column: Object Transporter does not migrate packages directly into a Production tenant as an unattended bulk push without the governance controls your tenant topology enforces, and many day-to-day setup changes or unsupported implementation types still require direct configuration or safe tenant-to-tenant copying.
Overwrites, security policy merges, and attribute diffs
Understanding what Object Transporter overwrites versus what it merges prevents unexpected permission drift in the target tenant:
- Standard modified instances overwrite the target: Any instance on the Modified tab (except security policies and translation values) overwrites the target tenant's instance when migrated. On the Attribute Diff page, Workday marks changed attributes as Change (overwrites target), New (adds to target), Removal (exists in target but not source; removed on migration), or Not Matching (merges language translations without overwriting existing target translations).
- Security policies default to additive Merge: When a package contains modified domain or business process security policies, Workday's default migration behavior is Merge (Recommended), which adds permission-holding security groups and roles from the source policy to the target policy without removing existing target permissions. Workday never assigns Removal status to attributes on domain or business process security policies under a merge.
- When to use Override or Manual Selection: Clicking Edit Migration Behavior lets you switch all modified security policies to Override (replacing the target policy completely with the source policy) or Manual Selection (choosing Merge or Override per policy). Even when you override a policy, migrations for security groups and their business process security policy permissions remain additive—removing an unwanted security group assignment in the target tenant requires a security administrator to remove it manually.
- Excluding modified dependencies: In Dependencies Diff, clicking Manage Modified Instances lets you clear the check box on a modified instance to exclude it. Excluding a top-level instance marks its dependencies as Excluded by Parent, unless a dependency is also referenced by another included implementation type in the same package. Once you click Save Changes on an exclusion, you cannot undo it without starting a new migration.
- Circular dependencies: When Workday encounters a circular dependency while expanding View Dependencies, it flags the first occurrence with a circular dependency icon, stops loading further nested rows to avoid an infinite loop, and still migrates the circular dependency.
Effective date inheritance traps
If your package includes effective-dated objects, clicking Set Effective Date Strategy sets the package default (such as 01/01/1900 or a manual date), with optional overrides by implementation type or individual instance. Watch for two inheritance rules:
- When you migrate a single instance, all of its effective-dated dependencies inherit the effective date you select for that instance.
- When a top-level instance has no effective date of its own, any effective-dated dependencies underneath it inherit the date of migration as their effective date unless you override them using Set Effective Date by Instance.
How kiweely helps when Object Transporter blocks or doesn't cover the object
When a migration stalls on 50 mismatched Reference IDs, a broken calculated field dependency chain, or an implementation type that Object Transporter does not support, kiweely works directly in your connected source and target Workday tenants with your consent. In a single conversation, kiweely can inspect the source object's full dependency tree (including calculated fields that return blank or condition rules that failed to fire), compare Reference IDs and security groups against the target tenant, and carry out the missing target setup one step at a time—asking for your approval before every change and reading the saved configuration back to prove the target matches.