Replace the core system without stopping the company.
The rewrite has been on the roadmap for two years because starting it means someone owns the risk. We cut the system into pieces small enough that starting doesn't take a hero.
Book a callSounds familiar
We've been planning the replacement for two years. Every quarter it moves one quarter.
Two people understand the billing logic. One of them is contracting now.
Every release needs a freeze, a war room and a Saturday.
What's actually going on
A legacy system survives because it is load-bearing and because the risk of touching it has no owner. Everyone in the building can name the problem. Not one of them has the authority to accept the consequences of fixing it.
'How do we cut this apart' is the second question. The first is who gets to decide that a partial, imperfect step is allowed to ship. Until someone answers that, every plan stays a plan.
What we do
Map the system's real boundaries, not the ones on the diagram
Find the seams where it can be cut without a freeze
Get the risk of the first step named and owned
Ship the first slice to production, not to a staging branch
Hand over architecture the teams can extend without us
What this isn't
No big-bang rewrite. No two years before anything ships.
No reference architecture nobody will implement.
In your organisation
System boundaries copy team boundaries, always. If the modules can't be owned by the teams you actually have, the architecture won't survive contact with next year's org chart. So we design both, or neither holds.
What you end up holding
Core system replaced without a freeze
Architecture the teams can develop independently
Knowledge out of two people's heads
Related
Who you'd work on this with
Robert Vogt
Has been the engineer told the rewrite was too risky to start. Knows which of those risks was real and which was habit.
robert@unmade.ch
Jeremy Zahner
Systems architect by trade. Finds the seams in a system nobody ever drew a diagram of.
jeremy@unmade.ch