System Replacement and Data Migration: Switching Systems Without Losing Ten Years of Data

The hard part of replacing a system was never the new system — it's the ten years of data inside the old one. Customer lists, transaction records, inventory ledgers: move them over and the new system can take charge of operations on day one; fail to move them, or move them wrong, and you lose the past and the present at the same time. In the system-replacement projects we've handled, data migration routinely takes over a third of the total project hours — while the owner's expectation is usually "isn't it just export and import?" This article walks the complete path to a safe exit.

Step One: Find Out Whether the Data Can Even Come Out

Do this step before deciding to switch systems, not after. The old system's export capability directly determines the migration's difficulty: full export functionality is best; if only partial reports can be exported, assess whether the missing data can be reconstructed; if it's completely locked down, you may have to negotiate with the original vendor — and that's when you'll feel the cost of never having negotiated deliverable clauses in the contract (we cover this thoroughly in who owns the code and data after system delivery). One aside: even if you're not switching yet, go verify today that your data can be exported, and build a regular backup habit — details in data backup strategy.

Step Two: Data Cleaning — The Dirtiest and Most Valuable Work

Ten years of data is always dirty: duplicate customers (the same person three times, each with a differently formatted phone number), junk-filled fields (an address field reading "same as above"), long-discontinued products still carrying inventory. Migration is the best moment to clean, because dirty data moved into the new system makes the new system dirty from day one.

Practical cleaning principles:

• Define the primary key before deduplicating. What identifies the same customer — mobile number? tax ID? Decide first, then machine-screen and human-verify.
• Not all data needs to move. The value of seven-year-old order history inside the new system may be lower than the confusion it creates. The common compromise: migrate the last two to three years of detail in full, and convert older data into summary figures or archive it as read-only reference files. How much to move depends on your regulatory requirements (e.g. tax-document retention periods) and actual lookup frequency.
• Keep the mapping table. Which new-system record does old customer number C0012 map to? That mapping table must not be discarded after migration — every future historical investigation depends on it.

Step Three: Parallel Running — Trade a Painful Stretch for a Safe One

The clean cut — "shut the old system Friday, open the new one Monday" — bets the entire company on a zero-defect migration, and we don't recommend it. The safe approach is parallel running: for a period, both systems coexist, the new system actually carries operations, and the old system stays queryable with daily reconciliation. This stretch is painful — some data gets entered twice, staff will complain — so control its length, usually two weeks to a month, and set explicit graduation criteria: N consecutive days of reconciliation with zero discrepancies, and every critical process exercised on the new system, before the official cutover.

The point of parallel running is to move the moment you discover a migration error — from the day it blows up to a day when it can still be fixed.

Step Four: The Rollback Plan — Hope It's Never Used, But It Must Exist

Before cutover day, write down in black and white: if the new system fails badly, how do you return to the old one? What triggers a rollback (what severity of problem qualifies, and who has the authority to call it)? How does data created in the new system after cutover get back-filled into the old one? How long must the old system remain operable (our habit: at least one full month-end closing cycle)? A cutover without a rollback plan is going all-in with your operations. In practice, teams that write a rollback plan almost never use it — because the process of thinking through the risks is itself the best prevention.

Three Small Things That Always Get Forgotten

1. The old system's URLs and integrations: website forms, scheduled reports, and third-party services wired to the old system are routinely missed on the cutover checklist — and detonate one by one on launch day.
2. Staff muscle memory: finish training during the parallel-running period, not live on cutover day.
3. The old system's retirement rites: confirm the data archive, cancel recurring license charges, revoke accounts. Every year, companies keep paying monthly fees for systems nobody uses anymore.

Replacing a system is a once-a-decade event and deserves engineering rigor. If you're evaluating a replacement and want help mapping the migration path properly, come talk to us: custom systems and SaaS development.