A manual WordPress migration has two inseparable parts: a complete copy of the site’s files and an export of its database. Copy the files first, import the database, update wp-config.php, and use a serialization-aware URL replacement when the domain or path changes. Keep the old site and both backup components until the new installation passes login, media, permalink, plugin, theme, and error-log checks.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What a manual WordPress migration actually moves
WordPress does not need to be reinstalled when you move it to another server or another location on the same server. You are moving an existing installation, not creating a new one. The migration is complete only when both of these coordinated assets arrive at the destination:
As an Amazon Associate I earn from qualifying purchases.
- The file tree: WordPress core files,
wp-content, plugins, themes, uploads, JavaScript, PHP files,.htaccesswhere applicable, andwp-config.php. - The database: an SQL export containing posts, pages, comments, settings, users, metadata, menus, widget data, and plugin or theme records stored in MySQL or MariaDB.
An SQL dump is not a complete website backup. It does not contain themes, plugins, media uploads, wp-config.php, or other files. Conversely, a file archive cannot recreate posts, users, settings, or metadata. WordPress therefore treats the database and files as one backup set.
Choose the right migration plan before touching the live site
The sequence is broadly the same, but the risk and the URL work vary according to the move. Decide which case describes your project:
| Situation | What usually changes | Main concern |
|---|---|---|
| Same domain, new server | Files, database connection, DNS, and server rules | Configuration and routing; URLs may need little or no editing |
| New domain, same site | Files, database connection, and stored URLs | Safe replacement of serialized and non-serialized values |
| New subdirectory or path | Path settings, rewrite rules, and stored links | Correct home/site URL and permalink behavior |
| Single-site WordPress | One database and one document root | Consistent table prefix and configuration |
| Multisite network | Network tables, site paths, domain or subdomain rules | Network-specific URL, .htaccess, and wp-config.php changes |
Also check the practical constraints. A large database may exceed phpMyAdmin upload or execution limits; SSH and WP-CLI provide a more reliable route when available. A move with almost no downtime needs a final synchronization plan, while a low-traffic site can often tolerate a maintenance window. Most importantly, choose a URL-replacement method that understands PHP serialized data.
1. Freeze a rollback point
Do not begin by deleting or overwriting the source site. First create a known-good rollback set and record the configuration needed to reproduce it.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Record the source environment
- Current domain, protocol, and document-root path.
- Database name, table prefix, and database host.
- PHP version and other runtime details used by the site.
- Active plugins, active theme, scheduled cron jobs, and special web-server rules.
- Any custom constants or server configuration that affects URLs, caching, redirects, or uploads.
Create both backup components
- Export the complete database to an SQL file.
- Copy the entire WordPress installation, including
wp-contentandwp-config.php. Do not limit the copy to visible pages or only the uploads directory. - Store the SQL dump and file archive together, preferably in more than one location. An external hard drive is a practical offline copy for this rollback set.
- Keep the original site, original database, and original files available until the destination has been tested and traffic is stable.
WordPress describes the files and database as a single “backup set.” If either part is missing, a later restore can be incomplete.
2. Copy the complete WordPress files
Download or archive the entire installation from the old server. The copy must include core files, plugins, themes, uploaded media, JavaScript, PHP, and static assets. Preserve hidden files such as .htaccess when the source uses them.
Archive before transferring when possible
Creating a compressed archive on the source server reduces the number of individual transfers and preserves permissions more consistently. After transferring it, extract it into the destination document root. If you copy files individually, verify that the transfer did not skip hidden files, symbolic links, or files whose names contain spaces.
Check the file set
- Confirm that
wp-admin,wp-includes, and the root WordPress files are present. - Inspect
wp-content/plugins,wp-content/themes, andwp-content/uploadsfor expected contents and recent dates. - Confirm that
wp-config.phpwas copied but is not publicly downloadable through the web server. - Retain ownership and permissions suitable for the destination server; do not make the whole tree world-writable as a shortcut.
3. Export the source database
Use the source host’s MySQL/MariaDB interface, command-line tools, or an equivalent export function to create an SQL dump. The export should include the WordPress tables and their data. Keep the original database untouched until validation is complete.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWhat the SQL dump contains
The database normally holds posts, pages, comments, users, settings, metadata, menus, widgets, and data created by plugins and themes. It does not hold the PHP code for those plugins and themes, the media files in wp-content/uploads, or the configuration file.
When an export fails
- Upload or execution limits: export from the command line or ask the host for a dump rather than repeatedly increasing a browser timeout.
- Large tables: use a method that can stream or compress the export and verify that the resulting file is not truncated.
- Character-set problems: retain the dump’s character-set and collation statements; changing them casually can corrupt non-ASCII content.
4. Prepare the destination server
Before importing anything, create an empty MySQL or MariaDB database and a database user. Grant that user the permissions WordPress requires, then note every value because they will be needed in wp-config.php.
| Value | Where it is used |
|---|---|
| Database name | DB_NAME |
| Database username | DB_USER |
| Database password | DB_PASSWORD |
| Database host | DB_HOST; it may be a hostname, socket, or host-plus-port value supplied by the host |
| Table prefix | $table_prefix; it must match the imported table names |
Upload the copied files to the destination document root or the intended subdirectory. Make sure the web server’s virtual host points to that location before testing.
5. Edit wp-config.php for the new database
Open the copied configuration file and change the database constants whenever the destination values differ:
Free tools Windows power users keep installed
One-click scans. No signup required.
define( 'DB_NAME', 'destination_database' );
define( 'DB_USER', 'destination_user' );
define( 'DB_PASSWORD', 'destination_password' );
define( 'DB_HOST', 'destination_host' );Preserve the existing authentication keys, salts, debugging choices, and other site-specific constants unless you have a separate reason to change them. A changed salt set logs users out; it is not required merely because the server changed.
Check URL constants before importing
Look for WP_HOME and WP_SITEURL definitions in wp-config.php. These constants can override the corresponding values in the database. If they still point to the old domain or path, the site may continue redirecting there even after the database has been edited. Remove or update them deliberately rather than assuming the database values control the final URL.
Rank #3
6. Import the database after the files are in place
WordPress’s restore guidance puts the files first and the database import second. With the destination database selected, import the SQL dump using the host’s database tool or a command-line client.
- Confirm that the destination database is empty or that you have intentionally prepared it for this import.
- Start the SQL import and wait for it to finish; do not close a browser tab during a long import unless the host confirms it continues server-side.
- Check that the expected WordPress tables exist and that their names use the same prefix declared by
$table_prefix. - Review the import output for errors, skipped statements, or a size limit that stopped the process early.
If the imported tables use wp7_ but wp-config.php declares wp_, WordPress will behave as though the database is empty. Correct the prefix mismatch before diagnosing anything else.
7. Update domains and paths without breaking serialized data
A same-domain move may need no broad URL replacement. A domain, protocol, hostname, or subdirectory change does. Stored references can appear in the home and siteurl options, post content, media URLs, widgets, menus, and plugin settings.
Why a blind SQL replacement is dangerous
PHP serialized values include the length of each stored string. Replacing a short hostname with a longer one changes that length. A blind find-and-replace can therefore make serialized options unreadable, breaking widgets, menus, plugin settings, or other structured data even when ordinary post text appears correct.
Use a serialization-aware method
WP-CLI’s search-replace command is designed to process serialized data and can write the transformed database to an export file. A typical dry-run and replacement sequence is:
wp search-replace 'https://old.example' 'https://new.example' --all-tables --dry-run
wp search-replace 'https://old.example' 'https://new.example' --all-tables --export=updated.sqlRun the command from the WordPress directory, review the dry-run counts, and take a fresh database backup before the actual replacement. Include the old path in both search and replacement strings when the site moves between a root and a subdirectory. The exact table scope should be chosen carefully if the database contains unrelated applications; --all-tables is appropriate only when those tables are intended to be migrated and the command’s behavior has been reviewed.
Recommended Free Tools
Set the canonical home and site URLs
Ensure the destination values for home and siteurl match the intended protocol, domain, and path. If you use constants in wp-config.php, make those values agree with the database or remove the constants. Search for the old URL again after replacement so that leftover references in content, menus, widgets, and plugin settings can be investigated rather than silently redirecting visitors back to the old host.
8. Rebuild routing and test the new installation
Test on the destination before changing public DNS. A temporary hosts-file entry, staging hostname, or host-provided preview URL lets you exercise the site while the old site remains available.
Core access tests
- Open the front page and several representative posts, pages, archives, and custom post types.
- Log in to
/wp-admin/, visit the dashboard, and confirm that users and roles are present. - Open Settings and confirm the site URL, timezone, reading settings, media settings, and other values important to the site.
- Check that the active theme renders correctly and that expected plugins are active without fatal errors.
Media, links, and interactive features
- Open images from old and recent uploads, downloadable files, galleries, and featured images.
- Follow internal links, navigation menus, pagination, feeds, and canonical links.
- Submit forms, test search, and verify email-dependent workflows where the site uses them.
- Inspect browser developer tools and server error logs for 404, 500, mixed-content, permission, or PHP-version errors.
Refresh permalinks and rewrite rules
When the server, document root, domain, or path changed, go to Settings > Permalinks and save the existing structure without changing it. This flushes WordPress rewrite rules. Also verify that the destination has the correct .htaccess content for Apache or the equivalent rewrite configuration for the web server in use. A site that loads at the home page but returns 404 errors for individual posts usually has a routing or rewrite problem, not a missing database.
9. Cut over traffic with a controlled final sync
Once the destination passes testing, plan the DNS and final-content transition.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11- Lower the DNS TTL ahead of the planned change when the DNS provider allows it. This can reduce how long resolvers retain the old address, but it cannot force every resolver or browser to switch immediately.
- Put the old site into a controlled maintenance state during the final synchronization if new comments, orders, registrations, or edits must not be lost.
- Take a final database export and copy any files uploaded since the first transfer.
- Import the final database changes, repeat any required URL-safe replacement, and recheck the destination.
- Point DNS to the new server and monitor access logs, error logs, forms, media, and administrator reports.
Do not erase the old files or database when DNS changes. Retain the original rollback set and the new destination backup until traffic is stable and you are confident no late-arriving data needs recovery.
Common failure symptoms and precise fixes
| Symptom | Likely cause | First checks |
|---|---|---|
| “Error establishing a database connection” | Wrong database name, user, password, host, permissions, or an unavailable database server | Compare all four DB_* constants with the destination credentials and test the user’s grants |
| WordPress asks for installation | Wrong table prefix, failed import, or connection to an empty database | List destination tables and compare their prefix with $table_prefix |
| Home page redirects to the old domain | Old home/siteurl values or URL constants in wp-config.php |
Check both database options and WP_HOME/WP_SITEURL |
| Widgets, menus, or plugin settings disappear | Broken serialized data after a raw text replacement | Restore the pre-replacement database and repeat with a serialization-aware tool |
| Images are broken | Uploads were not copied, URLs still reference the old location, or file permissions block access | Inspect wp-content/uploads, image URLs, and web-server permissions |
| Posts return 404 while the front page works | Rewrite rules or .htaccess were not rebuilt for the new server/path |
Save Settings > Permalinks and check the server’s rewrite configuration |
| White screen or HTTP 500 | PHP incompatibility, plugin/theme fatal error, missing extension, or permissions problem | Read PHP and web-server logs, then temporarily disable the suspected plugin or theme |
Multisite migrations need network-level checks
A Multisite move is more than copying one site’s tables. Review the network’s wp_blogs and wp_site records, the options table for each site (for example, wp_2_options), and every domain and path value. Confirm whether the network uses subdomains or subfolders and whether that structure changes at the destination.
- Update network domain and path values consistently.
- Check
wp-config.phpconstants that enable Multisite and define the network’s domain, path, and cookie behavior. - Rebuild the network’s
.htaccessor equivalent rewrite rules when the server or path changes. - Test the network dashboard, the main site, several subsites, media uploads, and administrator access for each site.
Do not apply a single-site URL replacement plan to a network without first mapping every site’s domain and path.
A final migration checklist
- Complete source file archive exists, including
wp-content, uploads, hidden files, andwp-config.php. - SQL export completed without truncation or import errors.
- Original files and database are retained as a rollback set.
- Destination database, user, permissions, host, and table prefix are recorded.
- Destination files are in the correct document root.
DB_NAME,DB_USER,DB_PASSWORD, andDB_HOSTare correct.WP_HOMEandWP_SITEURLconstants have been checked.- Database was imported after the files and uses the expected prefix.
- Domain/path replacement, when required, used a serialization-aware method.
- Login, representative content, media, downloads, forms, search, plugins, theme output, and logs were tested.
- Permalinks were saved and rewrite rules checked.
- Final DNS cutover and any last database/file synchronization were completed.
- Old and new backup sets remain available until monitoring confirms stability.
Bottom line: migrate both assets, then validate before switching off the old site
A dependable manual migration is a controlled sequence: preserve a rollback point, copy every WordPress file, export and import the database, update the destination configuration, replace changed URLs without damaging serialized values, refresh routing, and test the real site workflows. Keeping the old installation until those checks pass is what turns a risky one-way move into a recoverable migration.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
