Solution
We cannot safely change it
Legacy system modernization
The system works. That is precisely the problem: it works, it runs something the organization depends on, and it has reached the point where any change is expensive to make and frightening to release. Knowledge about it is thin, the tests are thinner, and the people who designed it have moved on.
A rewrite is the obvious answer and almost always the wrong one. It runs for years against a moving target, and the old system has to be maintained the entire time. The work that actually succeeds is finding the seams that allow parts to be replaced independently, and sequencing that replacement so the service keeps running throughout.
You are probably here because
- A change that should take days takes a quarter, and most of that is verification.
- Nobody can say with confidence what will break if a given component is touched.
- A dependency is going out of support, and the upgrade path runs through the whole system.
- A rewrite has been proposed, costed, and quietly deferred more than once.
What settles it
Finding the seams
Identifying where the system can be cut so a piece can be replaced without coordinating every other piece. Where no seam exists, creating one is the first piece of work, and it is what makes everything after it possible.
A defined end state
Modernization without a stated destination becomes permanent. Naming the architecture you are moving toward is what lets you tell whether a given step is progress or motion.
Strangler migration
New functionality built outside the old system, with traffic moved across piece by piece, so the old system shrinks rather than being switched off in one event nobody wants to schedule.
Capturing the rules before moving them
The behaviour that lives in the code and in a few people's heads, written down as something checkable. It is the only way to know afterwards whether the replacement does the same thing, and every step is sequenced around it so the business keeps operating throughout.
Track whether the system is safe to change yet, rather than how much of it has been replaced. The first milestone usually arrives years before the second, and it is the one the business feels.
how this gets delivered
Capabilities, cases, and further reading
Delivered through
- Systems Architecture
Designing architectural foundations that allow complex organizations to operate reliably and evolve safely.
- Platform Engineering
Reliable and maintainable platform foundations that support development and operations at scale.
Where we have done it
- Medlemsplatformen
A membership organisation runs a dozen processes that each used to keep their own truth. This is what it took to join them into one chain, and to keep a person at every point where value is granted.
- Garage CRM
Enquiry to signed rental in one system for a garage, parking and storage operator. What one administrator knew is now a shared process the whole team, and the AI, can work from.
- Vareoprettelse
Cuts the manual effort of onboarding products, and every published value can be traced back to its source.
faq
Frequently asked questions
- Should we rewrite or modernize incrementally?
- Incrementally, in nearly every case where the system is still running the business. A rewrite has to reach parity with a target that keeps moving while the old system is maintained in parallel, and the risk is concentrated in a single cutover. Incremental replacement spreads that risk and delivers value before the end.
- What if there are no tests and no documentation?
- That is the normal starting point. The first work is usually characterization: capturing what the system actually does at the boundaries you intend to cut, which gives you something to verify the replacement against. It is slower than it sounds worth being, and it is what makes the rest safe.
- Can this be done while we also deliver new features?
- Yes, and it usually has to be. The sequencing question is which seams to open first so that the features people are waiting for can be built outside the old system rather than inside it. Done well, the modernization is paid for by work the organization wanted anyway.
- How long does it take?
- Longer than a rewrite estimate and shorter than a rewrite. More usefully: the point at which the system becomes safe to change again usually arrives early, well before the last component has moved, and that is the milestone worth planning around.