Modernization
Make an ageing system safe to change again
The application still runs the business. That is exactly the problem: it is too important to replace casually and too fragile to change quickly. Modernization is the work of making change cheap again, one deliberate step at a time.
You might recognise one of these
- “A one-line change takes three weeks and nobody can explain why.”
- “Two people understand this system, and one of them is leaving.”
- “We have been quoted a rewrite. It is a very large number.”
What we do about it
Legacy is rarely one problem. It is an accumulation: an architecture that grew without standards because nobody had time to set them, tests that were never written because the deadline was real, a deployment process that works but that nobody wants to run on a Friday, and institutional knowledge concentrated in two people.
None of that is fixed by a new framework. It is fixed by identifying the specific things that make change expensive here, and removing them in the order that reduces risk fastest.
So we start with an assessment — the code, yes, but also the deployment pipeline, the environments, the dependency situation, and the way work moves from idea to production. Frequently the binding constraint turns out not to be the code at all. A team that cannot deploy confidently will be slow regardless of how elegant the architecture is.
What comes out is a roadmap sequenced by risk reduction, with a clear build, refactor, replace or retain call on each significant component — including the components that should simply be left alone. Not everything old is a problem. A stable module that rarely changes and does its job is not technical debt; it is an asset with an unfashionable implementation.
Then we do the work, incrementally, with the system in production the whole time. Value arrives continuously instead of at the end of a two-year programme, and you can stop after any phase and still be better off than when you started. That last property is what makes modernization a defensible investment rather than an act of faith.
For technical readers
In practice the first three items are almost always the same: get a repeatable build and an automated deployment; put characterisation tests around the modules you are about to change; and remediate unsupported framework versions and vulnerable dependencies. Only then does structural work — extracting modules, introducing clear boundaries, moving to a modular monolith — become safe enough to be worth starting.
We prefer a modular monolith as the target for most business systems. Microservices earn their operational cost when independent scaling, independent deployment or genuine team-ownership boundaries demand them. Adopting them to fix a code-organisation problem converts a refactoring exercise into a distributed-systems problem, which is a poor trade.
The order we work in — risk reduction first
-
Make it deployable
A repeatable build and automated deployment — the highest-leverage fix, before anything else.
-
Put tests around change-prone code
Characterisation tests that pin existing behaviour, so change stops being a gamble.
-
Remediate versions and dependencies
Unsupported frameworks and vulnerable packages — dull, bounded, and unblocking.
-
Establish module boundaries
Clear ownership, enforced by tooling in CI rather than by good intentions.
-
Strangle only what needs it
Replace the components with a real reason — in production throughout, no big-bang rewrite.
Capabilities
What this covers
Architecture assessment
What actually makes change expensive here, evidenced with specifics rather than adjectives.
Incremental migration
Strangler-fig replacement, module by module, with the system in production throughout.
Modular restructuring
Clear boundaries and ownership. A modular monolith first; microservices only where the operational cost is justified.
Test and quality recovery
Characterisation tests around the parts you are about to touch, so change stops being a gamble.
Cloud and DevOps
Repeatable builds, automated deployment, environment separation, observability, infrastructure as code.
Security and dependency hygiene
Unsupported frameworks, vulnerable packages, secrets in configuration files, and the rest of the accumulated debt.
Deliverables
What you end up holding
Tangible artefacts, not a verbal summary. You keep all of it.
- Architecture findings with system context and dependency diagrams
- Code and maintainability observations, with specific evidence
- Security and operational risk register
- Deployment and DevOps assessment
- Build, refactor, replace or retain recommendation per component
- Prioritized roadmap sequenced by risk reduction per unit of effort
- Modernization scorecard with a benchmarked score
- Estimates for the first three items, so the roadmap is actionable
How the engagement runs
Typical shape and duration
-
Assess — 2–3 weeks
Fixed fee. Codebase, architecture, deployment and delivery process, plus interviews with the people who maintain it.
-
Stabilise — 4–8 weeks
The highest risk-reduction items first: usually deployment automation, test coverage around change-prone areas, and dependency remediation.
-
Migrate — ongoing
Module by module, in production, with rollback available at every step. Value lands continuously rather than at the end.
-
Sustain
Managed support, or a handover to your team with the runbooks and reasoning to keep it going.
Where it usually starts
Modernization and Architecture Assessment
A structured review of an existing application, architecture and delivery process, followed by a prioritized modernization roadmap and clear build, refactor, replace or retain recommendations.
- Duration
- 2–3 weeks
- Format
- Remote, with codebase and environment access
Questions we are usually asked
Should we just rewrite it?
Usually no. Rewrites tend to cost more than predicted, take longer than promised, and reproduce the original problems in a newer framework — because the original constraints are rediscovered one at a time. Incremental modernization delivers value continuously and can be stopped at any point. When a rewrite genuinely is right, we will show you the arithmetic rather than assert it.
Can you modernize without stopping feature work?
Yes, and you generally should not stop it. A modernization that freezes the business tends to get cancelled halfway. We sequence work so that feature delivery continues, usually getting faster as the early items land.
Our team built this. Will this be a criticism of them?
No. Almost every system we assess got this way through reasonable decisions made under deadline pressure with the information available at the time. We assess the system and the process, and we share findings with the team before executives see them.
What if it is not .NET?
Architecture, delivery practice and operational maturity transfer across stacks, and we assess those regardless. For deep language-specific work outside our competence we will tell you rather than bluff.
How do you decide what to do first?
Risk reduction per unit of effort. The first items are usually unglamorous — a reliable deployment, tests around the code you change most, a dependency upgrade — because they make everything after them cheaper and safer.
Do we have to commit to the whole roadmap?
No. It is sequenced deliberately so that stopping after any phase leaves you better off than when you started.