Legacy ERP Migration
Moving off a legacy ERP is rarely a data problem. It is the pricing rule coded in 2009 and the report nobody can explain. We recover those rules first, then migrate.
Why It Matters
Where source code is available we read it. Where it is not, we test the system with known inputs and record what comes out, which is slower but works on anything.
Migrating closed transactions from a decade ago adds cost, extends testing and slows the new system, for data almost nobody queries. A read-only archive keeps that history searchable and reportable for audit or dispute, while the live system holds only what it needs to operate.
We pull a real extract early, because everything else depends on it being possible.
Code read, behaviour tested and people interviewed, then written up and confirmed.
The new setup built around the documented rules, with archive scope agreed.
Real transactions through both systems, differences investigated on both sides.
Timed runbook, agreed rollback route, old system to read-only afterwards.
A real sample pulled from the old system early, so feasibility is fact not assumption.
Every recovered rule written in plain language and confirmed with the people who use it.
The spreadsheets, scripts and reports feeding off the old system, so none are orphaned.
What is carried, what is archived read-only, and how the archive stays searchable.
Real transactions through both systems, with every difference explained.
Timed steps, named owners, checkpoints and the rollback route agreed in advance.
No plan is worth anything until a real extract has come out of the old system.
We treat undocumented logic as the main risk, not as a discovery detail.
How people cope with the old system tells you what the new one must handle.
Carrying all history is expensive and rarely useful, and we say so before you pay for it.
When the systems disagree we find out which is right. The old one often is not.
It is the normal starting point and it is the real work of a legacy migration. We recover the rules by reading the code where we can get it, by testing the system with known inputs to see what comes out, and by interviewing the people who have worked around it for years. Those rules get documented before anything is rebuilt.
Usually. Even closed systems normally allow a database read, a report export or a printable output that can be parsed. It is slower and less pleasant than a supported export, but we have not yet met a system that held its data somewhere entirely unreachable.
Not migrate it, in almost every case. Loading two decades of closed transactions into a new system adds cost and testing time for data nobody queries. The better answer is a read-only archive: keep the old data searchable and reportable without carrying it into the live system.
Read-only, yes, and we recommend it for a period. Keeping it writable is a different matter, because two live systems drift apart within days and you end up reconciling forever. The usual pattern is writable during the parallel run, then read-only, then archived.
Typically 4 to 9 months end to end, and the discovery phase is what makes it longer than a standard implementation. Recovering undocumented rules cannot be rushed safely, and every project that has tried has paid for it during the first month-end on the new system.
By running both for at least one full cycle and comparing the outputs, not by reviewing a specification. We take real transactions, put them through both systems and reconcile the results. Where they differ we find out which one is right, because the old system is not always the one that was correct.
Related
The other services in this section, and related pages from TCB Infotech.
No commitment. An honest read on what the migration involves.
