Example acceptance packet for an application migration

What this example is

This is a synthetic handover outline for moving one small application's test copy to an agreed target. No files were migrated for this example, no timing is measured and no client sign-off exists. It shows the fields that should become real evidence during an authorised delivery.

• Request: exact source and target, included application/database/files and excluded external systems.
• Baseline: dependency versions and login, read, write and file-access checks on the safe source copy.
• Target: matching checks on the new isolated copy with permitted synthetic data.

Evidence before a live switch

Each named business flow has an expected result and a retained redacted test result. Include the restore rehearsal, required roles/extensions and uploaded-file checks. Identify all external effects that were disabled. A local green build cannot substitute for the agreed target runtime result.

• Record changed code, settings and migrations.
• Keep independent review findings and dispositions.
• Explain every excluded path rather than silently treating it as tested.

Write boundary and recovery

Name when the source stops accepting writes and when the target starts. Record how the authorised operator would recover if the target fails after receiving new data. Returning code or DNS to the source is not enough if the databases have diverged. If recovery is unresolved, the live switch remains blocked.

• Customer approves the cutover and account actions.
• Secrets and production backups stay on approved owner-held routes.
• Acceptance, invoice and cash receipt are separate records.

Use it to evaluate a proposal

Ask which checks will prove the business still works and what cannot be reversed automatically. The answer should identify actual boundaries, not merely promise no downtime. A completed packet would contain real run evidence; this example remains an inspectable specification, not a runnable migration fixture.