# Migration acceptance checklist

A working homepage is only the start of migration acceptance. Use this checklist to agree what must work before traffic moves, who verifies it and what evidence closes the move. Intercube engineers can prepare the target environment and carry out your included managed hosting migration.

Source: https://intercube.io/knowledge/hosting-migration-checklist

Project / owner / date: ____________________

## 1. Agree the move

Owner: Application owner + Intercube

Define the application, cutover decision and people responsible before moving data.

- [ ] Record domains, runtimes, databases, files, workers, scheduled jobs and external integrations.
- [ ] Name the application approver, migration engineer and incident contact.
- [ ] Agree acceptance tests, the cutover window and the point at which the old environment can be retired.

Evidence / notes / sign-off: ____________________

## 2. Prove the target environment

Owner: Developers + Intercube

Check the actual application against its target services before changing public traffic.

- [ ] Check runtime and service versions, configuration, secrets and file permissions.
- [ ] Exercise login, search, uploads, checkout or the application's other critical journeys.
- [ ] Verify workers, scheduled jobs, outbound email, payment callbacks and integration allow-lists.
- [ ] Compare representative response times and error behaviour with the current environment.

Evidence / notes / sign-off: ____________________

## 3. Reconcile data and recovery

Owner: Data owner + migration engineer

Treat new writes and recovery as part of the move, not as work to discover afterwards.

- [ ] Verify database and file transfer using agreed counts, checksums or application-level checks.
- [ ] Confirm the backup location and demonstrate the agreed restore procedure.
- [ ] Agree how writes are paused or synchronized during the final transfer.
- [ ] Record rollback triggers, who decides and how writes made after cutover would be reconciled.

Evidence / notes / sign-off: ____________________

## 4. Switch traffic deliberately

Owner: DNS owner + Intercube

Make the routing change only after the target and the final data state pass acceptance.

- [ ] Review DNS records, existing TTLs, TLS certificates, proxy settings and canonical host redirects.
- [ ] Lower editable TTLs in advance where useful and allow earlier cached records to expire.
- [ ] Verify the final data sync and confirm that jobs run in only the intended environment.
- [ ] Approve the move, switch routing and test through the public hostname from outside the server.

Evidence / notes / sign-off: ____________________

## 5. Accept production and hand over

Owner: Application owner + operations

Close the migration when the application works and the operating responsibilities are clear.

- [ ] Repeat the critical user journeys on the public site, including a permitted end-to-end transaction.
- [ ] Check errors, queues, scheduled jobs, email and external callbacks after traffic arrives.
- [ ] Confirm monitoring, backup schedules, access, deployment ownership and the support SLA.
- [ ] Record acceptance and the agreed observation period before retiring the old environment.

Evidence / notes / sign-off: ____________________

## Plan your migration with our engineers.

Share your application, current hosting and the checks that matter to your business. We will prepare the move and the managed environment, with migration included at no additional cost.

https://intercube.io/start?interest=migration