A WordPress migration is not simply a matter of copying a website directory to another server. It is a coordinated transfer of two separate components: the WordPress files and the database. A reliable WordPress migration checklist should therefore cover preparation, backup, configuration, stored URLs, rewrite rules and testing before the old installation is retired.
This process applies to a standard single-site migration, but the exact work depends on what is changing. A hosting move may involve different tasks from a domain or path change, while a new database environment can require updates in wp-config.php. Installed plugins, themes and integrations also determine which workflows need verification after the move.
Define the Migration Scope Before Touching the Site
Begin by recording the current environment and the destination environment. Treat hosting, database and URL changes as separate items rather than one general migration task. This makes it easier to identify which settings require attention and which should remain unchanged.
Determine whether the domain, URL scheme, path or subdirectory will change. Also establish whether the database server, database name or database username will be different at the destination. These details influence the review of wp-config.php and the handling of stored URLs.
A standard single-site checklist should not automatically be applied to WordPress Multisite. The available documentation covers standard single-site migrations in detail and does not treat Multisite as identical. If the site uses plugins, themes, forms, memberships, multilingual features, scheduled tasks or third-party services, record those elements now so they can be tested later.
Create a change inventory
Write down the old and new hosting locations, database details and public URLs. Note whether the change concerns only hosting or also includes a domain, scheme or path. Add a list of important site workflows and integrations. This inventory becomes a reference during configuration and post-move acceptance testing.
Build a Restorable WordPress Backup Set
A complete WordPress backup normally has two distinct parts: the site files and the database. Downloading the WordPress directory does not normally back up the database because it is stored separately, usually in MySQL or MariaDB. A file archive without a database export is therefore not a complete migration backup.
The file backup can include WordPress core files, plugins, themes, images and uploads, JavaScript and PHP files, other static files, wp-config.php and .htaccess where present. The database contains site content and settings, so it must be exported separately. Keep both components associated as one coordinated backup set created around the same time.
The typical sequence described in the documentation is to back up the database first and the WordPress files second. For restoration, files are generally restored first and the database is then imported. This sequence helps keep the two components connected as you prepare the destination.
Files and database are separate backup components
Answering the central backup question directly: yes, WordPress files and the database should be backed up separately because they are stored separately. The file archive should cover the applicable installation and site files, while the database export should be retained with it as part of the same migration set.
Create and retain a restorable backup before importing the database, changing URLs or editing configuration files. Do not expose wp-config.php, database exports or backup archives publicly because they may contain credentials, authentication keys or site data.
Verify the backup before migration
Confirm that both the file archive and database export are present, accessible and stored separately from the production server. Keep more than one backup copy in separate locations as operational protection, without treating this as a guarantee of recovery. Retain the original backup while the destination is being transferred and tested.
Prepare wp-config.php and Database Details
The question of which wp-config.php values may need to change depends on the database environment. Review the database connection settings if the database moves to another server, the database name changes or the database username changes. The database host entry should also be checked against the destination environment.
Back up wp-config.php before editing it and keep database credentials private. A domain-only move may not require database credential changes when the database environment remains unchanged, but that does not remove the need to verify the public WordPress URLs.
Database connection review
Compare the destination database server, database name, database username and related connection values with the settings in wp-config.php. Apply only the changes required by the new database environment. Distinguish these connection settings from the WordPress Address and Site Address, which describe where the files reside and where visitors access the site.
If the temporary RELOCATE constant described in the documentation is used for recovery, remove or disable it immediately afterward because leaving it enabled can be insecure.
Handle WordPress URLs Safely
When a domain or path changes, old URL references can remain in the database. They may affect links, images, theme display, widgets, menus or plugin-specific options. URL handling should therefore be planned separately from the file transfer and database import.
Create a verified, restorable backup before changing stored URLs. Do not use an unqualified raw SQL search-and-replace across the database because serialized values can become corrupted. Use a method or procedure that understands serialized data.
WordPress Address versus Site Address
WordPress distinguishes between the WordPress Address (URL) and the Site Address (URL). The WordPress Address identifies where the WordPress core files reside. The Site Address identifies the public address visitors use.
After migration, verify both settings in Settings > General. Each should contain the intended destination, use the correct scheme and, according to the documentation, should not have a trailing slash. Review the settings separately rather than treating them as interchangeable values.
Serialized data and GUID preservation
Stored URLs can appear inside serialized data, which is why a blanket database replacement is unsafe. Use serialization-aware procedures and verify the result through the migrated site. Do not change wp_posts.guid values during a domain or path migration. WordPress documentation explains that GUID values are intended to remain stable even when the site changes domain or location.
Move the Files and Database in a Controlled Sequence
Keep the original backup set in a safe location before modifying the destination. Transfer the applicable WordPress files, including the configuration and rewrite files where present, then import the database into the destination environment. Apply only the database connection changes required by the new environment.
Confirm the destination directory structure and review file permissions as part of the move. Keep the file backup and database export available while the new installation is being checked. Do not retire, delete or overwrite the old installation before the new site and critical workflows have been verified.
Transfer and restore checklist
- Confirm that the file archive and database export are available.
- Transfer the WordPress files to the destination.
- Import the database into the destination database environment.
- Review and update the required database connection values in
wp-config.php. - Check the destination structure, permissions and configuration files.
- Keep the original installation and backup set available for rollback while testing.
Back up .htaccess and wp-config.php before editing them. A syntax or redirect error can make the site unavailable.
Refresh Permalinks, Rewrites and Redirects
After the files and database have been moved, review permalink rules, custom rewrites and redirects. Update .htaccess where necessary and confirm that rules refer to the new location. A migration can appear successful while old paths, custom routes or redirects still point to the previous installation.
Test representative current URLs and old URLs. Confirm that old addresses redirect to the intended destination and that internal links do not continue to reference the old domain or path. Keep the old installation available until this behavior has been confirmed.
Permalink and redirect verification
Refresh or regenerate permalink rules when required by the migrated configuration. Check representative pages, posts, media URLs and any custom rewrite paths. Review each important redirect rather than assuming that all rules transferred correctly. Back up .htaccess before editing it because redirect or syntax errors can make the site unavailable.
Run a Post-Move Acceptance Test
Testing should begin before the old installation is shut down or deleted. The official documentation does not provide one exhaustive test matrix for every site type, so adapt the acceptance pass to the site configuration and installed products.
Start with the administration area and public front end. Verify the intended WordPress Address and Site Address, login, navigation, representative pages and posts, media links and search. Review menus, widgets, plugin-specific options, file permissions and remaining references to the old URL.
Core WordPress checks
- Open the WordPress administration area and public front end.
- Test login, navigation, representative pages and posts.
- Check images, uploads and other media links.
- Review menus, widgets and plugin-specific settings.
- Check file permissions and remaining old URL references.
- Test permalinks, custom rewrites and redirects.
Document unresolved issues instead of treating the migration as complete merely because the homepage loads. Keep a verified rollback backup available while those issues are being resolved.
Site-specific workflow checks
Extend the test plan to the workflows that are actually installed. For a WooCommerce store, this may include checkout and payment gateways. Where applicable, test forms, transactional email, memberships, multilingual switching, scheduled tasks, CDN behavior and third-party integrations. These are site-specific checks, not universal WordPress requirements.
Record the outcome of each relevant workflow before finalizing the move. Test the migrated copy before shutting down or deleting the old site, and keep the old installation and its backup available until the new site, redirects and critical business workflows have been verified.
A reliable WordPress migration checklist joins a separate file backup with a database export and keeps both as one restorable set. It reviews the database connection values in wp-config.php, verifies the WordPress Address and Site Address, handles serialized data carefully and preserves GUID values. It also refreshes permalinks, rewrites and redirects, then tests both core functions and site-specific workflows. The exact acceptance checks depend on the configuration and installed products, so do not assume that one test list fits every site. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.