Website migration: how to move a business site without losing content or traffic

A website migration moves two things: your content, and the addresses that visitors and search engines already know. Most of the work, and most of what quietly goes wrong, is in the content. The database, the media and the user accounts have to arrive complete and readable. Then redirects carry your traffic across, and Search Console tells you for 30 days whether it worked.

We build the sites and handle the SEO around them, so we see migrations from both ends. We've also moved our own. In 2026, ez-digital.com went from Gatsby with a headless WordPress backend to Next.js, and what that move taught us is in the sections below.

What kind of website migration are you doing?

There are three kinds, and each moves different things. A hosting move copies the files and database as they are and keeps every URL. A redesign or platform change reshapes the content for a new system and usually changes URLs. A domain change moves everything to a new address.

Migration type	What has to move	Do URLs change?	What matters most
Hosting move (same domain, same platform)	Files and the database, copied as they are	No	A complete copy, DNS timing, keeping the old host up
Redesign or platform change (for example WordPress to a headless CMS)	Content reshaped for the new system; media re-linked; forms rebuilt	Usually	Nothing lost in the transform; the redirect map; the pages that rank
Domain change	Everything, at a new address	Yes, all of them	All of the above, plus the Change of Address tool in Search Console

Many projects are two at once, such as a redesign on a new host; apply the steps for both rows. Ours was a platform change that kept the domain and almost every URL.

Start with a content inventory

Before anything moves, count what you have. A content inventory is a spreadsheet of every type of content on the site and how many of each exist: pages, posts, products, media files, users, form entries. Those counts are how you prove later that nothing was left behind.

Note where each type lives and what it's made of. Most content sits in the database, but some hides in theme files or a page builder's own tables, and every field a post carries needs a home on the new platform. Decide in writing what stays behind, such as old drafts and expired promotions, so nobody guesses on launch day.

Moving the database

How hard this is depends on whether the database engine changes. MySQL to MySQL on a new server is a dump and a restore. Moving between engines, or out of a CMS into a headless CMS or plain files, is a translation: export, transform, import, then check that nothing was lost on the way.

On the same engine, match the database version where you can, and do a trial run weeks before launch so you know how long the real one takes.

Different engines are harder than they look. MySQL (or MariaDB) and PostgreSQL differ in column types, auto-incrementing IDs, time zones and case sensitivity, enough to break a straight copy. A conversion tool handles the common cases. The rest needs a script, and a person reading its output.

Leaving a CMS is rarely table to table. Going from WordPress to a headless CMS such as Contentful or Strapi, or to Markdown files in a code repository, means reshaping the content as it moves. Shortcodes and page-builder markup become clean HTML or structured fields. Write the transform as a script you can re-run, because you will run it more than once.

That's the move we made: our pages became JSON files and our posts Markdown, in the site's code repository with no CMS behind them. The WordPress backend was already offline by then, so we crawled the live site and took the content from the data files its Gatsby build had published, which still carried the original WordPress fields. If your old CMS is still running, export everything before it goes.

Watch the character encoding. When text stored in one encoding is read as another, curly quotes turn into strings like ’. Check the encoding at both ends, and search the imported content for those characters afterwards.

Then prove nothing was lost. Compare the inventory counts type by type, and spot-check by hand: the oldest post, the newest, one with a table, and your ten busiest pages.

Counts catch missing records, not missing pieces inside a record. On our own site every count matched, yet the conversion to Markdown had silently dropped 14 empty spacer blocks from three blog posts. Comparing pages showed the posts running short; the old site's data showed why.

Moving files and media

Media moves separately from the database, which only holds its URLs. Copy the files first, then make sure every link in the content points at a file that answers, whether the files go to another server or to object storage such as Amazon S3.

Between servers, copy the uploads folder with a tool that keeps the folder structure and permissions, and compare file counts at both ends. If the domain and paths stay the same, the links keep working.

Moving media to S3, often behind a CDN (content delivery network) such as Amazon CloudFront, takes load off the web server, but every file gets a new URL. Update the stored URLs with a search and replace across the database. On WordPress, use a tool that understands serialized data. Some settings store each string's length beside it, and a plain replace that changes the length corrupts them.

Keep the old file URLs answering too, because other sites and old emails still link to them. Redirect the old uploads path to the new location, or serve the files from the same path through the CDN.

Our media went the other way, off the WordPress host and into the new site. The old site served each image under many generated URLs, one for every size and format, and we mapped 429 of those addresses onto 41 files. Some images had only ever lived on the WordPress host, which was gone. The Internet Archive's Wayback Machine had copies of several; a few blog images had never been archived and had to be restored separately. Copy your media before the old host is switched off. An archive is a poor backup.

Last, check permissions. Public images should be publicly readable, and private files such as form attachments must not be.

Users, forms and the content freeze

The last pieces are the ones people forget until launch day: accounts and form entries, plus anything written while the new site was being built.

Accounts can move, but passwords often can't, because each platform hashes them its own way. Either the new one accepts the old format, or every user resets their password.

Export past form entries if anyone still needs them, then rebuild each form with its connections: who gets the email, which CRM the lead lands in, which conversion event fires. These quietly break after a platform change, so we list every one before launch as part of our integration work. On our own move, the contact form kept sending to the same SendGrid list, and we dropped the old newsletter handler because no page had a signup form any more.

Content also keeps changing while you build. There are two ways to get the last changes across:

1. Freeze. Stop editing the old site on a set date and make the final export after it. Right for most brochure sites.
2. Delta sync. Migrate everything early. Just before launch, export only what was created or changed since, using each record's modified date, and import that. Right for sites that can't stop, such as stores taking orders.

Either way, run the inventory counts again after the final copy.

Keeping the design, or building a new one

A redesign gets new styles. When the design stays and only the platform or design system changes, the new site has to reproduce the old styles as closely as it can, and someone has to decide before the build how close is close enough.

Small differences, such as a few pixels of spacing or a slightly different line height, are often fine. Some pages have to match pixel for pixel at every screen width. Settle which applies to each page type up front, so "it looks a bit off" can be checked against an agreed standard. We kept our own design and put the bar in numbers: in each screenshot of the new site, no more than one pixel in a hundred could differ from the old site's.

The styles also have to cover content that doesn't exist yet. The old blog may never have had a table, a nested list, a quotation or a block of code, but next month's post might. We style a standard set of these elements, add whatever this client is likely to publish, and test each with sample content, so new posts look right on whatever platform the site now runs.

Will a website migration hurt my rankings?

Expect a temporary dip, not a lasting loss. Google says plainly to expect temporary fluctuation in site ranking during the move, and that for a medium-sized site it can take a few weeks or more before the new URLs replace the old ones in results.

Once the content has arrived intact, a dip usually becomes a real loss for one of five reasons:

1. No redirect map, or a lazy one. Old URLs return 404, and the rankings and links they earned go with them.
2. Everything redirected to the homepage. Google specifically warns against sending many old URLs to one irrelevant page.
3. A noindex tag or a blocking robots.txt left over from staging. The new site goes live and tells search engines not to index it.
4. Rewritten titles and content on the pages that bring traffic. The pages that rank should change least.
5. Internal links still pointing at old URLs. Each one now goes through a redirect, and some through two.

Before launch: build the redirect map

A redirect map is a spreadsheet with every old URL in one column and its new destination in the next. Google's instruction is simple: once you have the list of old URLs, decide where each one should redirect to. Building that list is most of the SEO work in a migration.

We build ours in four steps:

1. Collect every old URL. Start with the sitemap.xml. Google Search Console and, on some sites, the database catch the addresses the sitemap misses.
2. Set up the sheet. Each old URL gets a "to" column, a redirect type, and a decision: keep the page or delete it. We usually fill it in together with the client.
3. Pre-fill, then review. When the new site already exists, we sometimes have AI draft the destinations, then check every row. Correcting a draft is easier work than starting from a blank column.
4. Import once it's approved. The redirects go into the CMS, a server config file or a redirect map file.

These rules decide the "to" column:

• Same content, new address: redirect to the new page that replaces it.
• Merged content: redirect to the page it was merged into.
• Gone for good, with no replacement: let it return 404 or 410 rather than forcing it onto an unrelated page.
• URL variants: include the versions with and without a trailing slash, with and without www, and on HTTP. Each needs to land on the one canonical address in a single hop.

Our own map was short, because the paths didn't change, but the trailing slash did: the old site sent /about to /about/, and the new one redirects the other way. Two retired service pages now point at the pages that took over their content, and an old SEO service page with no successor points at the services index.

Use permanent redirects set on the server: Google recommends HTTP permanent redirects, such as 301 and 308, which its guide to redirects says tell Google the target should be the canonical URL. Keep them for at least a year, and agree who maintains them after launch.

Before launch: what else to check on staging

Crawl the new site on its staging address before anyone flips DNS.

• Your top pages. Compare the titles and copy of your 20 or so busiest search pages with the old versions.
• Indexing controls. Staging is usually blocked from search engines on purpose; make sure the noindex tag and any Disallow: / line are gone from the live site.
• Canonical tags. Google asks that each new URL carry a canonical tag pointing at itself, not at the old domain or the staging address.
• Links and images. Links should point straight at the new URLs, with no broken images.
• A way back. Keep a full backup of the old site until the new one has run cleanly for a month.

On our own site we automated these checks across all 33 pages. Each had to answer with real content, with and without the trailing slash. Titles and descriptions were compared with the old site's, every internal link was followed, and every page was screenshotted at phone, tablet and desktop widths and compared with the old site's pixels. That comparison is what caught the missing spacer blocks.

If your current site is slow, a migration is the cheapest time to fix it, since every template is being rebuilt anyway. Read how a faster website brings in more clients before signing off the design.

Launch day: switch over and verify

Launch day is for proving that what worked on staging works in production, before you announce anything.

1. Make the final copy, by ending the freeze or running the delta sync, and check the inventory counts once more.
2. Turn on the redirects and test 20 or 30 old URLs from the map, including your top pages and a few old image URLs. Each should return a 301 or 308 to the right place in one hop.
3. Submit the new sitemap in Search Console.
4. Crawl the live site for 404s, redirect chains (one redirect leading to another), broken images and any page still carrying noindex.
5. Send a test through every form, and check that analytics records the visit and the submission.
6. For a domain change, use the Change of Address tool. It needs both properties verified in Search Console and a 301 from the old homepage to the new one, and it applies for 180 days.
7. Hosting move only: the DNS TTL (how long other servers cache your address) should have been lowered to a few hours a week earlier, as Google's hosting-move guidance suggests. Keep the old host running until its logs show no more traffic.

The first 30 days in Search Console

Search Console tells you whether Google is following the move. Check daily in the first week, then weekly. Compare against the same period before launch, not the day before.

When	What to check	What's normal
Day 1	URL Inspection on the homepage and two or three top pages; the sitemap shows as read	Hosting move only: a temporary drop in Googlebot's crawl rate, recovering over a few days
Week 1	The Pages report for new "Not found (404)" entries; the old URLs showing as redirects	Some old URLs still showing in results while Google processes the redirects
Weeks 2 to 4	Clicks and impressions on your top pages; queries you used to rank for	New URLs gradually replacing the old ones; for a medium site this can take a few weeks or more

If URL Inspection can't fetch a page on the new host, fix that first. A drop confined to a few pages usually means a missing redirect or missing content.

Should a small site migrate all at once or in stages?

All at once. Google recommends that small and medium sites move all their URLs simultaneously instead of one section at a time. One well-tested switch is simpler to check.

How much does a website migration cost and how long does it take?

There's no standard price, because no two sites move the same way. A hosting-only move is the smallest job. A platform change costs more, because the content and its links have to be reworked. We scope and estimate each migration from the site itself.

Size and variety matter most. Distinct layouts count as much as pages, so a 50-page brochure site and a 2,000-post blog with a store attached are different projects. A like-for-like database copy is quick; leaving an old CMS full of custom fields takes a transform script and testing. Every form and CRM connection has to be rebuilt and tested too.

For Los Angeles businesses that rely on local search, one detail is easy to miss: if your Google Business Profile links to a URL that's changing, update it there too.

When to hire help with a website migration

Hire help when the content has to be reshaped, the database or file storage changes, or URLs change, especially if search brings in a real share of your leads. Your host can often handle a small hosting move.

Most of the migrations we run for businesses in Los Angeles and across the US are part of a redesign or platform change, planned alongside the new site from the start. That's how our web design and development projects work, and if you're planning a move, ask us for an estimate based on your site. If you're mid-migration with another developer, we can review the plan or a traffic drop through our consulting service.

Whoever does the work, take your content inventory and crawl your current site today, before anything changes. Those counts and that list of URLs are the two things you can't rebuild once the old site is gone.