Moving your data to a new system: what to take and what to leave
Echipa HR 365 · reviewed 2026-09-15 · 5 min read
Migrations do not fail for technical reasons; they fail because the old data contradicts itself and nobody has the authority to decide which version is true. The order that works is: people and structure first, then balances, then history — and only as much history as you will actually use, because the rest stays available in the old export anyway.
Why it actually fails
In an old system, the same person can appear with two hire dates, in a department that no longer exists, with a manager who left last year. None of it caused trouble as long as the file was read by someone who knew the context. A new system does not know the context and demands a single value.
| What contradicts | Who settles it |
|---|---|
| The hire date differs between files | The personnel file, not the payroll sheet |
| The department no longer exists | Who runs it today, not what the old record says |
| The manager has left | Filled in before the import, never left empty |
| The leave balance differs from your own calculation | A reference date is set and nothing is recalculated retroactively |
| The same person, two rows | Decide which is active and mark the other, do not delete it |
The right order
In four stages
- Stage 1 — active people and structure: who is employed, in which department, who their manager is
- Stage 2 — balances at the reference date — leave, above all
- Stage 3 — documents and personnel-file data in current use
- Stage 4 — history, selectively — and only after the system is already in use
The temptation is to do it all at once so that “nothing is left behind”. In practice that delays go-live by months and raises the risk: the more you import in one go, the harder it is to say what went wrong when a number does not add up.
What is not worth moving
The useful question for each category is not “will we still need this?” but “have we opened it in the last twelve months?”. The answer is usually no, for most history older than two years.
- Timesheets older than the period you actually consult — they stay in the archived export.
- Employees who left five years ago, unless there is a concrete reason to have them in the live system.
- Fields nobody filled in consistently — they import empty and stay empty, adding only noise.
- Old organisational structures that no longer match reality.
A new system started with clean, sparse data is more useful than one started with the full history and three fields that contradict each other. The old archive does not disappear — it is kept as an export, in a known place, with a note about what it contains and up to when.
How to check that it worked
Not by counting. The fact that 342 rows went in says nothing about whether they are correct. The useful check is by sample and by totals: ten people picked at random, checked field by field against the source, plus a few sums that must match exactly.
- Ten people at random, compared manually against the personnel file, not against the file you imported from.
- Every manager: does each have the right reports? It is the field that breaks most often and it then affects every approval.
- The total leave days, compared with the old system at the reference date.
- The number of active employees, compared with payroll for the same month.
The second point deserves particular attention. The reporting structure is the field that leave approvals, timesheets and reviews all depend on afterwards — and an error there does not show up at import, but two weeks later, when somebody cannot approve a request and nobody understands why.
How long should I run both systems in parallel?
As briefly as possible — a month is usually enough, and only for one workflow, not for everything. A long parallel period looks prudent but leads to data entered in only one of them, so you end up with two contradicting sources. That is exactly the problem the migration was meant to solve.
What if the old vendor will not give me a complete export?
That is why the export question belongs at contract signing, not at departure. If you are already there, ask in writing what they can deliver and in what format, and build the plan around what you actually receive.
Who should lead the migration?
Someone from HR, not from IT. The hard decisions are not technical, they are about which version of the data is true — and only someone who knows the people and the processes can say.
Where to start
Before any import, take ten employees at random and try to fill in every field of the new system by hand, using only the sources you have. The contradictions you find in that hour are exactly the ones that would have stopped the migration three weeks in.
Employee and balance import, with a check before anything is written
You see what will be imported and which rows have problems before you confirm, and the manager structure is validated separately — where the errors usually are.
You can create an account in a few minutes and use every module for 7 days, no card required.