Short answer: do not switch everything off on a Friday and hope. Build the new system alongside the old one, keep the two in sync while people move across, and cut over once the new system has proved itself on real work. The business keeps running throughout, and the final migration becomes a routine step instead of a gamble.
Why do "big bang" replacements go wrong?
A big-bang cutover replaces the old system with the new one in a single step. It looks simpler on a plan, but it concentrates every risk into one weekend:
- Hidden rules surface late. Legacy systems, especially spreadsheets, carry years of undocumented conventions that nobody lists until something breaks.
- Staff learn under pressure. People meet the new system on the day they depend on it.
- There is no way back. Once the old system is off, every problem has to be fixed live.
What does a side-by-side migration look like?
- Map the current system first. Find every place data enters, where it goes, and who relies on which report. The spreadsheet nobody mentions is usually the one finance depends on.
- Build the new system around real processes, not an idealised version of them.
- Keep old and new in sync. Changes made in either system flow to the other, so teams can move across one at a time without losing data.
- Move people in stages, starting with a team that can give quick feedback.
- Compare the two. Reconcile totals and reports between old and new until they agree.
- Cut over once, when nobody needs the old system any more. The final migration is then a small, rehearsed step.
A real example: replacing a spreadsheet ledger
A supply chain solutions provider recorded every transaction in a centralised Google Sheet ledger. Order, revenue and cost data sat elsewhere, and sales data lived in a CRM that was analysed by hand in spreadsheets. There was no single view of how the business was performing.
We built a transactions system in Django to replace the ledger. While staff moved across, it stayed in sync with Google Sheets through bulk reads and writes, so nobody had to stop working or keep two records by hand. Once everyone had moved, we ran the final migration.
Around it, we added a daily ETL that aggregates orders, revenue and cost for fast analysis, and brought the CRM's leads and deals into the same database through its API. The result was three systems (transactions, orders and CRM) unified in one place, over 16 months of continuous development. Read the full case study.
What should you decide before starting?
- What must not break. Month-end close, payroll, customer billing: name them, and test them first.
- The source of truth during the transition. For each kind of record, decide which system wins when the two disagree.
- How you will know it works. Agree the reports and totals that must match before the old system is retired.
- Who owns the cutover. One accountable team, with the authority to delay it if the numbers do not match.
Key takeaways
- Run old and new side by side instead of switching in one step.
- Sync the two so teams can move across at their own pace.
- Reconcile reports before retiring the old system.
- Treat the final migration as a rehearsed formality, not the main event.
If you are planning to replace a legacy system or a spreadsheet the business has outgrown, tell us about it and we will scope the migration with you.