The legacy system is business-critical.
An outage or long feature freeze is not an option, so modernization must happen alongside live operations.
All services
Legacy modernization
Modernize without standing still. Step by step, while everything keeps running.
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.
Strangler figPHP 8 & GolangZero downtime
What you get
- An assessment with a risk and dependency map of your system
- A modernization plan in steps that each deliver value on their own
- Implementation while everything keeps running, every step individually reversible
- Test coverage and a pipeline, so the progress does not decay again
Scope & working together
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.
The starting point
Nobody wants to touch it. Everybody depends on it.
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 symptoms- A language or framework upgrade has been overdue for years.
- A change in one place breaks something in another.
- Deployments are a manual procedure with a checklist.
- Security updates are blocked because dependencies are out of date.
- New developers need months to make their first meaningful commit.
- Features get estimated and the estimate is never right.
Who this is for
For technical owners whose most important system cannot simply pause.
For CTOs and engineering leads with a productive application that has grown over years. It drives revenue or core processes but slows releases, hiring or growth.
The risk is already visible.
Dependencies expire, knowledge sits with a few people or every change creates unexpected effects.
You need a viable first cut.
The missing piece is not another target diagram but an order that reduces risk and delivers value early.
What I do
Secure it.
Retire it.
Hand it over.
01
An assessment built on facts
I 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.
02
A safety net before the first change
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.
03
Strangler fig instead of big bang
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.
04
Changing platform without interrupting operations
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.
05
Knowledge back into the team
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.
Specific cases
PHP project handoverFor when the developer or agency is gone and nobody knows how the system works any more. First an assessment that tells you where you stand, then step by step back into a state where changes are plannable again. A page of its own with the process and an assessment as the entry point.PHP upgrade & migrationIf the system runs on PHP 7 or an early 8, it gets no security updates. The effort rarely sits in the language itself but in dependencies without a successor and in missing tests. Separate page with the sequence, the tooling and an assessment as the entry point.Zend Framework and LaminasZend Framework was absorbed into the Laminas Project in early 2020 and is no longer developed under its old name. For ZF2 and ZF3 there is a largely mechanical route across, for ZF1 there is none. Separate page on which case means which effort.Symfony upgradeOnly 6.4, 7.4 and the 8.x line are maintained. The route runs version by version, and the effort sits in the deprecations and in bundles without a successor.Laravel upgradeLaravel 11 has been out of support since March 2026, Laravel 12 without bug fixes since August 2026. The jump inside the framework is small; what costs time are the packages with their own timelines and the PHP floor of 8.3. A page of its own on what really drives the effort.Shopware 5 to 6Not an update but a move: plugins, themes and customizations do not come along. What it costs is decided by the number of extensions, not by the size of the catalogue.
A system nobody wants to touch any more?
Let’s spend 30 minutes on the first step.
How it runs
No deadline with an open outcome.
Every step delivers value on its own and can be turned back. There is no moment where everything has to work at once.
STEP 01
A read in 30 minutes
Age, size, language version, what is blocking right now. After that you know whether an assessment makes sense.
STEP 02
Assessment, 2–3 weeks
Code, data, deployments and incidents. The result: a risk map and a modernization plan in steps.
STEP 03
Secure and retire
Tests and pipeline first, then the first cut. From week four the results are measurable.
STEP 04
Handover
Documented decisions, pairing, and an order for the steps your team takes on its own.
The other side
What the current state costs you.
The total is not printed below, because I do not know it. I do know the items, and in almost every case two of them already add up to a multiple of what the entry package costs. Do the maths yourself, then the number is yours.
- 01Changes that take too longHow many days does a change cost today that would take hours in a maintained system?
- 02Incidents in operationHow often does something stop, for how long, and who is tied up while it does?
- 03What keeps getting postponedWhich plans fail on the technology rather than on the market, and what would they be worth to you?
- 04HiringHow long will you look for someone with this stack, and how many weeks until they deliver?
- 05The rebuild you are considering insteadWhat figure is in that quote, and what happens to daily business while it is being built?
None of these items appears on an invoice, and together they usually cost more than the project that would end them. The free Legacy Risk Score turns them into a list with numbers.
The outcome
What changes afterwards.
Room to move again
Changes to the system become plannable. What used to be a risk turns into a ticket.
No standstill
The business keeps running throughout. No frozen backlog, no switchover day with an open outcome.
Results in weeks
The first visible progress arrives in weeks rather than quarters, because each step delivers value on its own.
Technologies I use
Proven tools. No experiments.
Languages
- PHP 8
- Golang
- Python
- TypeScript
- SQL
Frameworks
- Symfony
- Laravel
- Laminas
- Slim
Analysis
- PHPStan
- Psalm
- Rector
- Composer Audit
Tests
- PHPUnit
- Pest
- Characterization tests
- Xdebug
Data
- MySQL
- MariaDB
- PostgreSQL
- AWS DMS
- Doctrine
Platform
- Docker
- ECS Fargate
- Kubernetes
- AWS
- Terraform
Patterns
- Strangler fig
- Anti-corruption layer
- Expand and contract
- Feature flags
Operations
- GitHub Actions
- GitLab CI
- CloudWatch
- Blue/green
Who you are talking to
Directly with me as a freelancer. No agency in between.
I am Tim Rutte. More than 20 years in software development, most of it in systems that were already running before I arrived. You talk to the person who touches your code, from the first call to the handover.
- 20+years in software development
- 50+successful projects
- 2003working remotely since then
Working together
Working with your team or delivering independently.
You do not need to bring a particular setup. I adapt the engagement to how your company works and how much responsibility you want to hand over.
01Together
I work as part of your team.
If knowledge and responsibilities already sit with you, I join wherever additional experience is needed. Inside your workflows, in direct contact, without creating a parallel track.
- Integration into your sprints, reviews and technical decisions
- Pairing and knowledge transfer throughout delivery
- Code, documentation and operations remain fully with your team
02Independent
I take ownership of delivery.
If you lack time or capacity internally, I take a clearly scoped piece of work from technical clarification through to production. You set the objective and constraints; I take care of the path there.
- One point of contact from clarification through to delivery
- Regular, clear progress updates without day-to-day supervision
- A proper handover with documentation and a walkthrough
Whichever model you choose, you always know what is being built, which decisions are pending and what happens next. Billing follows the project and the model you prefer: clearly bounded work at a fixed price, longer or more open-ended work by time spent.
Continuity
Your system remains yours.
Independent delivery does not create dependency on me. Everything required to develop and operate the result stays in your environment from day one and remains ready for handover throughout the engagement.
Access stays with you.
Code, cloud accounts, pipelines and secrets live in your systems. Operations never depend on a personal account or credentials that only I control.
Knowledge does not stay in my head.
Architecture decisions, operating procedures and known risks are documented where your team will find them and kept current as the work progresses.
Someone else can take over.
Reproducible environments, automated deployments and regular handovers allow your team or another provider to continue without starting again.
The goal is not for you to depend on me permanently. The goal is for you to remain free to decide who develops the system next.
Client voices
What clients say afterwards.
“Great collaboration! Mr Rutte modernized our old PHP shop quickly and reliably, brought it up to date and built in many sensible improvements along the way. Communication was uncomplicated, deadlines were met – absolutely recommendable.”
Common questions
Before you ask.
Why not a complete rewrite?
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.
Can we still ship features during the modernization?
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.
How long does something like this take?
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.
What if we have no tests?
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.
Is there a quick first assessment?
Yes. The free Legacy Risk Score 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.
Terms that come up here
Strangler figTechnical debtAnti-corruption layerFeature flagModular monolithExpand and contractBus factorEnd of lifePHP upgradeZend FrameworkBrownfield and greenfieldBig bang migrationLegacy codeCharacterization testsTest coverageRefactoringMonolithMicroservicesData migrationAPI firstReplatformingContainerCI/CDDatabase indexRunbookPatch management
To the glossaryOther services
What else I help with.
Backend development
Backends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn moreAWS migration
From your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreReducing AWS costs
I find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreImproving AWS resilience
So that a single fault does not take the whole application with it: dependencies and single points of failure identified, recovery rehearsed rather than documented, changes delivered as Terraform.
Learn moreAI in production
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreProcess automation
Replacing 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 more