The preparation phase of a website migration, step by step

The success of a website migration is decided almost entirely before launch. Preparation reduces the risks by setting what must be migrated, keeping a record of what exists and building the redirect plan while the new site is being developed. Here are its steps, in the order they are carried out.

Write down the migration's objectives (what it should improve, and how that will be measured), its scope (the content, languages and sections concerned), the team and the schedule. Choose a launch date outside peak periods and inform everyone concerned, from customer service to marketing. The scope depends on the type of migration: see the types of migration and their scope, and for the schedule when to build the migration plan.

Before any change, back up the old site's files and database, along with the list of its URLs and content. The backup is kept off the server (locally or in online storage) and lets you roll back if something goes wrong.

The host's backup and transfer tools (OVHcloud, for example) are often enough, with no particular expertise. The database can also be exported from phpMyAdmin, the MySQL administration tool most hosts provide. Details are in our article on backing up data before a migration and the one on backing up the database.

List every URL that matters: those from a crawl of the old site (Screaming Frog or another crawler), but also those from Search Console, link tools (Ahrefs, Majestic), server logs and old sitemaps. A page missing from the menus can still receive links and traffic. Also identify the URLs to remove, which will answer with a 410 code.

For content, a page-by-page inventory tells you what to carry over, rewrite or drop: see data migration in a redesign.

To judge the migration, you need to compare. Before launch, record the site's performance with PageSpeed Insights and the Core Web Vitals: the time to display the largest content element (LCP), the page's responsiveness to interactions (INP) and the visual stability of the layout (CLS). Also export the pages and queries from Search Console and the Google Analytics 4 reports on pages and conversions (see backing up Google Analytics 4 data).

Preparation is a chance to improve rankings rather than copy what exists. The content audit tells you which pages to keep, merge or rework. Keyword research, with tools such as Ubersuggest, Semrush or Ahrefs, checks that the pages of the new structure match real searches.

Also check the basics page by page: title and meta description, heading hierarchy, internal and external links. Whatever is missing on the old site must appear in the new site's specifications.

Developers need written rules: URL structure, title and meta description tags, canonical tags, hreflang for a multilingual site, structured data, pagination, XML sitemap, robots.txt and expected load times. Delivered early, these specifications avoid discovering gaps during acceptance testing, when it is late to fix them.

Links from other sites to yours are an essential part of its rankings. From the start of the redesign, list the URLs that receive them (Search Console, Ahrefs, Majestic) and assess their quality, for example with Majestic's Trust Flow: these are the URLs whose redirect must never be missing. See the importance of backlinks in a migration.

The redirect plan maps each old URL to its new address. It is built on the staging site as soon as the new pages exist, then checked with a new crawl just before launch: as long as the new site is not frozen, its URLs can still change. See the redirect plan.

The staging site is used to test the new site in real conditions without it being indexed: redirects, internal links, tags, forms, checkout, load times. Keep it closed to search engines (password or noindex) and check that these settings will not reach production. The checks to run are in our migration checklist, and the most common pitfalls in the mistakes to avoid in a migration.

If code, development or SEO are not familiar to you, entrust the preparation to a team used to migrations: it will handle the analyses, the technical migration and the tests. This is not a project to play down: your traffic and your customers are at stake.