Reduce website migration risk by proving that the destination works before sending it public traffic, controlling changes to application data, and planning how to recover if acceptance checks fail. A file transfer and a DNS edit are not a complete migration. There is no universal migration duration or guarantee of zero downtime or zero data loss.
WebCare360 publishes this operational planning guide and sells hosting. This is an editorial workflow, not a report of a tested customer migration or a promise that migration assistance is included in a hosting plan. Use your application's supported procedures and agree who will perform each operation.
Define what moves and who can approve it
Write down the source, destination, reason for moving and responsible operator. List the domains and applications in scope, the people controlling DNS and hosting access, and the owner who can accept service interruption or missing data. Record a change window and a way to contact those people if the website itself is unavailable.
Set acceptance conditions before copying anything: the required pages load, authentication and critical transactions work, expected records are present, integrations reach the right environment, and monitoring and recovery are available. Choose checks and an observation period appropriate to the application. A successful homepage request alone does not satisfy those conditions.
Inventory files, state and external dependencies
Record application and runtime versions, extensions, configuration, file permissions, certificates, licences and scheduled jobs. Separate deployed code and unchanged files from databases, user uploads, sessions, queues and other state that may continue changing. Confirm compatible destination software and the supported transfer method; do not assume that a newer version can accept every old export.
List external payment, mail, identity, storage and webhook services. Identify any source IP allowlists, callback URLs or credentials they depend on. Record what stays external so that a hosting move does not accidentally become an unplanned migration of another service.
Check email explicitly. If mail remains with an external provider, preserve its routing and authentication records. If mailboxes move, plan mailbox contents, accounts, aliases, delivery during the transition and a final synchronization method supported by the mail system. Moving the website's files does not move mail already stored elsewhere. Confirm send and receive behavior separately from web-page testing.
Keep recovery separate from the transfer
A migration copy prepares the destination. A backup is retained for recovery; a snapshot captures state within the system's constraints, and a replica may continue receiving later changes. These labels do not prove that an application can be restored. Keep an accessible recovery point, its keys and the instructions needed to restore it independently of the working migration copy.
AWS's recovery-testing guidance recommends exercising restoration to check backup integrity and recovery procedures. Apply that principle to your actual backup system; it does not imply an AWS product or an included backup service.
Use the database's supported method. For example, PostgreSQL documents distinct backup approaches, and its file-system backup guidance explains shutdown or consistent-snapshot requirements. Copying arbitrary live database files is not a substitute for those procedures. Follow the documentation for your own database and version.
Rehearse before changing public traffic
Prepare the destination with the required configuration and a representative copy of the data. Test the real hostname and HTTPS configuration using an authorized preview method. The local hosts-file preview guide covers one way to test from your own computer while public DNS still points elsewhere. It does not redirect other people's devices or external callbacks.
Exercise sign-in, representative reads and writes, uploads, search and the business operations that matter. Use test accounts and sandbox integrations where available. Disable or isolate outbound messages, real charges and duplicate scheduled work during rehearsal. Do not dismiss certificate errors or treat a disabled integration as a passed production test.
Record the test, expected result, observed result, environment and unresolved issue. Verify destination logs and the recovery procedure. Stop before cutover if a required dependency or recovery mechanism cannot be validated.
Plan the final state transition
For each changing dataset, record five decisions: what can change, what can be copied early, what must be synchronized last, which environment may accept writes at each stage, and how the resulting state will be checked. Unchanged images may be copied ahead of time; orders accepted afterward require a separate supported consistency plan.
Choose the application's supported method, such as an agreed maintenance restriction and final export, or a properly configured replication-based transition. A background copy alone does not establish coherent writes across two live applications. If clients can reach both environments, resolve how their writes, sessions and jobs are handled before creating that situation.
As a planning example, an online shop might pre-copy unchanged product images while orders remain on the source. Its operator must then define how later orders and uploads reach the destination, when conflicting writes stop, and which records are checked before accepting the move. This is not a tested recipe for a particular shop or a promise of loss-free transfer.
Prepare DNS and routing without assuming an instant switch
Identify the actual traffic control: DNS records, a reverse proxy, a CDN origin setting or a combination. Preserve previous values and access needed for reversal. Change only records required for the move; a website-origin change does not by itself require changing unrelated mail records or the entire DNS delegation.
Cloudflare's TTL reference explains how DNS caching affects updates. Lowering TTL in advance can shorten caching of newly obtained answers, but previously cached answers can retain their earlier lifetime. Local caches and resolver behavior also matter. Neither lowering TTL nor changing a record makes every visitor switch immediately; existing connections and application sessions have their own behavior.
Plan for traffic reaching the old environment during transition. Use observed requests and application state alongside DNS checks. Do not declare completion from one resolver result or a universal “24 hours” rule.
Execute the cutover against explicit gates
- Confirm the destination rehearsal passed, recovery is usable and the source remains available for the agreed fallback.
- Confirm the decision-maker and notify affected users or operators of the planned impact.
- Apply the agreed write and job controls, complete the final synchronization and validate the resulting state.
- Change the documented routing controls in the planned order.
- Check real application behavior, data changes, integrations, mail where applicable, errors and destination monitoring.
- Watch for clients still reaching the source and apply the previously agreed coexistence plan.
- Accept the migration only after the defined checks and observation period pass; otherwise invoke the recovery decision.
Gradual traffic exposure is appropriate only when the application and data model support it. Do not introduce a split solely because it sounds safer. Pause at a failed gate rather than pushing through an unexplained discrepancy.
Make rollback a data decision as well as a routing decision
AWS’s cutover guidance distinguishes rollback before new data from rollback after the destination has accepted changes. The same distinction is useful when planning a hosting move; the implementation depends on your application.
Before cutover, name the rollback decision-maker, observable triggers, controls to reverse and prerequisites for keeping the old environment usable. Triggers might include failed critical transactions or missing expected records; the thresholds must come from this application's acceptance criteria.
Determine what happens to writes accepted after cutover. Sending users back to an older database can leave those changes behind. Preserve the new state, decide how to reconcile it using supported procedures, and control further conflicting writes before returning traffic. If safe reversal is no longer possible, use the documented recovery alternative and obtain the responsible owner's decision.
Routing reversal may involve more than DNS, and cached destinations may continue to receive traffic. After rollback, validate data, authentication, transactions, integrations and monitoring again. Record what was reversed, what remains changed and any accepted data gap. “Change DNS back” is not an adequate rollback plan.
Retire the old service only after acceptance
Close the source only when the acceptance and rollback obligations are satisfied, the destination recovery arrangement is verified, and the responsible owner approves. Review remaining traffic, mail dependencies, retained data and cancellation terms. There is no universal safe retention period.
Keep the inventory, test evidence, recovery point, state-transition record, routing changes and acceptance decision together. Update operational ownership and revoke obsolete access when it is safe. The migration requirements page helps prepare a service brief; use the current contact options to confirm any requested assistance and its scope. If the source is already unavailable, follow the separate source-access and backup recovery decision guide instead of assuming a planned cutover is still possible.
