Legacy Modernization
Your product works, that's the problem. It earns revenue, so you can't stop it, but every change takes longer and every deploy is a risk. I decompose legacy systems into maintainable services while the business keeps running. I've done it before: a Vaadin monolith into 12 independently deployable services, serving 50+ tenants, with zero downtime migrations.
Your monolith, decomposed and moved to the cloud, without downtime. The hard part of legacy work isn't writing new code, it's understanding a system nobody documented and changing it without breaking revenue. AI coding tools are useless here: they excel at blank repos and fail against fifteen years of undocumented business rules. This is engineering judgment work, and it's what I did for almost three years at a German B2B SaaS company.
Every deliverable, upfront.
System archaeology, trace and document what actually exists
Decomposition plan: service boundaries, shared domain interfaces, migration sequencing
Multi-tenant and identity architecture if you need it (I've designed for 50+ tenants)
Hands-on implementation of the first extractions, not just a slide deck
Zero-downtime migration strategy with rollback points
Documentation your team can continue from
How it runs.
Weeks 1–2, Archaeology: read the code, interview the team, map the real data flows. Deliver a system map that's more accurate than your internal docs.
Weeks 3–4, Plan: service boundaries, extraction order, risk register. The plan optimizes for shipping value early, not for architectural purity.
Weeks 5+, Extract: first service out, running in production, pattern proven. Your team continues with the playbook, or I keep going.
This is for you if…
Software companies whose 10+ year old core product resists change
Teams facing a rewrite decision and needing a third option
B2B SaaS platforms that grew into multi-tenancy the hard way
German SMEs can often fund part of this
This kind of engagement is frequently eligible for BAFA consulting funding (up to 50%) and, in NRW, the MID programme. Public funding runs through 2026. You apply, eligibility depends on your company; I'll point you to the right programme on the call.
01Do we have to stop shipping features during the migration?
No, and any plan that requires it should worry you. The work is sequenced so the monolith keeps serving traffic while services are extracted one at a time behind stable interfaces. I have run this on a platform serving 50+ tenants with zero-downtime cutovers.
02Should we rewrite instead?
Usually not. Rewrites fail because the old system encodes years of undocumented business rules nobody can restate, and the new one has to learn them all before it can replace anything. Incremental decomposition keeps revenue flowing while the knowledge transfers. If a rewrite genuinely is right for your case, I will say so.
03Can AI tools do this instead?
Not well. AI is strongest in an empty repository and weakest against fifteen years of undocumented rules with revenue running through them, because the relevant context does not fit in a context window and the risk tolerance is zero. I use AI heavily inside this work, but the sequencing and the judgment about what may safely move are the job.
04What do we get if we stop after the first phase?
A system map that is more accurate than your internal documentation, a decomposition plan with service boundaries and extraction order, and a risk register. That is deliberately useful on its own, so you are never locked in to continue.
Still unsure whether this is the right shape of work?
Book a call