Evolving a legacy system
Mangrove's back office earns money every day, and it is hard to change. This lesson gives you a method to replace it piece by piece: decide what to replace at all, find the seams, sequence the slices, move data out of the shared database, and prove each step before you switch, while all 320 stores keep trading.
By the end you can
- Decide per capability whether to keep, improve, replace or retire it, starting from outcomes instead of feature parity
- Find seams in entry points, code and data, and pick slices that can move on their own
- Sequence slices by value, risk and dependencies, with a rollback plan for every step
- Move ownership of a table group out of a shared database in four phases
- Prove a new part with branch by abstraction, a parallel run and store waves before it takes over
The everyday picture
A busy restaurant needs a new kitchen, but it cannot close. Dinner service runs every night, and the festival week is fully booked.
So the owner rebuilds one station at a time. First the dessert station, because it is small and nothing else depends on it. A temporary counter stands next to the old one while the new one is built. For a week, both stations make the same dessert, and the chef tastes both. Only when the new one matches does the old one go. Nobody touches the grill in festival week. The temporary counters are planned, paid for, and removed at the end.
Replacing a legacy system works the same way. You pick the order, you keep the old part working until the new one has proved itself, and you budget for the temporary pieces that let both run side by side.
Start from outcomes, not feature parity
A legacy system is one the business depends on and finds hard to change. That makes it valuable, so the goal is never "replace it". The goal is an outcome the business can measure: weekly releases for buyers, a stock report that never blocks goods receiving, a partner price change that reaches the Partner app in 5 minutes. You wrote those as quality attribute scenarios in Quality attributes and constraints. They are the only reason to spend money on a migration, and they tell you when to stop.
The most common trap is feature parity: "the new system will do everything the old one does". In their article series Patterns of Legacy Displacement, Ian Cartwright, Rob Horn and James Lewis describe it as a common cause of failed migrations. Writing down everything the old system does is a huge effort, much of it is no longer used, and a parity target pushes you towards one big switch day at the end.
So work capability by capability, and give each one of four decisions:
- Keep: it works, rarely changes and blocks no outcome. Leave it in the monolith.
- Improve in place: give it a clear module boundary inside the monolith (Monolith, modular monolith, microservices).
- Replace: it blocks an outcome and changes often. Move it out, slice by slice.
- Retire: nobody uses it. Prove that with usage logs over a full business cycle (a month-end and a festival), then switch it off.
Usage data settles arguments that opinions cannot. If the request logs show that a back-office screen had no visits in 90 days, it does not need a new version. If a report runs every morning in every store, it needs a better home.
Quick check
The buyers ask that the new pricing service "does everything the old pricing screens do, on day one". What should the architect do first?
Outcomes and usage decide what to rebuild. A full parity specification is the effort that sinks migrations and leads to a big switch day. A flat refusal ignores real needs; the buyers do need the screens they use every week.