The Risk Is the Logic Nobody Wrote Down
Moving off a legacy ERP is rarely a data problem. It is the pricing rule somebody coded in 2009, the discount that only applies to three customers, and the report finance relies on that nobody can explain. We recover those rules first, then migrate.
50+ ERP and software projects. Zero failed projects since 2021.
Legacy systems hold knowledge that left with people
The rules are still running every day. They are just no longer written anywhere, and nobody notices until the new system gives a different answer.
We work out what the old system actually does
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. Then we interview the people who have quietly worked around it for a decade, because the workarounds are themselves part of the real process.
- Source read where it exists, behaviour tested where it does not.
- Workarounds captured, not dismissed as bad habits.
- Every recovered rule documented and confirmed.
Twenty years of history does not belong in the new system
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.
- Open items and balances migrated, closed history archived.
- Archive remains searchable for audit and disputes.
- A smaller, faster system to test and to run.
The problems specific to legacy systems
These are what separate a legacy migration from a straightforward implementation.
From an opaque system to a cutover with a way back
What a legacy migration covers
Extraction proof
A real sample pulled from the old system early, so feasibility is fact not assumption.
Business rule document
Every recovered rule written in plain language and confirmed with the people who use it.
Dependency register
The spreadsheets, scripts and reports feeding off the old system, so none are orphaned.
Archive strategy
What is carried, what is archived read-only, and how the archive stays searchable.
Parallel run comparison
Real transactions through both systems, with every difference explained.
Cutover runbook
Timed steps, named owners, checkpoints and the rollback route agreed in advance.
What getting off legacy gives you
Why teams choose TCB Infotech for legacy migration
Legacy ERP migration questions
Nobody here knows how the old system calculates things. Is that a problem?
The vendor is gone or will not help. Can you still get the data out?
What do we do with twenty years of history?
Can we keep the old system running as a fallback?
How long does a legacy migration take?
How do we know the new system produces the same answers?
Plan Your Move Off the Old System
Book a free consultation. Tell us what you are running and what nobody can explain about it, and we will set out how the rules would be recovered and the data extracted.
Book a Free Consultation →No commitment. An honest read on what the migration involves.
What Is Inside a Legacy ERP Migration
The difference between this and a normal implementation is discovery. Here is how we prove the data can come out, recover the rules nobody documented, and decide what history is worth carrying.
From proving extraction to retiring the old system safely
We prove it can come out before planning anything else
The first piece of work is a real extract from the old system, because a migration plan built on an assumption about data access is worthless. At the same time we map what else reads from that database: the spreadsheets, scripts and reports built over the years that will silently break the day it goes away.
- A genuine extract taken early, not a promised one.
- A register of everything feeding off the old system.
- Extraction route documented so it can be repeated at cutover.
Three ways to find out what the system really does
We read the source where it exists. Where it does not, we test the system with known inputs and record the outputs until the behaviour is clear. Then we interview the people who use it, because the workarounds they have built are part of the live process and will otherwise be lost entirely.
- Source review where code is available.
- Black-box testing where it is not.
- User interviews to capture the workarounds.
Carry what you need, archive what you must keep
Open items and balances migrate. Closed history goes to a read-only archive that stays searchable for audit and disputes, which keeps the new system small and its testing manageable. The cutover itself is a timed runbook with owners and checkpoints, and the old system drops to read-only rather than being switched off.
- A clear split between migrated and archived data.
- Archive that satisfies retention and audit duties.
- Old system read-only for a defined period after cutover.
Everything the migration delivers
Extraction feasibility note
The route, a real sample, and whether it can be repeated reliably at cutover.
Business rule document
Every recovered rule in plain language, confirmed by the people who rely on it.
Dependency register
Reports, spreadsheets and scripts reading the old system, each with an owner.
Archive design
What is kept, where, how it is searched, and how long it is retained.
Parallel run results
Real transactions compared across both systems, with each difference explained.
Cutover runbook
Timed steps, owners, checkpoints and the agreed route back.