Ask anyone who has run an HRIS implementation what nearly derailed it, and almost none of them will say the software. They will say the data.
It is the least glamorous part of the entire project. Nobody demos it. Nobody gets excited about it in the steering committee. It appears in the plan as a single innocuous line — "data migration" — sitting between configuration and testing as though it were one task of comparable size. And it is, with grim reliability, the thing that slips the timeline, blows the budget, and quietly determines whether the system you spent a year selecting is trusted or resented the day it goes live.
The reason is simple and rarely stated plainly. You are not moving data. You are moving the accumulated mess of every HR decision your organization has made for the last fifteen years — into a system that, unlike your old one, will actually enforce rules about what is allowed to exist. The migration is where that mess finally becomes visible. And there is far more of it than anyone expects.
"We'll Migrate Your Data" Is Three Different Promises
When a vendor or partner says they will handle the data migration, that single phrase can mean any of three very different things, and the gap between them is measured in months of your team's time.
It can mean they will move the data — take your files, transform them, and load them into the new system, with their people doing the work. It can mean they will provide the tools and the mapping while your team does the extraction, cleansing, and validation. Or it can mean they will migrate a defined set of records and fields, in a standard format, and everything outside that definition — historical data, custom fields, attachments, anything messy — is your problem and your cost.
Most buyers hear the first meaning. Most contracts specify the third. That gap is where implementations quietly go wrong: the client team discovers, weeks in, that "migration support" meant guidance, not labour, and that the work they assumed the vendor owned has been theirs all along. Before anything moves, get the answer in writing to one question: who physically does the extraction, the cleansing, and the validation — and for exactly which data?
The Cleanup Nobody Scopes
Every organization believes its data is in reasonable shape. Almost none of them are right, and the migration is where they find out.
Fifteen years of an old system accumulates things a new one will refuse to accept. Employee records with inconsistent formats, because the rules changed three times and nobody went back to fix the old entries. Terminated employees whose records were never properly closed. Duplicate people who exist twice because of a reorganization or an acquisition. Custom fields that meant something to one HR manager in 2014 and nothing to anyone since. Manager relationships that point to people who left years ago. Addresses, cost centres, and job codes that were free-text where they should have been controlled, and are now a thousand spellings of the same twelve values.
The old system tolerated all of it because it enforced almost nothing. The new system will not. It has validation rules, mandatory fields, and referential integrity — which is exactly why you bought it, and exactly why your existing data will not fit through the door without work. That work — the profiling, the de-duplication, the reconciliation, the decisions about what to keep and what to let go — is real, large, and almost never in anyone's original estimate.
Clean data is not a prerequisite the vendor supplies. It is a project your organization runs, and it is the one that most often gets discovered rather than planned.
Start It Months Before You Think You Need To
Migration is treated as a late-stage task — something that happens near the end, once configuration is settled and go-live is in sight. This sequencing is precisely backwards, and it is the most common structural mistake in the entire implementation.
Data cleansing has no shortcut and does not compress. You cannot de-duplicate ten thousand employee records faster by adding people at the last minute; you can only discover, too late, how many of them are wrong. When migration is left until the end, the timeline offers two choices, both bad: slip the go-live, or migrate dirty data to hit the date. Under deadline pressure, organizations almost always choose the second — and then live with the consequences for years.
The discipline is to begin data profiling in the first weeks of the project, in parallel with configuration, not after it. Pull a real extract early. Find out how bad it actually is while there is still time to do something about it. The teams that go live cleanly are not the ones with better data — they are the ones who looked at their data early enough to fix it without panicking.
Who Actually Owns It (It's Probably You)
The single most dangerous assumption in any migration is that someone else is handling it. The vendor assumes you are cleansing the data, because they cannot possibly know your business rules well enough to decide which of two conflicting records is correct. You assume the vendor is handling migration, because that is what "migration support" sounded like. And so the work that belongs to nobody sits untouched until the schedule forces a reckoning.
Only your organization can make the decisions the migration requires. Which of these two employee records is the real one. What to do with fifteen years of history you may or may not need. Whether a field that mattered a decade ago should survive into the new system. These are business decisions disguised as technical ones, and no external party can make them for you. The vendor can move data. They cannot decide what your data should be.
The organizations that handle this well name an owner early — someone accountable for data quality, empowered to make the keep-or-drop calls, and resourced with enough of the right people's time to actually do the work. Without that owner, migration becomes everyone's assumption and no one's responsibility, which is the same as no one doing it.
Bad Data Doesn't Stay in the Past
There is a temptation, under deadline, to treat migration as a one-time hurdle: get the data in, go live, move on. But data that goes in wrong does not stay quietly in the past. It becomes the foundation everything else is built on.
A duplicate employee record does not just look untidy — it corrupts headcount reporting, double-counts in analytics, and confuses every downstream integration. A manager hierarchy migrated with errors breaks approval workflows on day one. History loaded into the wrong fields produces reports the business quietly stops trusting, and a system nobody trusts is a system nobody uses. Worst of all, incorrect data feeding payroll produces wrong pay — the single fastest way to lose the workforce's confidence in the entire platform, no matter how good the software underneath it is.
This is why migration quality is not a technical detail to be delegated and forgotten. It is the foundation of whether the system is believed. You can recover from a delayed go-live. Recovering from a go-live built on data the organization has learned not to trust is far harder, and takes far longer, than doing the migration properly would ever have.
The Role This Keeps Pointing Back To
Issue 02 of this newsletter described the role nobody budgets for — the HR Tech expert who bridges business operations, HR processes and technology decisions. Migration is where that bridge is most needed and most often missing. The technical team knows how to move data but not which of two records is the correct one. The HR team knows the business rules but not what the new system will and won't accept. The gap between them is exactly where migration decisions live.
Someone has to stand in that gap: translating business reality into migration rules, deciding what history is worth keeping, and holding the line on data quality when the timeline starts pushing toward "just load it and fix it later." Without that person, migration defaults to whatever is easiest under deadline — which is almost never what is right.
A Final Thought
The software gets the attention because it is the visible, exciting part of the project. But no platform, however good, can outrun the data it is fed. The most sophisticated system in the world, loaded with fifteen years of unexamined mess, produces sophisticated, well-designed wrong answers.
None of this is difficult to prevent. It requires pinning down who actually does the migration work, treating data cleansing as the real project it is rather than a line item, starting months earlier than instinct suggests, naming a clear owner, and refusing to trade data quality for a go-live date. Unglamorous, every one of them — and collectively they matter more to your outcome than any feature you compared in the demos.
You spent a year choosing what the system can do. Whether it does it correctly depends entirely on what you put inside it.
The best software in the world cannot outrun the data you feed it.