How to Back Up Your Website Before a Hosting Migration or Update

Overview

A useful website backup is more than a downloadable zip file. Before any migration or major update, you need a backup that is complete, current, accessible, and restorable. Those four words matter because many failed recoveries happen even when a backup technically exists. The archive may be outdated, missing the database, stored only on the same server, or saved in a format the new host cannot easily use.

For most websites, a pre-migration backup should include five categories of data:

• Website files: application code, themes, plugins, uploads, media, configuration files, and static assets.
• Database: content, settings, user accounts, ecommerce orders, form entries, and other dynamic data.
• Server and application configuration: PHP version notes, rewrite rules, cron jobs, environment variables, caching rules, and web server settings where applicable.
• DNS and related service records: current nameservers, A records, CNAMEs, MX records, TXT records, and any email or verification settings.
• Recovery notes: login URLs, control panel access, SSH credentials, plugin license references, and the exact steps required to restore the site.

The safest approach is the 3-2-1 mindset adapted for websites: keep at least one local copy, one off-server copy, and one provider-level or platform backup if available. In practical terms, that means you do not rely only on a backup tool inside the same hosting account you are about to change.

If your site runs on managed cloud hosting or managed WordPress hosting, your provider may offer snapshots or automatic backups. Those are useful, but they should not replace your own export before a risky change. Provider backups are often designed for operational recovery, while your own backup can be tailored for migration and validation.

Think of the backup process as three stages:

1. Create: export all required data.
2. Verify: confirm the archive is complete and readable.
3. Test restore: recover the site in staging or another isolated environment if the change is significant.

If you are planning a broader move, these related guides may help with adjacent tasks: WordPress Hosting Checklist: What to Compare Before You Switch, How to Connect a Domain to Your Hosting Provider, and How to Transfer a Domain Name Safely: Timeline, Costs, and Checklist.

Checklist by scenario

Use the scenario below that best matches your situation. In every case, the core rule is the same: capture both files and data, document the environment, and keep a copy outside the current host.

1. Shared hosting or control panel migration

This is common when moving between hosts that use cPanel, Plesk, DirectAdmin, or a custom panel.

• Export the full home directory or site root using the file manager, SFTP, or SSH.
• Dump all related databases, not just the primary one. Some sites use separate databases for applications, forums, or analytics tools.
• Download hidden files such as .htaccess, configuration files, and environment files if your setup uses them.
• Record the current PHP version, active extensions, cron jobs, SSL setup, and any custom redirects.
• Take screenshots of DNS zones, email routing, and panel-specific settings.
• Save a separate list of installed applications, plugins, themes, and their versions where possible.
• Store the backup in cloud storage or local encrypted storage, not just the current account.

If the current provider offers a full account backup, save one copy of that as well. Even if the destination host cannot import it directly, it can be useful during recovery.

2. WordPress backup before update or migration

If you need to backup a WordPress site before update or before switching hosts, keep the workflow simple and complete.

• Back up the full wp-content directory, including uploads, themes, plugins, and any custom assets.
• Export the WordPress database.
• Save core configuration files such as wp-config.php and server rewrite rules.
• Note the active theme, must-use plugins, caching plugins, security plugins, and backup plugins.
• Pause or account for dynamic changes during the backup window, especially ecommerce orders, bookings, memberships, or form submissions.
• Put the site in maintenance mode if needed for consistency, or schedule the backup during a low-traffic period.
• Create a staging restore if the update is major, such as a PHP version change, theme framework update, or plugin stack cleanup.

WordPress sites often fail after migration because of serialized data, path changes, caching conflicts, or missing media. A backup that includes only files or only the database is rarely enough.

If you are evaluating where to move next, this WordPress hosting checklist is a useful companion read.

3. Ecommerce, membership, or other dynamic sites

These sites need extra care because data changes continuously.

• Identify what changes every minute: orders, subscriptions, inventory, support tickets, customer profiles, or appointment records.
• Shorten the maintenance window between final backup and DNS cutover.
• Export transactional databases as close as possible to the migration time.
• Pause background jobs that could write conflicting data during transfer.
• Confirm payment gateway webhooks, shipping integrations, and email notifications can be reconnected after the move.
• Take an additional post-cutover backup once the new environment is live and stable.

If performance is part of the migration reason, pair your backup plan with a hosting review focused on speed and scaling. These guides can help: Best Hosting for WooCommerce Stores and How to Choose Web Hosting for Better Core Web Vitals.

4. Static sites, site builders, and headless front ends

These are usually easier to back up, but the hidden dependencies still matter.

• Export the site files or generated build output.
• Save the source repository if one exists.
• Back up media libraries, form destinations, CMS content sources, and deployment configuration.
• Record DNS settings, CDN rules, redirects, and environment variables.
• Save access to third-party services such as forms, email delivery, analytics, and image storage.

If the site builder is proprietary, verify whether your export can be restored elsewhere. Some builder backups are platform-specific and are not true migration backups.

5. VPS, cloud server, or container-based deployment

For more technical teams, application-level backups are still required even if you have infrastructure snapshots.

• Create a database dump before taking a server snapshot.
• Archive application files, persistent volumes, and uploaded assets separately.
• Export infrastructure-as-code, deployment scripts, and environment variables without exposing secrets insecurely.
• Document web server configs, firewall rules, process managers, cron jobs, and SSL certificate paths.
• Verify backup retention and snapshot location if moving across regions or providers.
• Test whether the backup can be restored on a fresh instance, not only on the original server.

A machine snapshot can help recover a broken server, but it is not always the best tool for selective site restoration. Pair snapshots with clean application exports.

What to double-check

Once you have created the backup, stop and validate it. This is the part many teams skip, and it is where a website backup before migration becomes truly dependable.

Backup completeness

• Can you see both the files and the database export?
• Are media uploads included?
• Did hidden files transfer correctly?
• Did you capture custom configuration outside the web root?
• Are cron jobs and scheduled tasks documented?

Backup freshness

• When was the backup created?
• Did new orders, posts, or user registrations happen after that time?
• Do you need a final differential or last-minute export before cutover?

Restore readiness

• Can the archive be opened without corruption?
• Do you know which database credentials and file paths to update on restore?
• Have you tested the site in staging or on a temporary URL?
• Do you know how to reverse the change if production fails?

Environment compatibility

• Does the new host support the required PHP or runtime version?
• Are required extensions, memory limits, and upload limits available?
• Will caches, object storage, or CDN settings need adjustment after restore?

Security and access

• Are backups encrypted at rest if they contain customer or account data?
• Who has access to the backup files?
• Have you removed old credentials from notes or exports?
• Do SSL, DNS, and email settings have a documented recovery path?

Security often gets overlooked in backup planning. If your move includes certificate changes, review SSL Certificate Setup Guide: How to Secure Your Website on Any Host. If the migration changes DNS or mail flow, also review Business Email on Your Domain.

One practical habit helps more than any tool choice: keep a plain-language restore document. It should answer five questions quickly:

1. Where is the latest verified backup stored?
2. What files and databases belong to this site?
3. What versions and dependencies does it require?
4. How do you restore it in staging?
5. How do you roll back production if needed?

Common mistakes

Most backup failures come from process gaps rather than missing software. Here are the mistakes that cause the most trouble during hosting migration or updates.

Relying on one backup source

If your only backup is stored on the same hosting account you are replacing, it is not enough. Keep at least one independent copy.

Backing up files but not the database

This is especially common with WordPress, ecommerce platforms, forums, and custom CMS setups. The site may look present in the file archive while the actual content and settings are missing.

Ignoring dynamic content

Orders, comments, bookings, support messages, and customer registrations can be lost in the gap between backup and cutover. Dynamic sites need a tighter migration window and often a final sync.

Skipping restore tests

A backup you have never restored is still unproven. Even a basic staging restore will catch missing paths, incompatible versions, broken permissions, or incomplete exports.

Forgetting DNS, email, and external services

Website uptime can look fine while contact forms, business email, or transactional messages silently fail. Document MX records, TXT records, webhook endpoints, API keys, and any third-party dependencies.

Leaving out performance and caching settings

Sites moved to faster cloud website hosting can still perform poorly if old cache rules, broken image paths, or misconfigured CDN settings follow them. After restore, validate performance and monitoring with Website Speed Optimization Checklist for Cloud Hosting, CDN vs Cloud Hosting, and Website Uptime Monitoring Guide.

Not documenting access

Migration windows become chaotic when nobody knows which login controls DNS, where the backup is stored, or who can restore the database. Keep access information organized and limited to the right people.

Assuming host snapshots solve everything

Infrastructure snapshots are useful, but they may not be portable or convenient for selective recovery. They are one layer, not the full backup strategy.

When to revisit

The best backup checklist is one you return to before any meaningful change. Revisit and update this process when any of the following happens:

• You are about to migrate to new cloud hosting, managed cloud hosting, or a new control panel.
• You plan a CMS core update, theme rebuild, plugin overhaul, or PHP version change.
• You add ecommerce, memberships, bookings, or any feature that creates more dynamic data.
• You change DNS, nameservers, CDN configuration, SSL handling, or business email routing.
• You move from shared hosting to VPS, container, or scalable hosting infrastructure.
• You change backup plugins, deployment workflows, or recovery ownership inside your team.
• You are entering a seasonal traffic period and cannot afford rollback delays.

For a practical routine, use this short action plan before every migration or major update:

1. 24 to 72 hours before: audit what must be backed up, confirm access, and clean up obsolete files you do not need to carry forward.
2. Before the change window: create full backups of files and databases, then store them off-server.
3. Immediately after backup: verify archive size, open the files, and confirm the database export is valid.
4. If the change is significant: restore in staging and test key pages, logins, forms, checkout, and admin functions.
5. At cutover: freeze or monitor dynamic writes, complete the final sync, and update DNS carefully.
6. After launch: test SSL, redirects, forms, email, performance, and uptime alerts.
7. After stabilization: take a fresh backup of the new environment and update your recovery document.

A calm migration usually starts with a boring, well-documented backup. That is a good sign. The objective is not just to save data. It is to make recovery straightforward if the update fails, the new host behaves differently, or a small configuration issue causes a larger outage than expected. Keep this checklist close, adapt it to your stack, and review it whenever your hosting workflow changes.