If the company reports into a foreign parent, the drivers are different: your Ukrainian subsidiary runs 1C.
Data migration is where quiet problems become loud. You can configure a system perfectly, but if dirty balances and duplicate customers drive into it, the team's trust in the new ERP disappears in the first week. The good news: migration can be made predictable.
The main principle: move less than you want to
The temptation to “bring 10 years of history” is almost always a mistake. Historical transactions are rarely needed in day-to-day work — keeping them in an archive is enough. Mostly open balances and master data enter the new system, not your entire past ledger.
What to migrate
- Master data: customers, vendors, items, chart of accounts.
- Open documents: unclosed orders, invoices, debts.
- Balances: inventory, cash, settlements as of the switch date.
- As much history as you truly need for reporting — no more.
Four migration stages
1. Audit and cleanup
First we look at what's actually in the old system. Duplicates, empty fields, incorrect codes — all fixed before the transfer. Cleaning data in the new system is far more expensive.
2. Mapping
Every field in the old system gets a counterpart in Business Central. This is where you decide how old codes, units of measure and categories map onto the new structure.
3. Test load
Data is loaded into a test environment and the team reconciles: do balances match, are debts correct, is everything in place. This step repeats until the numbers agree.
4. Final load
Done over a weekend or a low-activity period. By go-live the real data has already been validated on the test, so there are no surprises.
How to avoid downtime: the key is a parallel period. The old system runs until the last day, the final load is done as of a fixed date, and balance reconciliation finishes before the team starts working in the new system.
The most common mistake
Underestimating data cleanup. Teams often assume “the data is fine” until they see it laid out in a structured form. Reserve dedicated time for audit and cleanup in the plan — it's the cheapest insurance against post go-live chaos.
Still deciding whether the platform fits your business? Start with the Business Central platform guide — the problems it solves, what it covers, and how implementation and migration actually run.
What to migrate and what to archive
The most expensive mistake is migrating everything. Here is the working rule we apply on projects.
| Data type | Migrate | Comment |
|---|---|---|
| Master data customers, items, warehouses | Yes, in full | But clean it first — duplicates and dead records should not travel |
| Balances stock, cash, receivables | Yes, as at go-live date | The foundation of correct accounting from day one |
| Open documents | Yes | Unfulfilled orders, unpaid invoices, work in progress |
| Transaction history | Selectively | Usually one to two years for analytics. Deeper history stays in the archived system |
| Closed periods | No | Period totals are enough; source documents stay where the law requires |
| Legacy configuration | No | The classic trap: carrying old workarounds into a new system |
Migration stages with realistic timings
| Stage | Duration | Deliverable |
|---|---|---|
| 1. Data audit | 3–5 days | Report on master data quality: duplicates, empty fields, invalid codes |
| 2. Cleansing | 1–3 weeks | Verified master data in template format. The longest stage — and mostly done by the client |
| 3. Test load | 3–5 days | Data in a sandbox and the first list of discrepancies |
| 4. Reconciliation | 1 week | Signed reconciliation: balances in the new system match the old one |
| 5. Production load | 1–2 days | Usually over a weekend so operations are not interrupted |
Note stage two: it is the longest and it is performed mainly by your team, not the partner. If a project plan allows two days for cleansing, the plan is not realistic.
How to verify the migration is correct
Not by eye. Four control totals must match before go-live:
- Trial balance at the cut-over date — old system against new, to the cent.
- Stock balances by quantity and value for every warehouse.
- Receivables and payables by counterparty.
- Record counts in master data: what was exported must equal what was loaded.
A discrepancy of even a few cents is not a rounding artefact — it is a signal to find the cause. After go-live it becomes far more expensive to trace.
Why migrations fail
- Cleansing starts after the project does. Duplicates in the old system become duplicates in the new one.
- No data owner on the client side. The partner cannot know which of three identical customer records is real.
- Ten years of history migrated. Budget grows, performance drops, value is minimal.
- Test load skipped. Errors surface in the production environment.
- Legacy system switched off immediately. Keep it in read-only mode for at least six months.
Frequently asked questions about data migration
How long does data migration to Business Central take?
Two to six weeks depending on data quality. The longest stage is master data cleansing, performed mainly by the client team. The load itself takes one to two days and is usually scheduled over a weekend.
Can we migrate our full transaction history?
Technically yes, but it is rarely worthwhile. The optimum is balances at cut-over, open documents and one to two years of history for analytics. Deeper history stays in the legacy system kept in read-only mode.
Does the business stop during migration?
No. The production load is scheduled for a weekend or a quiet period. On Monday the team starts working in the new system while the old one remains available for reference.
Who is responsible for data cleansing — us or the partner?
The partner handles technical preparation, but only the client can decide which of three identical records is the valid one. That is why every project needs a nominated data owner on the client side.
What if our legacy data is in poor shape?
That is normal, and exactly why the first stage is a data audit. It reveals the scale of the problem before work starts rather than mid-project. Sometimes it is cheaper to migrate only balances and master data.
How do we confirm the data migrated without errors?
Through control totals: trial balance, stock balances by warehouse, receivables and payables by counterparty, and record counts in master data. The result is signed off in a reconciliation document before go-live.