Platform: Two Workday tenants and Workday Adaptive Planning
Scope: The worker and compensation feed into a personnel planning sheet and a headcount sheet
The business problem
A personnel-planning model had to change its upstream Workday data source without risking existing planner inputs, modelled employee keys or historical figures. The source connection could change even when the business-facing plan stayed the same.
Existing architecture
Two Workday reports feed planning. A worker report loads a personnel sheet in the live planning version. A trended worker report loads headcount actuals. Both pass through one data source, staging tables with calculated columns, and two loaders. The personnel loader uses employee ID as its key.
Why it happened
The main migration risks were data-contract changes in IDs, aliases and row grain; differences in loader modes; and compensation fields present in source reports but not all used in the planning model. A loader set to replace could affect planner-entered data.
Design decision
We did not repoint the existing data source. We built a separate connection and data source for the new tenant, to run in parallel. That allows a side by side comparison and a clean rollback.
We asked the business one question before building: match what planning does today, or also switch on the four unused fields. We recommended matching today’s behaviour first.
We also asked for the full reports to move to the new tenant, not a new eight-field interface. That keeps the existing sheet, transformations and loader mappings reusable.
Implementation approach
- Compare the new reports with the old: schema, aliases, IDs and sample employees.
- Prove connectivity before building anything else.
- Import into separate staging tables and recreate the calculated columns.
- Copy the loaders and test them without touching the live version.
- Reconcile, rerun to test repeat loads, then plan cutover and rollback.
Controls and validation
Before cutover we check total rows, distinct and duplicate employee IDs, blank IDs, and employees with more than one position. We confirm the report returns only the intended worker population. We test that planner-entered values survive a load.
Outcome
The current-state contract was documented and a parallel connection and data source was prepared. Authentication works. Staging imports, loader regression tests and cutover follow once the new data source is fully available.
Lessons learned
- Agree the data contract first: IDs, aliases and grain. The internal logic of the reports can differ.
- Check the loader mode in production itself. Do not assume it matches the test environment.
- Build the new path in parallel. Repointing a shared data source puts every load that uses it at risk.
Scope of the outcome
Source-change assessment and parallel connection prepared; staging and cutover not documented as completed.
EPMLogic | Implementation insight based on an anonymized scenario. Exact operational amounts and client details are intentionally omitted.
