What to back up before a website migration: the complete list

Before any migration, people think of backing up the database. That is necessary, but far from enough: a successful migration needs to be able to roll back if the launch goes wrong, to compare the new site with the old one, and to know exactly what the old site contained, including what nobody looks at any more.

This page is the checklist of what to set aside, to be done during the preparation phase of the migration. Each item links, where one exists, to the detailed procedure.

A backup before a migration serves three purposes:

• rolling back: if the new version has a serious problem on launch day, you must be able to put the old one back into service, with its files, its database and its configuration;
• comparing: traffic and visibility data from before the migration are the baseline that will tell you, three months later, whether the migration cost you visits;
• forgetting nothing: the old URLs, the redirects already in place and the metadata of each page are the raw material of the redirect plan. Once the old site is switched off, they can no longer be collected.

The code, the theme, the plugins or modules, and above all the media: images, videos, downloadable documents (in WordPress, the wp-content folder). Copy them with an SFTP client, or ask your host for a full archive. Media count twice: they are often indexed in Google Images and cited by other sites, and their addresses will have to be redirected if they change (see redirecting images).

Pages, posts, products, accounts, orders, settings: on a dynamic site, almost everything is in the database. An SQL export (with phpMyAdmin or mysqldump) contains only the database: keep it together with the copy of the files, the two forming the complete backup. The methods (manual, control panel, cloud, rsync, automated services) are detailed in our article on backing up the database.

What is neither in the CMS files nor in the database, and is found missing afterwards:

• the .htaccess file or the nginx configuration, with the redirects already in place. They must be carried into the new plan and updated to point directly to the new addresses: otherwise an old URL redirected in 2019 ends up at the end of a chain of two or three redirects;
• redirects managed by a plugin (such as Redirection on WordPress) or in the CMS back office, which live in the database and disappear with it;
• the robots.txt file and the XML sitemaps, to compare what was offered to Google before and after;
• scheduled tasks (cron), cache rules and the domain's DNS zone (A, CNAME, MX records for email, TXT verification records), to be noted before any change of host.

The database holds the texts, but it is also useful to keep a snapshot of what is actually online: a full crawl of the old site, with for each URL its response code, title, meta description, canonical tag and internal links. This record lets you check, after the migration, that no metadata was lost along the way. It is the subject of our article on migrating editorial content.

The history of Google Analytics 4 and Google Search Console is not migrated: it is kept and exported. Search Console keeps only 16 months of data, and Google Analytics 4 deletes event-level detail beyond the retention period you choose. The exports to make, and the settings to check, are in our article on backing up Google Analytics 4 and Search Console data.

A migration gets stuck more often on lost access than on a technical difficulty. List, with their owner, the access details for the hosting, the domain registrar and the DNS zone, the CMS back office, Search Console, Google Analytics, Google Tag Manager, and the services connected to the site (payment, carriers, CRM, email sending tool). Check that each account belongs to the company, and not to a former agency or employee. Keep these credentials in a password manager, never in a shared document in plain text.

A backup stored on the server you are about to leave is not a backup. Apply the 3-2-1 rule: three copies, on two different media, one of them away from the server and the premises. Date each backup and record it in the migration log.

Keep them beyond the launch, until the new site has stabilised and traffic is back to its level: several months, not a few days. They will also help you recover a forgotten page or redirect.

A backup that has never been restored is a gamble. Before the migration, restore it at least once on a test environment: the site must display, the database must respond and the media must be there. It is also the best way to time a possible rollback, and therefore to decide how long it remains possible on launch day.

• Backing up the database
• Backing up Google Analytics 4 and Search Console data
• Data migration in a website redesign
• The SEO migration checklist
• The redirect plan