Validation and handover

Loading the data proves the movement finished. The platform is ready when its data, workloads, security controls and support arrangements have all been accepted.

Agree acceptance criteria before rehearsal, and name who accepts each result. Any exception carries an owner, a due date and a stated effect on release.

Layer the reconciliation:

• Technical — objects and partitions, row counts, checksums where they are worth the cost, rejected rows, orphaned records, schema contract conformance.
• Business — critical reports, semantic definitions and representative results compared against the source, supervised by the relevant data owner.
• Workload — critical queries, batch and concurrency against the agreed thresholds.
• Security — access, encryption, credentials and audit, tested under real roles.

The validation catalogue gives a starting set with owners.

Hand over deliberately. Monitoring, alerts, support routes, defect handling, runbooks and retention of migration evidence. Define the stabilisation period and its exit conditions. Give the service owner an explicit list of accepted defects and outstanding work — a handover that pretends there are none is a handover that will be handed back.

Retire the source only after the new platform has been stable for the agreed period and every retention obligation has been met. The pressure to decommission early is financial and it is always there; the cost of having been wrong about it is much larger than the saving — and, for the reason set out in the next section, you may need the old platform to be readable for a good deal longer than the migration plan assumes.