Rewrites fail. Standing still does too. I modernize grown systems in small, always reversible steps: operations keep running, the team keeps shipping features, and the first measurable results arrive in weeks rather than in two years.
The assessment is a self-contained two to three week engagement. Modernization then runs in stages, pausable at any time without leaving anything half finished.
Remote from Germany. Straight with me, no agency in between.
Legacy rarely means old. Legacy means changes are expensive, risky and hard to predict. There are no tests that inspire confidence, no documentation that is accurate, and the knowledge about the critical parts lives in two people’s heads.
The obvious answer, rebuilding everything, is the most expensive one. A rewrite competes with day-to-day business for two years, has to reproduce behaviour nobody fully understands any more, and delivers no value until the switchover. So I work differently: the old system stays in operation and gets retired piece by piece.
Typical symptomsI read the code, the database, the deployments and the incident history. Out of that comes a map: what is business critical, what is genuinely broken, what looks worse than it is. Ranked by risk and business value, not by how pretty the code is.
Before anything gets changed, protection goes in: characterization tests for the critical paths, a reproducible environment, and a pipeline that finds errors before customers do. No net, no rebuild.
New functionality grows alongside the old system and traffic moves across gradually. Every step is small, measurable and reversible. If something does not work we turn it back, without a project crisis and without a crisis meeting.
Databases move with replication and switchover windows measured in minutes, applications get containerized, infrastructure lives in Terraform. Every step has a rollback path, rehearsed before it is needed.
I work in pairs and document decisions where people will actually look for them. At the end your team should be able to carry on, rather than having to book me again.
Every step delivers value on its own and can be turned back. There is no moment where everything has to work at once.
Age, size, language version, what is blocking right now. After that you know whether an assessment makes sense.
Code, data, deployments and incidents. The result: a risk map and a modernization plan in steps.
Tests and pipeline first, then the first cut. From week four the results are measurable.
Documented decisions, pairing, and an order for the steps your team takes on its own.
Changes to the system become plannable. What used to be a risk turns into a ticket.
The business keeps running throughout. No frozen backlog, no switchover day with an open outcome.
The first visible progress arrives in weeks rather than quarters, because each step delivers value on its own.
Because in most cases it fails. It competes with day-to-day business for years, has to reproduce undocumented behaviour, and delivers no value until the switchover. Retiring step by step is less spectacular, but it delivers earlier and can be stopped at any point. I have written up the reasoning in more detail in a separate article.
Yes, and that is part of the approach. New functionality preferably gets built in the new part of the system. That way every feature pays into the modernization instead of competing with it.
It depends on size and condition. What is defensible: an assessment in two to three weeks, first measurable results from week four. After that the modernization runs in steps whose order you can change or pause at any time.
That is the normal case. The first step is then characterization tests: they capture what the system does today, not what it ought to do. That gives you a net that makes behaviour changes visible before anyone touches the code.
Yes. The free system check is a structured questionnaire covering release capability, safeguards, knowledge distribution and technical debt. You get a PDF report with a risk assessment and recommended actions, with no sales call attached.
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreReplacing manual workflows with real systems: wired into the software you already run, with permissions and an audit log instead of a chain of tools.
Learn moreI find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreFrom your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreBackends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn more