Switching Off The System Of Record, Without Touching Code On The Day

The storefront had already moved. The system of record had not. So the business was running on a new stack while the compensation plan, the commissions, the downline tree and the advocate back office all still lived on a platform the client was paying for and intended to leave, on a replica hosted somewhere else, with a contract end date nobody could state.

The hard part of switching something off is never the switch. It is that nobody knows what is still plugged into it. Legacy touchpoints were scattered across the storefront theme, a checkout extension, the backend, a back office application, about sixty six one off scripts and roughly thirty five cloud resources, and there was no inventory of any of it. One vendor contract was still being renewed purely because a single pipeline had never been ported off it.

We ran it as a program rather than a project: a board of 108 tickets in the client's own tracker, worked alongside their team in their own repositories. The first deliverable was not a change, it was an inventory. Every script classified. Every cloud resource listed. Thirteen credential surfaces enumerated so revocation could be a checklist rather than a memory exercise.

Then the archive, because you cannot delete what you have not kept. A read-only command in the backend snapshots the legacy database: 388.6 million rows across 154 tables, checksummed and byte verified against the stored copy, into the client's own immutable storage with a second custodian named on their side. The scoping is the part we are proudest of. A first pass planned around 106 tables. Triaging the flagged remainder added payment ledgers, regulatory certificate records and payout history that the first pass had missed, and we finished at 339 tables with zero tables left unclassified. Not zero unimportant. Zero unclassified. Every table either archived or explicitly ruled out by a human.

The downline history got its own export, written as nineteen new files with no change to any existing code, with plan, export and verify modes, resume, checksums, money control sums and tree invariants checked on every snapshot: 7.45 million rows, every verification pass green.

Both commands ran dry first. Plan mode, then a verified dry run against the live replica, then the real execution. That discipline is what let the cutover day itself be boring, which is the outcome we would put on the wall: the day the legacy platform came out of the live path, zero code changed. Vendor toggles and verification only, against a runbook with a go or no go gate and a rollback for each part. Rewriting that runbook surfaced six contradictions between decisions taken months apart, which is the argument for writing the runbook well before the day.

One thing we built and then unbuilt. A re-attribution feature was developed on both sides and staged as a draft, then fully reverted within two days when the other vendor committed to owning it natively. Nothing shipped that the client later had to pay to remove.

This was a joint team throughout. The client's own engineers carried a large share of the commits and their operations lead ran the reconciliation checks. We are not claiming it alone.