Migration is a data problem wearing a software costume
Most failed migrations are not migrations of software. They are attempts to move twenty years of accumulated data habits into a system that expects them to be consistent.
The same supplier under four different codes, all still active.
Stock balances that have never reconciled to the ledger.
Item codes carrying meaning in a naming convention nobody documented.
Opening balances that only one person knows how to derive.
Audit
What data exists, what is duplicated, what is dead, and what has to be decided by a human before anything can move.
Masters
Items, suppliers, customers, accounts. Cleansed and deduplicated, with the decisions recorded rather than applied silently.
Balances
Opening stock, trial balance, receivables and payables, reconciled against the source system report by report.
Open transactions
Purchase orders, sales orders and work orders still in flight, migrated last and verified against the floor.
What makes a migration expensive
None of these are software costs. All of them are decisions someone in your business has to make.
Deciding what not to bring
Every organisation wants full history. Most need three years of transactions and clean masters. The rest belongs in an archive you can query.
Agreeing the valuation method
Standard, moving average or FIFO changes your opening balances. Decide it before the load, not after finance queries the first close.
Naming conventions
If item codes carry meaning, someone has to decide whether that survives. Changing it during migration is cheaper than changing it later.
Who signs the numbers
A migration is done when finance and operations both sign the same reconciliation. Without a named signer, it is never done.
How much history should we migrate?
Usually three years of transactions plus full masters and current balances. Older data goes to an archive you can still query, which is far cheaper than making it live.
Can we run both systems in parallel?
For one period, on the ledger, yes, and we usually recommend it. Running both indefinitely means maintaining two sources of truth and it always ends badly.
What if our data is genuinely bad?
Then the audit is the first deliverable and the cleanse is a project of its own. We would rather tell you that up front than discover it at load three.
How do you handle cutover?
A planned window between periods, with a rollback point, opening balances set by count, and the old system kept read-only for one cycle as a reference rather than a fallback.
Can you migrate from spreadsheets?
Yes, and it is often easier than a legacy ERP because the data is smaller. It is also usually dirtier, so budget more for the cleanse.
Migration is one phase of an implementation, not a separate service. The method page explains where it sits.
ERP implementation checklist
The decisions that determine whether a rollout lands, most of which come before anyone configures anything. Readable in full, no email required.
Send us a sample of your data.
An hour with your item master tells us more than a month of meetings.