Legacy-to-RAPID migration & cutover
How a rebuilt product takes over from its legacy predecessor: client data migration, a parallel run, a rehearsed cutover with a rollback plan, client transition comms — and decommissioning, which is where much of the promised infrastructure saving is actually realised. StudyBuddy runs this playbook inside the three-month window, and the run itself becomes the reusable pack for CXsmart.
Client data migration
- Map from evidence, not memory. The source model comes from the legacy knowledge pack (produced by the code-archaeology skill); the target model follows data-model governance. The mapping document is reviewed by Data and the SME — buried semantics ("status 7 means lapsed-but-reinstatable") are exactly what legacy migrations get wrong.
- Agents write the scripts; rehearsal proves them. Migration scripts are agent-generated and rehearsed end-to-end on a full-size copy in a controlled environment, repeatedly, until reconciliation is clean — record counts, checksums and business-level totals (policies, claims, premiums) that an SME can confirm.
- Migrate minimally, under UK GDPR. Data moves under the same lawful basis it was collected; data past its retention period is not migrated — migration is the natural moment to apply retention rules rather than copy the problem forward.
- Executing against production data is irreversible. Senior Dev + Data authorise, with the rollback plan and verified backup in hand, per authorise the irreversible.
Parallel run
- Legacy remains the system of record while the new product shadows it — read-only mirroring, or dual-write with automated reconciliation, chosen per product.
- Exit criteria are set before the run starts: N consecutive clean reconciliation cycles, error rate below threshold, SLOs green, Support sign-off. A parallel run without exit criteria becomes a permanent second system — the most expensive possible outcome.
- Time-boxed. For StudyBuddy the window forces this anyway; for larger products the box is a decision, not an accident.
Cutover & rollback
- The cutover is a rehearsed script: timed steps, named owner per step, a go/no-go checkpoint with the people who can say no, a change freeze on the legacy side, then the routing switch.
- Rollback is designed before cutover, not improvised after: the trigger conditions, the data-reconvergence approach for anything written to the new system since the switch, and who decides. Rollback verification is one of the checks that is never waivable.
- Cutover is doubly on the irreversible list — a production deploy and a data migration. Both authorisations recorded, per the standard; Production Readiness must already be green.
Client transition comms
- Commercial owns the narrative, built from the client cadence pack and release comms standard: what changes for the client and when, what to check afterwards, what to do if something looks wrong, and the support route (support playbook).
- Client-facing comms are an authorised action — approved by the account owner before sending, per the irreversible-actions list.
Decommissioning DTS
The savings that fund the AI tooling are realised at switch-off, not at go-live — a legacy system kept "just in case" costs the same as one in use.
- A dated retirement schedule — environments, licences and infrastructure retired item by item, each retirement logged against the FinOps savings plan so the savings-vs-AI-spend view on the metrics platform shows realised numbers, not projections.
- Archive, then delete. Legacy data is archived per retention rules before anything is destroyed; deletion is irreversible and needs data-owner authorisation with the legal basis recorded.
- The rollback window gates the schedule — nothing is decommissioned that a rollback would need, until the rollback trigger period has lapsed.
Client contracts and DPAs may name the legacy system, its hosting location or its data processors. Commercial and legal must review affected agreements before cutover comms go out and before DTS switch-off — this is a human sign-off this playbook cannot schedule for itself.
StudyBuddy first
The first execution — inside the three-month window — is deliberately also the capture run: the rehearsal scripts, reconciliation checks, cutover checklist and comms templates are deposited as toolkit capital, so CXsmart's migration starts from a proven pack rather than a blank page.
Standards referenced: UK GDPR (lawful basis, retention), ITIL 4 (change enablement).