Website Migration Planning: A Low-Risk Runbook for Domains, Data and Launch

A website migration can involve a new hosting provider, a new platform, a domain move, an infrastructure redesign, or several of those at once. The launch is often treated as the main event, but the quality of the result depends on preparation: knowing what must move, what can change, what needs to remain compatible, and how to recover if an important workflow fails.

This runbook helps business owners and technical teams plan a controlled migration. It covers scope, environment preparation, content and data transfer, DNS, testing, launch, and post-move monitoring. No migration is truly risk-free, and DNS changes do not instantly propagate everywhere. The goal is to make dependencies visible, reduce avoidable surprises, and define how the team will respond.

Choose a migration strategy and freeze scope

Write down why the migration is happening and what success means. The objective may be improved maintainability, a platform upgrade, a new hosting environment, lower operational burden, or an integration change. Separate required outcomes from optional redesign work. Combining an infrastructure move with a complete theme redesign, content rewrite, and application upgrade can make failures harder to isolate.

Decide whether the move will be a direct cutover, a staged migration, or a parallel launch. A simple static site may tolerate a short cutover. A store accepting orders needs a method to preserve changes made during the transfer. A custom application may require a data synchronization period or a planned write freeze. Document who owns that decision and what level of downtime the business accepts.

Inventory the complete service

List domains and subdomains, DNS records, website files, databases, media, mailboxes, scheduled jobs, certificates, forms, redirects, analytics, search tools, CDN settings, API connections, payment callbacks, and authentication providers. Identify which vendor controls each component and who can authorize changes. A website migration that moves files but forgets a DNS record, email route, cron task, or integration is not complete.

Record the current application and runtime versions, database engine, PHP extensions or other dependencies, storage requirements, and any custom server rules. Review access credentials and rotate them according to your policy; do not place secrets in the migration checklist. Confirm that the target hosting environment supports the application and required extensions before copying data.

Prepare the destination before copying production

Create the target environment with the required runtime, database, web server, storage, user permissions, certificates, backups, and monitoring. Validate a small health check before moving the full application. Configure a test hostname or protected staging URL so the team can exercise the destination without switching customer traffic.

Keep production-specific credentials and customer data protected. Use a staging copy with test integrations where possible. Prevent the new site from sending real transactional email or triggering production webhooks until the launch plan authorizes them. Verify that search engines will not index a private test environment.

Plan data transfer and change control

Take an initial copy, then identify what changes while the copy is in progress. A brochure site may have only occasional content changes. A transactional store can create orders, customer updates, and inventory changes continuously. Choose a synchronization strategy that accounts for these writes: a maintenance window, final delta transfer, database replication, or another method appropriate to the platform.

Before transfer, confirm the backup is restorable and record the data snapshot time. During the final cutover, communicate any content or order freeze clearly. Assign one person to confirm when writes may resume. If the old and new systems both accept writes without a reconciliation plan, the business can end up with missing or conflicting records.

Preserve URLs and search signals

Export existing URLs and map them to the destination. Keep paths unchanged where the content and information architecture are the same. When a URL changes, create a direct permanent redirect to the closest equivalent page. Avoid sending every retired URL to the homepage; visitors and search systems need a relevant destination.

Check canonical URLs, robots directives, sitemap generation, internal links, and page metadata on the target. Remove noindex restrictions when the site is ready to be public, but keep private staging content out of search. Preserve useful structured data only when it accurately describes the content and visible page.

Test acceptance criteria before launch

Make a list of important workflows and assign an owner to each test. Include desktop and mobile display, navigation, forms, sign-in, search, product options, checkout, payment confirmation, customer emails, admin workflows, integrations, page redirects, certificate validity, and error pages. Test representative content and a handful of unusual cases, not only the homepage.

Check logs and performance under realistic requests. Confirm that the target environment can handle scheduled tasks, background queues, uploads, and backups. For an online store, use approved test-payment methods and verify order status, inventory behavior, and confirmation. For a lead-generation site, submit a form and confirm that it reaches the correct team and is not trapped by spam filtering.

Prepare the DNS cutover and rollback

Confirm who manages the authoritative DNS zone and how changes are approved. Review existing records, including email authentication, verification tokens, subdomains, and service endpoints. Lowering TTL ahead of a planned change can help some clients pick up a new record sooner, but it does not guarantee instant propagation; caches may retain prior values for other reasons.

Record the old and new target values, expected change window, verification method, and rollback trigger. After the cutover, test from more than one network or resolver where practical. Verify certificates, website behavior, mail flow, and integrations. Keep the old environment available until the new service has passed the agreed validation period and the business owner approves decommissioning.

Monitor after launch

Watch error rates, response time, server resource use, application logs, form delivery, order processing, payment callbacks, search indexing, and customer support reports. Compare them with the baseline from the previous site. Check for missing assets, redirect loops, mixed-content warnings, and requests to old endpoints. Review analytics and search-console data after enough traffic has passed to produce useful signals.

Record changes made during launch and unresolved issues. Assign each follow-up an owner and deadline. Do not remove the old host simply because the homepage works; confirm that backups, mail, background jobs, and external integrations are all operating on the new path.

Common migration mistakes

• Changing the platform, design, DNS, runtime, and integrations simultaneously without separate test points.
• Assuming every application change is included in a file copy.
• Ignoring orders, form submissions, or inventory updates made during the transfer.
• Forgetting mail routing, scheduled tasks, certificates, or external API allowlists.
• Launching without URL mapping and relevant redirects.
• Turning off the old environment before recovery and verification are complete.
• Declaring success after checking only the homepage.

Frequently asked questions

Will lowering DNS TTL eliminate downtime?

No. It can reduce some caching delays, but it cannot remove every resolver or application cache. Test the destination in advance and plan for a period when users may reach either environment.

Can the old and new sites run at the same time?

Often they can, but only if writes, mail, payment callbacks, and background jobs are controlled. Two active copies of a transactional application can diverge unless data synchronization is designed and tested.

How long should we keep the old server?

Keep it until the new environment passes agreed functional checks, data and integrations are validated, backup and restore are confirmed, and the owner approves decommissioning. The duration depends on risk and business cycle.

Plan a migration with clear acceptance checks

Informatix Systems can inventory a website or store, build the migration map, prepare a target environment, coordinate data and DNS changes, and validate the launch against agreed workflows. We define scope, downtime assumptions, dependencies, rollback triggers, and ownership before work starts. Explore website and eCommerce services or contact Informatix Systems to plan a website migration.