Product & Technology Problems
When the debt is already showing up as recurring incidents and fragile releases.
What we improve
The system still earns its keep. Changing it has become dangerous.
Most products in this position do not need a rewrite. They need someone who can assess the risk, decide the order, and protect delivery while the system evolves.
Symptoms
What you are seeing
- Delivery has slowed and nobody can point to a single cause
- Small changes in certain areas produce unexpected failures
- Dependencies are unsupported, and upgrading them is its own project
- Test coverage is thin exactly where the risk is highest
- Frameworks in use are several major versions behind
- Deployments are timed nervously and rolled back sometimes
- One or two people understand the critical parts
- The team has proposed replacing the system outright
The default answer is usually wrong
Why 'rewrite everything' is rarely the right call
A full rewrite asks the business to fund a long period with no new customer value, while the existing system still needs maintaining. It also assumes the current behaviour is fully understood, which is usually the very thing that has been lost.
In most systems the risk is concentrated. A small number of modules carry most of the danger, and the rest is serviceable. Establishing which is which is a diagnosis, and it is cheaper than the rewrite it usually prevents.
Sometimes replacement genuinely is right. When it is, it should be a decision made on evidence, sequenced deliberately, and scoped to the part that warrants it, rather than adopted as a default because the current system is unpleasant to work in.
Approach
How Kendoo leads modernization
System assessment
What the system does, where the behaviour is understood, and where knowledge has been lost. Assessed against evidence rather than the team's impressions of it.
Risk map
Which parts are genuinely dangerous to change, what it would cost the business if each failed, and which risks are being carried unknowingly.
Target architecture
A destination that is reachable from where you actually are, rather than the architecture you would choose starting today.
Modernization roadmap
Sequenced so each stage reduces risk and leaves the system releasable. No stage requires a pause in feature delivery.
Incremental migration
Change delivered in pieces that can be verified and, if necessary, reversed. Big-bang cutovers are avoided wherever the architecture allows.
Quality gates and reporting
Agreed criteria for each stage, and a monthly written report on what moved, what did not, and which risks changed.
Decision criteria
Five things to do with any component
Applied deliberately, per component, with the reasoning recorded.
-
Refactor
The behaviour is understood and valuable, the structure is the problem. Improve it in place, under test.
-
Replace
The behaviour is understood but the implementation cannot carry where you are going. Rebuild that part, not the system.
-
Isolate
It is risky and poorly understood, but stable. Put a boundary around it so it stops constraining everything else.
-
Retire
It serves a need that no longer exists, or serves very few. Removing code is the cheapest modernization there is.
-
Leave it alone
It works, it is not blocking anything, and touching it would spend risk for no return. Often the correct answer, rarely the popular one.
Modernization and feature delivery, at the same time
The most common failure is treating these as competing budgets, which turns every planning session into an argument the technical side eventually loses.
The workable approach is to sequence modernization behind the roadmap: when a feature requires touching a risky area, that area is improved as part of the work. Progress on both comes from the same effort, and the debt reduction is visible in delivery rather than defended as a separate line item.
Outcomes
What changes
- Changes in previously dangerous areas stop producing surprises
- Deployment becomes routine rather than an event
- Dependency and platform risk is known and scheduled, not discovered
- Knowledge is spread beyond one or two people
- The rewrite conversation is settled on evidence
- Feature delivery continues throughout
Related
CTO on Demand
The engagement this sits inside, and what Kendoo is accountable for.
Results
How this work looks in practice, including a rewrite that turned out to be unnecessary.
Get a straight read on the rewrite question
Bring the rewrite proposal if you have one. Thirty minutes is usually enough to tell whether it is the right call.