Reference
What goes wrong during an HCM migration?
The short answer
Migrations fail in five predictable ways: source data is worse than discovery assumed; configuration quietly becomes customization; no one internal has authority to decide; parallel payroll gets cut when the calendar tightens; and the change is announced rather than managed. None of them are software problems, all of them are visible in advance if someone looks, and the one that causes visible damage is the truncated parallel.
The data is worse than anyone admitted
Every timeline assumes clean source data and nobody has it. Duplicate employee records, terminated staff still active, inconsistent job codes, historical pay elements no one can explain, accrual balances that only reconcile if you nominate one system as authoritative and cannot justify which.
Surfaces in week four to six, when data loading begins in earnest. Prevented by auditing the export before committing to a date — a few days of work that changes both the plan and the price.
Configuration becomes customization
Every product has things it does natively and things it can be made to do. Crossing that line carries permanent cost: upgrade friction, brittle integrations, and a configuration only one consultant understands.
Most of what pushes you across it is policy nobody would defend if asked. Surfaces during configuration workshops, and by then the decision has momentum. Prevented by auditing your own rules first and deciding which are genuinely load-bearing.
Nobody internal can decide
Implementations generate a continuous stream of decisions, most small and some consequential. Where they route through a committee, the queue becomes the critical path and the vendor’s timeline slips through no fault of the vendor.
Surfaces gradually, which is what makes it dangerous — no single delay looks like a problem. Prevented by naming one person with authority and protected calendar time before kickoff.
Parallel payroll gets cut
Running old and new side by side for at least two full cycles, reconciled to the cent including taxes, garnishments and every deduction, is the only reliable proof the configuration is right. It is also the last item before go-live and therefore the one the schedule eats.
This is the failure that produces visible damage, because it surfaces as incorrect pay in front of every employee. Prevented by fixing the cycle count in the contract, so cutting it is a commercial conversation rather than a scheduling decision.
The change was announced, not managed
Managers and employees meet the system through a launch email. Adoption stalls, shadow spreadsheets persist, and the reporting the platform was bought for is built on data nobody is entering properly.
Surfaces three to six months after go-live, framed as "the system does not do what we were promised" when the system is doing exactly what it was configured to do with the data it is receiving.
The pattern underneath all five
Every one is a readiness failure rather than a delivery failure, and every one is cheaper to prevent than to correct. The work that prevents them happens before a contract is signed, which is precisely when nobody is thinking about implementation.
| Failure | Surfaces | Prevented by |
|---|---|---|
| Dirty source data | Week 4–6 | Data audit before the timeline is set |
| Configuration → customization | Configuration workshops | Auditing your own policies first |
| No internal decision-maker | Gradually, as slippage | Naming one owner with authority |
| Parallel payroll cut | First live run | Cycle count fixed in the contract |
| Unmanaged change | 3–6 months post go-live | Training and a real process retirement |
Common questions
Which failure is the most damaging?
Can we recover a migration that is already going badly?
Should we migrate historical payroll data?
Where this sits
This page supports HCM | Workforce Management Advisory Services — the practice that does this work.
