Before you start
- ✓A repeatable data migration (see the migration guide)
- ✓A way to stop the new system emailing customers
- ✓A list of the paperwork and spreadsheets other people depend on
- ✓A decision on how order numbers continue
- ✓The order in which people and features will move over
Make the new system safe first
Staff only find the gaps by entering real work, so the new system must not be able to contact customers until you decide. On a recent Access replacement we built a two-layer email kill switch: a check on all eight places that send email, plus a fallback that only logs anything already waiting. It works alongside safe addresses in the migrated data.
Enter real work in both
For a period the old system stays the record while staff enter the same work in the new one. Each difference is a bug or an unwritten rule; proving the systems match covers what to compare.
Keep what staff rely on
Keep familiar printouts and keep feeding spreadsheets others depend on: a "copy spreadsheet row" button gave staff exactly the row they paste into their production sheet. On one rebuild the old admin area stayed behind a menu link.
Decide numbering and pace
If numbering restarts at 1, both systems have an order 1: carry on from the old highest number, or set an admin-editable starting number per order type. People can also move over in stages, with access switched on per person and area as they're ready.
Switch over from a fresh copy
- Freeze changes in the old system.
- Extract again and compare with your baseline.
- Run the migration a final time with real email addresses.
- Confirm none of the blocking checks fail.
- Keep the old system read-only for reference.
What usually goes wrong
From our own projects, not the manual.
Order numbers would have collided
Restarting each order type at 1 meant both systems would have an order 1 until the old records were retired. We set a starting number per type, editable by an admin, and recorded the old system's highest number.
Test data could have emailed real customers
Rehearsals and parallel entry used real customer records. Swap emails for safe addresses by default, and guard every route that sends email, including messages already waiting to go.
The new system's demo data could overwrite migrated records
Routines that fill a new system with demo data during development would have run over the migrated database. They now skip automatically once migrated records exist.
Staff depended on a spreadsheet the project didn't own
A production spreadsheet other people used every day couldn't be switched off on day one. Feeding it the same row it always had kept everyone working while the new system took over.
Do it yourself, or get help?
If only a few people use the old system and the data is simple, a well-planned weekend cutover can work. If several teams depend on it, customers get emails from it, or bookings run months ahead, get help planning the parallel run: most cutover problems come from something nobody listed.
Get a developer on it