Cutover engineering
The choreography of the switch: connection draining, a read-only window measured in seconds, TTLs lowered days ahead, and a written abort trigger. Every step is timed on a clone first.
Timed cutover runbookMigration
Same logins, same links, new platform
For teams forced off a cloud, a database engine or a vendor while the system stays live. We move in rehearsed stages, reconcile both sides, and cut over inside a read-only window measured in seconds.
- Rehearsed cutover
- Reconciled row by row
- Rollback until decommission
- Fixed scope
The move is not the hard part
Copying data from one system to another is a solved problem. What is not solved is everything hanging off the old system: the sessions people are logged into, the links in two years of emails, the webhook a partner points at, the card token that keeps a subscription alive, the report that runs at 06:00 and would fail silently. None of that appears in a data model, and all of it breaks on the day.
Migrations are rarely chosen. A licence renewal reprices overnight, a managed service reaches end of life on a published date, an acquisition forces two stacks into one, or a cloud bill stops making sense at your utilisation. That deadline is usually the only fixed thing in the project, which is why the plan has to be built backwards from it. The expensive failure is not a bad cutover; it is a migration that never finishes, where the straightforward parts move and the awkward remainder stays behind forever.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| Old system stays writable throughout | Continuous sync, not one export | Log-based change capture with replay |
| The contract end date cannot move | Plan built backwards from notice | Cancellation is the last task |
| Inbound callers are outside your control | Old URLs must keep answering | Redirect map and versioned shims |
| Every row must be accounted for | Cutover gated on a diff | Reconciler on counts and totals |
| A failed cutover needs an exit | Old system stays authoritative | Reverse replication until decommission |
In scope
- Moving the system between platforms unchanged
- Data movement, reconciliation and cutover
- Identity, session and billing carryover
- Decommission and cancellation of old contracts
Not in scope
- Rewriting the application while it moves
- New features on the new platform
- Reshaping the data model itself
Handled by
- Legacy Application ModernizationRewrites and behaviour changes, after the move.
- Data ModernizationSchema redesign, warehousing and pipeline rebuilds.
What we build
Data movement and parity
Bulk load, then log-based change capture so the target stays current while the source keeps taking writes. A reconciler compares counts, checksums and business totals; cutover waits on that diff.
Reconciliation reportsIdentity and session carryover
Moving auth providers without a mass password reset. Where hashes export, we import them; where they do not, users migrate on first login. MFA enrolments and social logins are mapped separately.
Identity cutover planInbound contract preservation
Everything pointed at the old system and outside your control: partner webhooks, API clients on old versions, SFTP drops, indexed URLs. Each gets a redirect, a shim or a deprecation date.
Redirect and shim mapBilling and token migration
Recurring revenue is the least forgiving thing to move. Card vaults transfer processor to processor under the compliance path both sides accept; subscription anchors and proration rules are rebuilt to match.
Subscription parity reportRuntime and version moves
Runtimes, frameworks and database engines that must move without changing what the software does: a major version with breaking syntax, an abandoned upgrade path. Behaviour gets pinned by tests, then moved.
Behaviour pinning suiteHow the work runs
- 01Weeks 1–2
Dependency and exit audit
We trace everything that talks to the system in both directions: clients, jobs, webhooks, reports, integrations, and read the old contract for notice periods, egress terms and export formats. What cannot move is found now.
You getDependency map and exit terms
- 02Weeks 3–4
Target and first load
We stand the destination up as code, load a full copy of production into it, and time that load for real. The first restore names the indexes, blobs and time zones that will cause trouble.
You getTarget environment as code
- 03Weeks 5–9
Sync and reconcile
Change capture keeps the target current while the old system stays live and writable. A reconciler runs on a schedule against counts, checksums and the totals your finance team recognises. Differences are fixed or explained.
You getLive replica with parity report
- 04Weeks 10–14
Rehearse and cut over
We rehearse the whole switch on a clone at least twice, clock running, until timings stop surprising anyone. On the day: drain connections, short read-only window, fixed checklist, release traffic. Rollback stays available until decommission.
You getSigned cutover and decommission record
What you are handed
- Dependency map of every inbound caller
- Exit terms, egress and notice-period summary
- Target environment defined in infrastructure code
- Change capture pipeline with replay
- Reconciliation reports on counts and totals
- Identity and session cutover plan
- Redirect map and API compatibility shims
- Timed cutover runbook with abort criteria
- Reverse replication and decommission record
Typical stack
Replication
DebeziumAWS DMSAzure DMSKafkapglogicalrclone
Target platform
PostgreSQLMySQLMongoDBKubernetesTerraformS3-compatible storage
Traffic control
NGINXEnvoyCloudflareRoute 53HAProxyUnleash
Verification
Great ExpectationsPercona ToolkitPlaywrightk6GrafanaOpenTelemetry
The calls we make, and why
Big-bang cutover over a weekend, or a phased migration?
Phased, with both systems live and reconciled throughout.
A weekend cutover concentrates every unknown into the four hours you have least ability to think clearly. Phasing spreads the same unknowns across weeks where each one can be found, fixed and re-tested while the old system still serves traffic.
We’d choose otherwise whenthe system has a genuine quiet window and cannot run two writable copies, like a single-writer ERP.
Should we lift and shift, or improve the system while we move it?
Move it unchanged first, then improve it on the new platform.
Changing behaviour and platform in the same step makes every mismatch an argument about which side is wrong, and reconciliation stops being a safety net. Once the move is done, the old system is still there to compare against.
We’d choose otherwise whenthe destination cannot host the behaviour at all, so it is rewritten and proved on the old platform.
Dual writes from the application, or change data capture?
Change data capture, never dual writes from the application.
Dual writes look simpler until the second write fails and you own a silent divergence with no record of when it started. Capture reads the database log, so it survives crashes, replays cleanly, and leaves the application code untouched.
We’d choose otherwise whenthe source exposes no log, as with some hosted SaaS platforms; then we add periodic full comparison.
Do we migrate all the historical data, or start clean?
Migrate what is queried, archive the rest, delete nothing.
Most estates carry years of records that nothing reads but legal will not let you drop. Moving them inflates load times, egress and every rehearsal cycle for no operational gain, and a cutover is the worst possible moment to be deleting anything.
We’d choose otherwise whenthe archive is genuinely hot, or a regulator requires it live and searchable in place.
This fits if
- A contract, licence or end-of-life date is forcing the move
- You cannot take a maintenance window long enough to move
- Users, partners and integrations must not notice anything changed
- An acquisition has left you running two of everything
- Your cloud bill no longer matches the workload underneath
Look elsewhere if
- You want the move to also fix everything done badly
- Schema changes on the old system cannot pause at all
- The deadline is under thirty days and cannot slip
EngagementFixed-scope migration
Typical length6–14 weeks per system
How it startsA paid two-week audit: we map every dependency, time a full data load, and price the cutover.
Questions we get asked
What happens if the cutover fails?
We roll back to the old system, which is still running and still authoritative until we say otherwise. The runbook names abort criteria in advance: a specific error rate, a specific lag figure, a specific failed check. Reverse replication carries any writes that landed on the new side back.
What drives the cost, and what usually gets missed?
Scope is fixed after the audit, so the number comes from what we find rather than a rate card. The drivers are inbound integration count, whether the source can replicate, and how much undocumented logic sits in stored procedures and scheduled jobs. The line most budgets miss is the parallel run: both platforms plus egress for the whole overlap.
Will our users have to log in again or reset passwords?
No password resets and no new credentials, though anyone signed in at cutover signs in once more, because sessions issued by the old provider stop being trusted. Where the source exports password hashes we import them; where it cannot, we verify against the old provider on first login. MFA enrolments and social logins are mapped separately.
Who owns what we build, and does the new platform lock us in?
All of it is yours: source, infrastructure code, runbooks and reconciliation tooling transfer in full, with a 30-day warranty on defects. Lock-in is a real trade: every platform choice buys convenience with portability. We keep the exit cheap where it is cheap, and where a managed service is better we take it and record what leaving would cost.
Can you migrate us if we do not have a test environment?
Yes, and building one is part of the work, not an extra. The first phase turns a production backup into an environment we can rebuild on demand, which is what makes your rollback plan real rather than theoretical. Rehearsing against that copy is where a migration finds its problems: the batch job with no owner, the expired sandbox credential.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.