Name the source, target and exact scope
A tenant copy begins with four facts: the source tenant, the destination tenant, the objects in scope and the differences that are intentional. Read the source definitions and check the target for existing records before creating or replacing anything.
Workday supports configuration packages and Object Transporter for tenanted configuration, including Extend model components in supported tenant paths. Whether you use a package, a supported API or Workday's own editor, the comparison still needs to prove what arrived in the destination.
Compare meaning, not display names or tenant IDs
Tenant-specific identifiers are not portable evidence of equality. Match objects by a stable business key, then compare every property that changes behavior: exact text, missing versus false, relationships, security, aliases, formulas and referenced values. Resolve duplicate or ambiguous names before deciding that an object is the same.
Equal counts can hide swapped relationships. If two questions each point to one section and one rule, a target that exchanges those links still has the same counts and sets but different behavior. Compare each object's edges to its intended parent and dependency.
A calculated-field reference is not the calculation
Capture the field's business object, function, exact name, description, WQL alias and the complete calculation. For a condition field, preserve row order, And/Or, parentheses, selected fields, operators, comparison types and every comparison value. Read collapsed selections in full; a visible sample of the values does not establish the saved set.
Resolve referenced fields and tenant values by business identity in the destination. After saving, reopen the field and compare the formula and alias. A matching catalog record, name or generated prefix does not prove that the target calculation is equivalent.
Move prerequisites before the objects that use them
Build a dependency order from the definitions you read. Create or verify referenced values and fields before the rules that consume them, then the records whose eligibility, visibility or behavior depends on those rules. Keep deliberately unfinished dependencies visible instead of activating a partial configuration as though it were complete.
A missing value blocks only the object that needs it. Confirm the absence with Workday's own search, report or query; a failed picker interaction is not proof that the tenant lacks the value. Continue with independent objects while the real dependency is resolved.
Change one object, then read it back
After each save, reopen the destination object and compare the persisted definition with the source and the intentional differences. For an uncertain save, read first; do not create the same object again because the screen did not provide a clear confirmation.
Keep data comparison, dependency verification and behavior testing separate. Matching fields and relationships do not prove that the two tenants' populations or identities will produce the same outcome. When behavior matters, choose representative included, excluded, boundary and empty cases and record which branches were not tested.
Production keeps the same plan and a stricter execution rhythm
In kiweely, a Production tenant connects only after the person confirms the exact target and the risk to live employees and data. Agreement can cover one named change or a complete list shown in advance; anything new or different stops for another decision.
Execution remains one change at a time with a readback before the next. kiweely does not run a bulk write loop against Production, and Workday Extend deployment and promotion do not reach Production through the product.
Leave a record that survives interruption
Keep one current work record with the source definitions, identity mappings, intentional differences, confirmed destination changes and remaining checks. Update it after meaningful groups of verified writes. On resumption, read that record and inspect uncertain destination objects before continuing.
For the app-side checks that follow a configuration change, use the Workday Extend validation guide and the deployed-app testing method.