Before migrating a website, back up everything that would be hard or impossible to recreate, and do it before you change anything, so you always have a way back. That means a full backup of your site files and database, your media library, and a content export, plus three things people forget: a complete list of your current URLs, a record of your current settings and plugins, and a baseline snapshot of your rankings and analytics so you can tell later whether the migration helped or hurt. Keep the old site live and untouched until the new one is fully verified, because a working old site is the best backup of all and your fallback if anything goes wrong. Store the backups somewhere separate from the site, and confirm they actually restore rather than assuming they do. WPBuildAI captures your content, media, and full URL list up front and keeps your old site available until the new one is verified, so you always have a safety net through the move.
Back up the substance: files, database, media, content
Start with the obvious core, done thoroughly. A full backup means your site files and your database together, since on WordPress the content and settings live in the database while themes, uploads, and configuration live in files, and you need both to reconstruct the site, as the WordPress backup documentation describes. Add your media library explicitly, because images and files are heavy and easy to under-capture, and a content export as a portable copy of your posts and pages. This is the material a rebuild draws on, and it is also what you would restore if you had to revert. Capturing it completely, before touching anything, is the foundation the rest of the safety net sits on.
Do not forget the URL list
The most commonly skipped backup item is also one of the most important: a complete list of your current URLs. You need it because redirect mapping starts from it, so without the full list you cannot be certain every address is either preserved or redirected, which is the heart of a safe site move. Capturing every URL up front, as in extracting all URLs for redirect mapping, turns the redirect work from guesswork into a checklist. It is trivial to capture before the migration and painful to reconstruct after, especially for URLs that only existed on the old site. So treat the URL inventory as a first-class backup artifact, not an afterthought, because it is the map the whole redirect plan depends on.
Snapshot your rankings and analytics baseline
The other overlooked item is a before picture of your performance. Record your current rankings, organic traffic, key impressions and clicks, and top pages, so that after launch you can tell whether the migration held your traffic or hurt it. Without this baseline you are judging the result from memory, which is unreliable, and normal post-launch fluctuation becomes impossible to interpret. Since traffic concentrates on a minority of pages, as the Ahrefs study shows, at least record how your top pages were performing so you can watch those specifically. This snapshot costs a few minutes in Search Console and analytics beforehand and is irreplaceable afterward, because you cannot go back and measure the past once it has changed.
Keep the old site live as your real fallback
The single best backup is a working old site, so do not dismantle it at launch. As long as the old site remains live and untouched, you have a reference to compare pages against, a source to recover anything the migration missed, and a fallback to revert to if the new site has serious problems. This is the same principle behind recovering content from a live site when locked out: a live site is the richest source there is. So plan the cutover to keep the old site available until the new one is fully verified, then retire it deliberately once you are confident. Tearing it down on launch day, before verification, throws away your best safety net at exactly the moment you are most likely to need it.
Store backups separately and prove they restore
A backup you cannot restore is not a backup, and one stored on the same server as the site can vanish with it. So store your backups somewhere separate from the site and host, and confirm they actually work: open the content export, check the database dump is intact, verify the file archive is complete. Migrations are precisely when people discover a backup was partial or corrupt, at the worst possible time. A little verification beforehand turns a hopeful copy into a dependable safety net. The platform you move to is not itself a ranking factor, as the Backlinko analysis shows, so this is not about SEO; it is about being able to recover and to measure, which is what backups exist for.
Steps to back up before a migration
- Take a full backup of site files and database together.
- Capture the media library and a portable content export.
- Export the complete URL list for redirect mapping.
- Record settings and installed plugins so configuration can be reproduced.
- Snapshot your rankings and analytics baseline for before-and-after comparison.
- Store backups separately, confirm they restore, and keep the old site live until verified.
Worked example: a safety net that was never needed but always there
Consider an owner preparing to migrate who treated backups as a discipline rather than a formality. Before touching anything, she took a full files-and-database backup, saved the media library and a content export, extracted the complete URL list, noted her settings and plugins, and recorded her current rankings and top-page traffic in Search Console. She stored it all off the server and confirmed the export opened cleanly. During the migration the old site stayed live. In the end nothing went badly wrong, so she never had to revert, but when a handful of pages looked off after launch she compared them against the still-live old site and fixed them in minutes, and her rankings baseline let her confirm traffic had held rather than guess.
Limitation: backups enable recovery, they do not prevent mistakes
It is honest to bound this. A thorough backup is your safety net, but it does not by itself make the migration correct; it lets you recover and measure, not avoid errors in the first place. You still have to do the migration well, map redirects, preserve URLs, and test before going live, and the backup is what saves you if that work has a gap. Restoring a large site also takes time and care, so a backup is a fallback, not a zero-cost undo button. So treat backups as essential insurance that pairs with, rather than replaces, doing the migration carefully, and keep the old site live so your best fallback is always at hand.
Key points
Before migrating, back up everything hard to recreate, before you change anything: a full files-and-database backup, your media library, and a content export for the substance, plus the often-skipped items, a complete URL list for redirect mapping, a record of settings and plugins, and a rankings and analytics baseline to judge the result. Keep the old site live and untouched until the new one is fully verified, since a working old site is the best backup and your fallback, then retire it deliberately. Store backups separately from the site and confirm they actually restore, because a migration is exactly when a partial or corrupt backup surfaces. Remember backups enable recovery and measurement but do not replace doing the migration carefully. WPBuildAI captures your content, media, and full URL list up front and keeps your old site available until the new one is verified, so you always have a safety net through the move. Send your web address for a free analysis.
Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.