SEC-01
Least-privilege access
Each integration gets the narrowest scope that lets the work function. Nothing more.
Stage 02 · BuildLegacy modernization
Modernizing software you cannot switch off
The system still runs the business. That is the problem — it cannot be paused, and the people who built it have gone. Modernization is a sequence of survivable steps, not a rewrite.
- Access stays in your accounts
- Every change on record
- Written, auditable deliverables
- C01Map what it actually doesIn scope
- C02Find the seamsIn scope
- C03Put a facade in frontIn scope
- C04Move one capability at a timeIn scope
- C05Migrate the data honestlyIn scope
- C06Decommission deliberatelyIn scope
In short
Legacy modernization is the staged replacement of a system that the business still depends on, done without an outage and without a full rewrite. The usual approach is to put a facade in front of the old system, move one capability at a time behind it, and keep both running until the last consumer has moved. A full rewrite is the option that fails most often, because it restarts a clock that has already been running for years and rediscovers every requirement the original team learned the hard way.
- 5
- Warning signals
- that say this is the work
- 6
- Controlled steps
- each ships something you keep
- 4
- Written refusals
- lines we do not cross
Self-audit
Signals this is the work
Tick the ones that are true where you are. Nothing is sent anywhere — the answer is for you, not for us.
If more than one of these is true today, the problem is usually further along than it looks from the outside. That is not a sales line; it is what the cost of waiting does.
Readiness checklistLegacy modernization
0 of 5 true
Nothing ticked yet.
How we do it
The sequence
Each step ships something you keep. You can stop after any of them and still be better off than when you started.
Start with step one- 01
Step 1 of 6
Map what it actually does
Not what the documentation claims. We trace the real behaviour, including the undocumented rules that someone added for one customer in 2014 and that the business now depends on.
- 02
Step 2 of 6
Find the seams
Modernization is only survivable where the system can be cut. We identify the boundaries where a capability can be lifted out without dragging the rest with it.
- 03
Step 3 of 6
Put a facade in front
New consumers talk to an interface, not to the old system. That lets the thing behind it change without every caller changing at the same time.
- 04
Step 4 of 6
Move one capability at a time
Each step ships, runs in production alongside the old path, and is reversible. Nothing is a point of no return.
- 05
Step 5 of 6
Migrate the data honestly
Legacy data is never as clean as anyone expects. The cleanup is scoped as its own piece of work rather than discovered mid-cutover.
- 06
Step 6 of 6
Decommission deliberately
The old path is switched off only when nothing is calling it, and the check for that is evidence rather than confidence.
Assurance
Secured and auditable by default
These controls apply to every engagement, including this one. They are engineering decisions, not a certificate on a wall — and you can check each of them.
SEC-02
Credentials in your name
Accounts and keys live in your tenancy. You can revoke any of them without asking us.
SEC-03
Every change logged
Changes, deployments and incidents leave a written trail you can audit.
SEC-04
Restores tested, not assumed
A backup only counts once it has been restored. We test, and we report the result.
SEC-05
Separate environments
Development never touches production credentials or unmasked customer data.
SEC-06
A documented exit
Runbooks written as we go. Leaving means revoking our access — nothing is held back.
What we will not do
The refusals
The things we turn down are a better description of how we work than the things we sell.
Standing commitmentsLegacy modernization
- 01
We will not: Recommend a rewrite because the code is unfashionable. Old is not the same as broken.
- 02
We will not: Modernize a module nobody uses, because it is the easy one to start with.
- 03
We will not: Move to microservices to solve a problem that was never about deployment topology.
- 04
We will not: Promise a cutover date before the data quality is known.
Questions
Before you ask
Anything else, ask on the first call. There is no charge for working out whether this is the right fit.
Talk about a problemHow long does legacy modernization take?
It depends almost entirely on how separable the system is, not on how large it is. A system with clear module boundaries can be moved capability by capability over a few months. A system where everything reads and writes the same tables takes longer, because the first work is creating boundaries that never existed. The mapping stage tells you which of those you have before you commit budget.
Should we rewrite instead?
Rarely. A rewrite means running two systems for as long as it takes, keeping them at feature parity while the business keeps changing, and rediscovering rules nobody wrote down. It is the right call when the platform is genuinely dead — unsupported language runtime, no hosting path, no security updates — and even then the migration is staged.
Can you modernize without downtime?
Usually yes, and that is the point of the facade-and-strangle approach: both paths run at once, traffic moves gradually, and rollback means pointing traffic back. Genuinely atomic changes — a database engine migration, for example — may need a window, and we say so early rather than late.
What if we do nothing?
That is a legitimate option and worth pricing. Some legacy systems are stable, cheap to run, and touched twice a year. The cost of doing nothing is only unacceptable when it is blocking revenue, creating security exposure, or making every other project more expensive.
Tell us what isn’t working.
One process, one system, one decision you are stuck on. An engineer replies within one working day with how we would approach it, and whether it needs building at all.