Why the new system keeps getting postponed
Everyone agrees the old system should go. The new one has been chosen, or at least discussed. And the move keeps slipping, because every time it comes up someone asks the question nobody can answer: what if we lose something?
It is a reasonable fear. Maybe you have seen it happen. A previous migration left notes behind, dropped attachments, or turned every date into the American format. Customers rang about things the new system had no record of. People still open the old system to check history because they do not trust the new one.
Where data actually gets lost
Data rarely disappears in one dramatic failure. It leaks through small gaps that nobody checked.
| Gap | What goes missing |
|---|---|
| Export does not include everything | Notes, attachments, history tables, custom fields |
| Field too short or wrong type | Truncated text, lost leading zeros, broken dates |
| No home in the new system | Data with nowhere to go is quietly left behind |
| Character encoding | Accented names and symbols turned to question marks |
| Relationships break | Orders no longer linked to their customer |
| Records change during the move | Work done on cutover day is lost |
The common thread is that the migration was a single manual event: export, tidy in a spreadsheet, import, hope. When that is the method, nobody can say for sure what arrived.
What staying put costs
- Continued licence and support fees for a system you have outgrown
- Workarounds and spreadsheets around its limits
- Risk growing each year as the old system ages
- A new system paid for and not used, or used alongside the old one
- Staff frustration with a tool everyone knows should have gone
Postponing does not reduce the risk. The data only grows, and the people who remember why things are the way they are gradually leave.
There is also a cost to the new system if it is already bought. A package that sits half set up, with a few enthusiasts using it alongside the old one, splits your records in two. Every month that goes on, the eventual migration has more to merge.
How we migrate
- Full extraction. We take the data from the source database itself where possible, not from a report or a partial export, including notes, attachments and history.
- Mapping document. Every source table and field is mapped to a destination, with a transformation rule if needed. Anything with no destination is listed, and you decide what happens to it, whether that is a custom field, an archive or a deliberate drop.
- Scripted migration. The move is a script that can be run again and again. That means we can rehearse it on copies, fix what is wrong and rerun it cleanly.
- Reconciliation. After every run we compare record counts per type, totals for money fields, and a sample of records checked field by field, including the awkward ones like long notes and unusual characters.
- User testing. Staff check records they know well in the new system and report anything that looks wrong.
- Cutover plan. A short freeze on the old system, a final delta migration for recent changes, a final reconciliation, then go live. A rollback plan is written in advance.
- Archive. The old system or a searchable copy of its data is kept read-only, so history can always be checked.
After the move
Staff work in the new system knowing the history is there, because they checked it during testing. If someone does find a gap, the mapping document and reconciliation reports show exactly what was moved, and the archive holds the original.
The fear goes because the unknowns were turned into lists and checked, not because anyone promised nothing would go wrong.
The scripts themselves remain useful too. If the business later merges with another, or adds a second system, the same mapping and reconciliation approach can be reused rather than worked out again from scratch.
Signs you are stuck here
- A system change has been postponed more than once over data worries
- A past migration lost notes, attachments or history
- Nobody is sure what the old system holds beyond the main screens
- Staff still open an old system to check history
- The migration plan is an export into a spreadsheet