We pair our engineers with yours and set an end date on every parallel run. Part of a new back-end goes into production in the first quarter, with the same familiar interface, and the old system gradually shrinks until there is nothing left of it.
What is in it
Five capabilities, and an end date on every parallel run.
Reading the system
Before anything is proposed. The reading is a deliverable your engineers keep, because the knowledge is the asset.
Behavior characterization
Tests written against what the system actually does, including the parts nobody meant. Bugs do not get promoted to features by accident.
Facade and routing
One stable interface in front of both systems, so traffic can move a capability at a time without anything downstream noticing.
Incremental delivery
Capability by capability, in production, with your engineers in the pairs from the first week rather than at handover.
Retirement of the old path
Every parallel run has an end date in the plan. Two codebases forever is worse than either one of them.
Behind a facade
The old system shrinks. It is never switched.
Nothing moves on a single night
Traffic moves one capability at a time behind an interface that does not change, so there is no weekend on which the business is asked to hold its breath. The strangler pattern is not ours and we make no claim on it; what we bring is the discipline of writing the retirement date into the plan at the start, when it is still cheap to mean it.
What you receive
| Artifact | Form |
|---|---|
| The characterization suite | Tests that pass against the old system before anything moves |
| The facade | Routing rules, in your repository, owned by your team |
| Migrated capabilities | In production, dated, one at a time |
| The retirement plan | With the date the old path is switched off |
Questions we are always asked
Four of them, answered the way we answer them on the phone.
Can you work in our stack?
We read it before we propose anything, and the reading is a deliverable your team keeps. If we cannot understand it well enough to characterize its behavior, we say so rather than quoting around the gap.
How long before something is actually in production?
A capability in the first quarter, not the third year. If a plan cannot put something real behind the facade inside three months, it is a rewrite wearing different words and we will tell you that.
What happens to our engineers?
They are in the pairs from the first week. Handover is not an event at the end, because a handover event is how a team ends up maintaining a consultancy architecture it never chose.
What if the parallel run never ends?
Every one of them has an end date written into the plan at the start, when it is still cheap to mean it. Two codebases forever is worse than either of them alone, and it is the most common way this work fails.
Case studies
Programs in this area, described by what they were rather than by who paid for us.