Data migration in a website redesign: the method

A website redesign is not just a new design or a new CMS. Everything the old site has built up has to move to the new one: its pages and their text, its media, its URLs and, depending on the site, its products, customers or orders. That is data migration, and it is often the most underestimated step of a project.

This article describes the general method, which applies to every site. Two cases have their own article: data migration for an e-commerce site (catalogue, customers, orders) and migrating editorial content (pages, articles, SEO metadata).

There are four families of data, migrated neither with the same tools nor by the same people:

• structure: the site tree, the URL of every page, categories and menus;
• content: text, media (images, videos, documents) and their SEO metadata (title, meta description, alt text);
• reference data: products and their variants, customer accounts, orders, forms and their submissions;
• measurement data: the history in Google Analytics and Search Console, which is not migrated but saved, to compare before and after go-live.

Start with the full list of what exists: a crawl of the old site for pages and URLs, CMS exports for the data (products, customers, articles), and the sources that reveal pages the crawl misses, such as Search Console, backlink tools or server logs. A page that receives links or traffic but appears in no menu is exactly the one that gets forgotten.

Every piece of data in the old CMS needs a place in the new one: a field for every field, a rule for every difference (an attribute that becomes a variant, a category that becomes a tag, a layout block that becomes another). This mapping table is the reference document of the migration; it stops everyone from interpreting it their own way.

Run a first full migration on the staging site as soon as the new site allows it, well before go-live. It reveals the cases the mapping did not foresee, gives a realistic idea of the time needed, and lets you test the new site on real data rather than on samples.

Compare the counts (pages, products, customers, orders) between the old and the new site, check a sample by hand, and look for what breaks silently: missing media, internal links still pointing to the old addresses, damaged accented characters, duplicate content.

At switchover, freeze the old site's content, replay the migration (or only the data created since the trial run), then put the redirects live. The more faithful the trial run, the shorter this step.

On an e-commerce site, the heart of the migration is the reference data: products, prices, stock, customer accounts, order history, with constraints of its own such as customer passwords or invoice numbers. Our article on e-commerce data migration covers them in detail.

On an editorial or corporate site, what matters is the quality of the migrated content: formatting, heading structure, SEO metadata, internal links. That is the subject of our article on migrating editorial content.

Data migration and redirects move forward together. To suggest the page of the new site that replaces each old page, Swan crawls both versions and compares their content by semantic proximity: with no content migrated to staging, there is nothing to compare. The order that works is therefore: trial migration on staging, Swan crawls both sites, you validate the suggested matches, the redirects are tested on staging, then the final migration and go-live.

The importance data you import into Swan (Search Console pages, backlinks from Ahrefs or Majestic, server logs) also serves the migration: it points to the pages to migrate first and to check first. Next, see our guide to the redirect plan and our SEO migration guide.