When an internal platform gets old, the tempting plan is a clean rewrite. It almost never goes to plan: requirements move while you build, the old system keeps changing, and the switch-over becomes a single terrifying weekend.
- Split the system into modules users would recognise.
- Ship the riskiest module first, on purpose.
- Run old and new side by side, syncing data both ways.
- Retire each old module only when nobody opens it anymore.
Why big-bang rewrites fail
A full rewrite can't be tested by real users until it's nearly done, so every wrong assumption surfaces at the end. Meanwhile the business keeps changing the old system, and the new one chases a moving target.
Riskiest module first
It feels safer to start with something easy. It isn't — the easy modules teach you nothing. Start with the module that matters most: if that one fails, nothing else will.
Takeaway
The first module you ship should be the one you're most afraid of. That's where the unknowns are.
Run both systems side by side
The new module reads and writes the same data as the old system, so users can switch back if something breaks. That safety net is what lets a pilot team use it for real work from week one.
Retire, don't switch off
Old modules go away when usage drops to zero on its own, not on a date in a plan. When nobody opens the legacy screen for two weeks, it's safe to remove.