Website migration with a way back.

• Choose this migration when only the host or server is changing.

  The design, content and page addresses stay as they are, and the work is moving everything the site depends on and proving the new host before visitors reach it.

• Choose website redesign when the platform, structure or addresses change.

  A rebuild moves content, maps old addresses to new ones and protects search equity, which website redesign and modernization covers, with the infrastructure work from this page.

• Choose SEO migration support when the domain or protocol changes.

  A new domain or a move to HTTPS changes every address, so redirects and search signals lead the plan, as described on the SEO, AEO and GEO pillar.

A website or server migration moves more than files: the database, configuration, DNS and email records, certificates, scheduled jobs, redirects, server rules and the access people and services use all have to move or be recreated. The inventory lists each one with the person who owns it.

Anything missing from the inventory is found after the switch, when it is hardest to fix, so the inventory is checked against the running site rather than against memory. Configuration and secrets are recreated through the settings of the new host, never copied into the repository or sent by email.

The inventory covers:

• Site files and uploaded media.
• The database, with a plan for changes made during the move.
• Configuration and environment settings, kept out of the repository.
• DNS records, including email and verification records.
• Certificates for every hostname the site uses.
• Scheduled jobs, background work and outgoing email settings.
• Redirects and server rules.
• Access for the people and services that deploy or monitor the site.

DNS is switched once both hosts can serve the site: record lifetimes are lowered well in advance, the new host is tested with a full copy, and content changes are paused during the switch so neither host falls behind. Some interruption can still occur, and the plan says how it is handled.

Every DNS record carries a time to live, the interval a resolver may keep a cached copy before asking for the record again. Lowering it well before the move means the change reaches visitors sooner when it happens. Certificates are in place on the new host before any traffic arrives, to avoid certificate warnings when visitors reach it.

During the switch, the server logs on both hosts show where traffic is still arriving, and the old host is left unchanged, so pointing DNS back to it remains possible.

Email keeps working when the records that route and authenticate it move with the site: MX records, and the SPF, DKIM and DMARC records receiving servers check, are copied to the new DNS before the switch and tested afterwards. Mailboxes stay where they are unless the mail service itself is changing.

A sending server looks up the MX records of a domain before it delivers mail, so a missing or mistyped MX record stops incoming mail with no warning on the website. Forms, stores and scheduled jobs that send mail from the new server need that server authorized in the SPF record, or their messages can be rejected or filtered as spam. Sending automated messages at volume is covered under integrations and automation.

A migration is rolled back by pointing DNS at the old host again, which is why the old host stays running and unchanged until the new one is verified. The criteria for rolling back, who decides, and how data written on the new host in the meantime is carried back are agreed before the switch.

Keeping two working environments and switching traffic between them is the idea behind blue-green deployment: a rollback becomes a switch rather than a rebuild. The hard part is data. Orders, form entries or content created on the new host after the switch have to be carried back or replayed, so the plan says how that happens.

A DNS rollback also waits on cached records, so it is not instant, and database changes that cannot be reversed are restored from the backup taken before the move.

After a move, checks confirm that important pages load over HTTPS with the right status codes, forms and email work, scheduled jobs and backups run on the new host, and search engines can still reach the site. Each check is recorded, so the old host is retired on evidence rather than on a date.

Checks start immediately. Google Search treats DNS and network errors like server errors, and indexed addresses that stay unreachable can be removed from its index within days.

Page titles, descriptions and structured data move with the files and are compared against the old host, and confirming that analytics tags still record visits belongs to analytics implementation. The checklist covers:

• Status codes, redirects, canonical tags and the sitemap on important addresses.
• HTTPS and a valid certificate on every hostname.
• Forms, outgoing email, incoming mail and analytics tags.
• Scheduled jobs, background work and backups on the new host.
• Server logs on both hosts until the old one receives no traffic.
• Googlebot access, checked with URL Inspection in Search Console, with crawl blocks removed from the new copy.
• Response times on the new host compared with the old one.
• No mixed content or blocked resources on important pages.

• Website migration
• Server migration
• Cutover planning and DNS sequencing
• Rollback planning
• Post-migration verification

A migration starts from the existing website and follows a set order, so the new host is proven before visitors reach it and the old one is retired only on evidence.

• Problems found on a copy

  Anything that breaks on the new host breaks during the rehearsal, while the live site is still untouched.

• Email and certificates move too

  Mail records and certificates are part of the plan, so they keep working instead of failing after the switch.

• A way back at every step

  The old host stays ready until the new one is verified, and the rollback criteria are agreed in advance.

• A documented new home

  Hosting, DNS and access are written down, so the next change does not start with guesswork.

• Leaving unsupported hosting

  A site on hosting that is slow, out of support or no longer administered moves to an environment the business controls.

• From one server to the cloud

  An application running on a single server moves to a cloud platform, with its database, jobs and configuration.

• Consolidating accounts

  Sites spread across several hosting accounts move into one account in the business name.

• An inventory of everything the site depends on comes before the plan, so nothing is moved on an assumption.
• DNS record lifetimes are lowered well before the switch, so cached copies refresh faster when it happens.
• The old host keeps running until the traffic reaching it stops, rather than until a fixed date.
• Nothing is switched without a tested copy on the new host and an agreed rollback route.
• Credentials and environment settings move through the access controls each provider offers, and never appear in the repository, a ticket or an email.
• No migration is described as zero downtime or risk-free: the plan reduces the risk, and the verification shows the result.