Migration acceptance checklist
Use the resourceA 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.
- Author
- Intercube
- Published
- Reading time
- 6 min read
Your migration acceptance checks
Download MarkdownWork through the checks with your developer and hosting engineer. Download an editable Markdown copy to record owners, evidence and sign-off in your project. On-page ticks stay in this tab and are not sent to Intercube.
0 of 19 checks completed
Agree the move
Owner: Application owner + Intercube
Define the application, cutover decision and people responsible before moving data.
Prove the target environment
Owner: Developers + Intercube
Check the actual application against its target services before changing public traffic.
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.
Switch traffic deliberately
Owner: DNS owner + Intercube
Make the routing change only after the target and the final data state pass acceptance.
Accept production and hand over
Owner: Application owner + operations
Close the migration when the application works and the operating responsibilities are clear.
01
Define acceptance before changing DNS
Write the acceptance criteria with the people who use and maintain the application. A shop needs checkout, payment callbacks and order processing checked. A customer portal needs authentication, permissions and document handling. Select the journeys that would make the move fail for the business, then assign a person to verify each one.
Record the current behaviour before the migration. That gives the team a comparison for application errors, response times and background processing. Keep the checklist with the migration plan so the decision to switch traffic rests on evidence rather than a successful server installation.
02
Keep data and routing decisions together
DNS caching affects when visitors reach the new environment. Cloudflare explains how TTL controls record caching; review the existing value before scheduling a change. Lowering an editable TTL does not remove copies that resolvers already cached under the earlier value.
The harder question is often where writes go during the move. Agree the final synchronization and the moment the new database becomes authoritative. If orders or other records have arrived after cutover, reconcile those writes before returning traffic to an older database. Changing DNS alone does not restore the correct data state.
03
Finish with an operating handover
A completed migration should leave a clear release route, useful monitoring, working backups and named support contacts. Agree who changes application code, who operates each managed service and how an incident is escalated. Record the final configuration and remove temporary access after the handover.
Intercube combines that operating model with the move itself. Our engineers prepare and maintain the infrastructure, while your team accepts the application. Preview environments provide a place to test, and the included deployment pipelines give future releases a repeatable route. Migration to Intercube managed hosting is included at no additional cost.
Keep the acceptance evidence
- Name an owner for each acceptance test.
- Verify integrations and background work as well as the website.
- Agree final writes, cutover and data-aware recovery.
- Review DNS caching before the routing change.
- Hand over monitoring, backups, access and the support route.