Plan a controlled hosting migration
A safe migration is not a file copy followed by a DNS change. It is a controlled transition of application behaviour, data, integrations and operational responsibility.
- Author
- Intercube
- Revised
- Reading time
- 10 min read
01
Discover what production actually depends on
Documentation rarely captures the complete environment. Scheduled tasks may live in a control panel, credentials may be stored on the server, integrations may allowlist an IP address, and deployment steps may exist only in one person’s notes. Migration discovery should compare the intended architecture with the running system.
Inventory domains, DNS, certificates, runtimes, services, data stores, queues, search, media, scheduled work, external integrations, access, monitoring and backup behaviour. Record data volume and change rate. Identify which components can move independently and which require a coordinated cutover.
02
Build and rehearse the target environment
The target should be created from a reviewed configuration, then exercised with a representative copy of the application. A rehearsal proves more than whether the homepage loads. It should cover build and deployment, administrative workflows, background processing, email, third-party callbacks, search, cache behaviour and the most important user journeys.
Measure data-transfer duration and record every manual intervention. If the rehearsal requires undocumented fixes, incorporate them into the migration procedure or automated configuration before the production change.
- Reproduce the application stack and environment configuration.
- Test critical application and operational journeys.
- Measure database and file synchronization windows.
- Verify monitoring, logs, access and backup behaviour before cutover.
03
Design the cutover and the decision points
A cutover plan needs owners, timings and criteria. Define when application changes stop, when the final data synchronization starts, how DNS or routing changes will be made, which checks must pass and who decides whether to continue. Lowering DNS TTL can help, but it does not replace validation or account for every cached resolver.
Rollback also requires a data decision. Returning traffic to the old environment after new transactions have reached the target can create divergence. Agree in advance which failures justify rollback, which can be repaired in place and how data will be reconciled.
04
Keep the old environment until the new one is proven
Migration is not complete when DNS changes. Observe application errors, queue depth, scheduled work, search and cache behaviour, resource use and the business transactions that matter. Confirm that external systems see the expected endpoints and that support teams know where to investigate.
Retain the previous environment according to the agreed fallback and data policy. Once the new platform has passed the observation period, remove obsolete access and credentials, update documentation and formally transfer operational responsibility.
Migration control points
- Complete dependency and data-flow discovery.
- A representative rehearsal with recorded timings and fixes.
- Named owners and go, hold or rollback criteria for cutover.
- Validation that covers business processes and background work.
- A deliberate handover from the old operating model to the new one.