{"id":20418,"date":"2026-11-02T12:28:21","date_gmt":"2026-11-02T11:28:21","guid":{"rendered":"https:\/\/stage.surver.nl\/kennisbank\/wordpress-backup-en-migratie-de-complete-gids\/"},"modified":"2026-11-03T14:54:14","modified_gmt":"2026-11-03T13:54:14","slug":"wordpress-backup-and-migration-the-complete-guide","status":"publish","type":"kennisbank","link":"https:\/\/stage.surver.nl\/en\/kennisbank\/wordpress-backup-en-migratie-de-complete-gids\/","title":{"rendered":"WordPress Backup and Migration: The Complete Guide"},"content":{"rendered":"
\"WordPress<\/figure>\n\n\n\n

Your site suddenly disappears after an update or a hack, or you want to switch to a different hosting provider\u2014and only then do you wonder if your backup actually works. A WordPress backup is a complete copy of your database and files, which you can use to restore your site after an error or a hack. Migration is the process of transferring that copy to another server or domain. Without a working backup, migration isn\u2019t safe. In this guide, I\u2019ll explain exactly what a backup is, how to create, store, test, and restore it, and how to safely move your site afterward. For each topic, I\u2019ll link to the article where we go into more detail.<\/p>\n\n\n\n

Backup, export, migration, and cloning: What's the difference?<\/h2>\n\n\n\n

A backup is a complete copy of your site, database, and files at a specific point in time. An XML export is just your content in a text file. A migration is the process of moving your entire site to a different server or domain. A clone is a working copy of your site on the same hosting account, which you can use, for example, as a staging environment to test updates. In support inquiries, I regularly see these four terms used interchangeably, and that\u2019s exactly where things go wrong.<\/p>\n\n\n\n

Concept<\/th>What's Inside<\/th>What is it for?<\/th>What It Is Not<\/th><\/tr><\/thead>
Backup<\/td>Database and files as of a specific point in time<\/td>Recovery After an Error, Hack, or Failed Update<\/td>No protection against a leak that's still there<\/td><\/tr>
XML Export<\/td>Posts, pages, comments, and menus<\/td>Migrating Content to Another WordPress Site<\/td>No backup, because the theme, plugins, settings, and media files are missing<\/td><\/tr>
Migration<\/td>The entire site has been moved<\/td>Moving to a different hosting provider or a different domain<\/td>No copy is left behind\u2014that's why you should back up first<\/td><\/tr>
Clone or staging environment<\/td>Working copy on the same hosting account<\/td>Testing Updates and Performing Recovery Tests<\/td>No backup, because it's on the same server<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Most of the confusion stems from the export function under Gereedschap > Exporteren<\/strong>. That sounds like a backup, but it isn't. You'll get an XML file containing your content, and without your theme, plugins, and settings, you can't restore a working site from it. You can read about what the export is actually good for in Exporting a WordPress Site Using the XML Export Feature<\/a>. Instructions on how to create a test copy can be found in the staging environment<\/a>.<\/p>\n\n\n\n

What's included in a full WordPress backup?<\/h2>\n\n\n\n

A complete WordPress backup consists of two parts: the database and the files. The database contains your posts, pages, settings, and users, and\u2014if you have an online store\u2014your orders and customers as well. The files are mainly located in the folder wp-content<\/code>, including your themes, plugins, and uploads such as images and PDFs. In addition, there are wp-config.php<\/code>, containing the information WordPress uses to connect to the database, and .htaccess<\/code> with your server rules.<\/p>\n\n\n\n

Strictly speaking, you don\u2019t need to include the WordPress core itself, since you can easily download it again. But it doesn\u2019t hurt to include it. What does go wrong, however, is a backup that contains only the database or only the files. That\u2019s a partial backup, and you can\u2019t restore a complete site with a partial backup. It\u2019s also important that both parts be from the same point in time. I call this a \u201cbackup set,\u201d and that term will come up again later when we discuss restoration.<\/p>\n\n\n\n

How to Back Up WordPress: Three Methods<\/h2>\n\n\n\n

You can back up your WordPress site through your hosting provider, using a backup plugin, or manually. My advice is to set up at least one automated backup method and also keep one copy outside of your hosting account. That way, you\u2019ll have a real safety net\u2014not just a false sense of security.<\/p>\n\n\n\n

Through your hosting provider<\/h3>\n\n\n\n

Your hosting provider automatically creates a hosting backup, separate from your WordPress installation. That\u2019s the approach I recommend to everyone as a baseline, because you can restore it even if WordPress itself stops loading. The downside is that everything is stored with the same provider if this is your only copy. Therefore, ask your host how often backups are created, how long they\u2019re retained, and which data center they\u2019re stored in. A good hosting provider will have specific answers to those three questions.<\/p>\n\n\n\n

With a backup plugin<\/h3>\n\n\n\n

A backup plugin creates a copy of your WordPress site and, ideally, stores it in external cloud storage. Well-known examples include UpdraftPlus, Duplicator, and All-in-One WP Migration, and the features available for free vary by plugin. The strength lies in that external storage, because it gives you a copy outside your hosting environment. The weakness is that the plugin runs on the same server as your site. If the site goes down, the plugin won\u2019t work either, and large sites often run into memory or file size limits.<\/p>\n\n\n\n

Manual<\/h3>\n\n\n\n

Manual backup means that you download the files yourself via SFTP or the file manager and export the database via phpMyAdmin or using WP DB Export<\/code> in WP-CLI. That's prone to errors and never happens automatically. I only do it as a one-time extra backup right before a major change, and I especially recommend it to developers.<\/p>\n\n\n\n

How often and where do you store your backups?<\/h2>\n\n\n\n

How often you back up your site should depend on how often it changes. A low-traffic business site can get by with a weekly backup, an active site needs daily backups, and an online store actually needs them even more frequently. Regardless, you should always create an extra backup right before an update or migration. For storage, I follow the 3-2-1 rule, which states that you should have three copies on two different types of storage, one of which is outside your hosting provider. In addition, keep multiple restore points over a longer period\u2014for example, daily, weekly, and monthly. After all, you often don\u2019t discover a hack until weeks later, and by then you\u2019ll want to be able to go back far enough. Also, check every now and then to make sure your automatic backups are actually running. More on this in how often you back up your data and the 3-2-1 rule<\/a>.<\/p>\n\n\n\n

What is often forgotten is that backup files contain sensitive data. They contain wp-config.php<\/code> including your database password and, for an online store, customer and order data as well. So never leave a backup as a ZIP file in a public web directory, because then anyone who guesses the filename can download it. Store backups in encrypted form and, preferably, within the EU. Under the GDPR, you are responsible for that personal data, even if it\u2019s stored in a backup.<\/p>\n\n\n\n

Restoring a backup and testing it beforehand<\/h2>\n\n\n\n

To restore a backup, restore the files and database from the same restore point, then resave the permalinks and clear the cache. You can read about which restore point to choose and what to check afterward in Restore a backup<\/a>. I think what you do before that happens is more important. A backup you\u2019ve never restored is just a hypothetical scenario\u2014just as insurance is only worth anything as long as the policy is still in effect. That\u2019s why I run a recovery test every quarter.<\/p>\n\n\n\n

    \n
  1. Choose any backup\u2014don't always pick the most recent one.<\/li>\n\n
  2. Restore it to a copy of your site, such as a clone in Installatron.<\/li>\n\n
  3. Check the login page, the homepage, a form, the media library, and\u2014if it's an online store\u2014the most recent orders.<\/li>\n\n
  4. Write down the date and the result so you can see if anything changes.<\/li>\n<\/ol>\n\n\n\n

    Restoring the system isn't always the solution, by the way. If your system has been hacked, you'll often just restore the malware along with it, because the vulnerability is still there. In that case, read this first Remove malware<\/a>, or leave the repair to WordPress hacked<\/a>. After a failed update, disabling a single plugin is often enough; see Site Down After an Update<\/a>.<\/p>\n\n\n\n

    With a WooCommerce online store, the situation is even more sensitive. Orders come in constantly, so a daily backup could miss an entire day\u2019s worth of orders. Therefore, never blindly restore an old database to a live online store; instead, first export the orders from after the restore point. Instructions on how to set this up can be found in WooCommerce Backup<\/a>. If you want backups and recovery tests to be a regular part of your online store maintenance, we'll include that in WooCommerce Management<\/a>.<\/p>\n\n\n\n

    WordPress Migration: Which Approach Is Right for Your Situation?<\/h2>\n\n\n\n

    A WordPress migration involves moving your entire site, and the approach you take depends on what\u2019s changing. If you\u2019re moving to a different hosting provider but keeping the same domain, only the server will change. You should test the new environment before the DNS change and make sure your email is transferred as well. That process is explained step by step in the Step-by-Step Guide to Moving Your WordPress Website<\/a>.<\/p>\n\n\n\n

    If your site gets a different domain or URL, you'll need to update the site URL, replace the old addresses in the database, and set up 301 redirects from the old to the new, so that visitors and Google can find you. To do this, read Change the WordPress URL<\/a>. If you're just transferring your domain to another registrar, your site will remain online, but you'll need to transfer your DNS records\u2014and especially your MX records\u2014with it; otherwise, your email will stop working. That's what this is about Transferring a Domain and DNS<\/a>. If you\u2019re putting a site from a staging environment or your own computer live, replace the test URLs and allow search engines to index the site again. And if you\u2019re switching from http to https, you\u2019ll need a valid SSL certificate, the correct site URL, and redirects.<\/p>\n\n\n\n

    Migration in Five Phases<\/h2>\n\n\n\n

    A WordPress migration to a different hosting provider takes place in five phases, from backup to post-migration verification. The main steps are outlined below. You can find the technical steps for each phase in the migration guide above.<\/p>\n\n\n\n

      \n
    1. Create a complete backup and an inventory of your DNS records and email accounts. Use your email hosting<\/a> If the mailboxes are on the same domain, move them before the domain change\u2014for example, using imapsync or by linking both accounts via IMAP in your email program.<\/li>\n\n
    2. Migrate the site to the new server, either using a migration plugin or manually. Installatron also has an import feature for an existing installation; to see if it works with your old host, please check with our support team.<\/li>\n\n
    3. Test the new site using a temporary URL or your hosts file while visitors are still on the old site.<\/li>\n\n
    4. Set the TTL one day in advance, and then update the DNS using the A record or the nameservers.<\/li>\n\n
    5. Check SSL, forms, email, and Google Search Console, and don't cancel your old hosting until a week has passed.<\/li>\n<\/ol>\n\n\n\n

      If you do it this way, your site won\u2019t go offline during the migration. There are, however, two pitfalls I often come across. The first is searching and replacing in the database. WordPress stores many settings as serialized data, and if you replace URLs in that data using a regular text editor, you\u2019ll corrupt it. So always use a tool that understands this, such as wp search-replace<\/code> in WP-CLI. The second pitfall involves online store orders. Orders received between the export and the DNS change will be lost. Therefore, move your online store during a quiet time, temporarily pause order processing, or transfer the database one last time as a final step.<\/p>\n\n\n\n

      Migrate it yourself or have someone else do it?<\/h2>\n\n\n\n

      Most people can move a small website without an online store on their own using a migration plugin. If you have an online store, multiple websites, your own email on the domain, or a tight deadline, I\u2019d recommend having someone else do it. A forgotten MX record or an error in the DNS can easily cost you more time than you\u2019d have liked to save. At Surver, the moving service<\/a> The entire migration process is included free with every package, with no limit on the number of sites or online stores. We\u2019ll migrate your website, email accounts (including folders), DNS records, and domain, and properly configure the site URL and redirects. An online store will be briefly in maintenance mode during the migration.<\/p>\n\n\n\n

      You don't have to handle everything yourself when it comes to backups, either. At Managed WordPress Hosting<\/a> We automatically create daily, weekly, and monthly backups, which are stored on external servers in separate data centers within Europe. With the shared hosting plans, you can restore them yourself at no cost using JetBackup 5 in cPanel\u2014separately for files, databases, or email accounts. You can create additional backups using Installatron, where you can also clone your installation for recovery testing. One thing to keep in mind is that the current state isn\u2019t automatically preserved during a restore, so be sure to create your own backup first. If you\u2019re on Surver Cloud, please contact support.<\/p>\n\n\n\n

      Backups are one part of maintenance. If you'd rather have someone else handle backups, updates, and checks entirely, check out WordPress maintenance<\/a>. You can read more in these articles.<\/p>\n\n\n\n