Move hosting with a tested cutover and a realistic rollback plan
A hosting migration moves a working system, not just a folder. The difficult part is keeping data coherent while users, background workers and cached DNS answers may still reach different places. A clear cutover plan makes that transition reviewable.
The practical takeaway
Prepare and test the destination, define which system may accept writes, switch traffic deliberately and agree on the data boundary that makes a rollback safe.
Write the migration brief before copying data
Inventory the application release, database, uploaded files, secrets, scheduled tasks, mail, DNS and external integrations. Include queue consumers and callbacks from payment or identity services. Identify the person authorised to change each component. A successful website copy can still fail if a background worker continues processing on the old host or a webhook delivers to a retired endpoint.
Define the acceptance criteria in ordinary user terms: a customer can sign in, view a representative record, upload a file and complete a synthetic transaction using approved test integrations. Add administrative requirements such as backups, monitoring and scheduled tasks. Record the expected maintenance window and the latest point at which the team must decide whether to proceed or roll back.
Confirm destination resources and the selected hosting region before scheduling the move. Allow temporary room for archives, database imports and the application working set. If migration assistance is relevant to the purchased service, ask support to confirm its exact scope and dependencies. Do not infer that domain registration, every mailbox and all third-party settings move with a hosting order.
Prove the destination without changing public traffic
Create the destination using the intended software and application versions. Restore a rehearsal copy using the same method planned for the final transfer. Test under the real application hostname through a controlled local override or an approved staging arrangement, so host routing and HTTPS certificate behaviour are exercised. Visiting an IP address alone does not prove that the production hostname will work.
Keep the rehearsal isolated from live side effects. Disable production email delivery, real payment actions, outbound webhooks and scheduled jobs until their behaviour has been reviewed. Verify filesystem permissions, upload handling, database connectivity and the required application routes. For WordPress, pay attention to stored site URLs and plugin behaviour; replacing arbitrary database text can damage serialised values.
Perform a restore rehearsal and keep the elapsed time. A first test that needs two hours of data import cannot fit an unexplained fifteen-minute final window. Decide whether the application needs a longer maintenance period, a supported incremental transfer or a different design. The migration plan should reflect measured work rather than treating the public DNS change as the whole project.
Make one system authoritative for writes
| Phase | Write authority | Required evidence |
|---|---|---|
| Preparation | Existing production service | Destination passes isolated rehearsal checks |
| Final synchronisation | Writes paused or controlled by the migration design | Database, uploads and queues reach a recorded boundary |
| Cutover verification | Destination only after acceptance | Requests and integrations reach the intended service |
| Rollback after new writes | Chosen after reconciliation planning | Recent accepted changes will not be silently discarded |
For a modest application, a planned read-only or maintenance interval can provide a clear final data boundary. Stop or pause the relevant writers, including workers and import jobs, then capture the final coherent database and file state. Record which queues or external events still need handling. A maintenance page that blocks browsers but leaves workers running is not a complete write freeze.
A design using continuous database replication requires its own supported failover procedure and careful validation. Do not improvise bidirectional synchronisation during a deadline. Two independently writable application copies can produce conflicting orders, identifiers or uploads. Choose the migration method that the team has rehearsed and can explain, even if that requires a more visible maintenance period.
Switch traffic in a small, observable sequence
Prepare DNS changes in advance. If reducing the cache lifetime (TTL) of a DNS record, do so early enough for previously cached answers with the old lifetime to expire. A lower value entered at the last minute does not shorten answers already held elsewhere. Keep old and new endpoints controlled during the overlap; changing DNS is not an instantaneous transfer of every active client connection.
- Confirm the final data boundary and the destination application release.
- Verify HTTPS, important routes and the intended write policy on the destination.
- Change only the planned traffic records and record their previous values.
- Compare authoritative DNS answers with several independent recursive lookups.
- Check representative user journeys and observe errors, latency and traffic at both hosts.
- Enable each approved worker or scheduled task exactly once, on its designated host.
For example, a team pauses writes at 21:00, completes final synchronisation at 21:15 and changes the web records at 21:20. It verifies the destination before reopening writes at 21:30. Those times are an illustrative sequence, not a standard duration. The important record is the moment new customer changes are first accepted at the destination.
Treat rollback as a data decision, then retire carefully
Before the destination accepts new writes, returning traffic to a still-consistent old service can be comparatively simple. Afterwards, switching DNS back alone may abandon accepted changes. Decide whether the destination can be repaired faster, or whether its new data must first be reconciled into the old system. Maintain the write freeze until the chosen rollback authority and data boundary are clear.
Keep the old service under a deliberate retention plan rather than cancelling it as soon as one browser works. Confirm that residual traffic, mail dependencies and callbacks no longer rely on it. Verify a fresh backup from the new production service and complete a final operational check. Archive the migration record so a later incident does not depend on someone remembering which server still owns a scheduled task.
