Moving a WordPress website to a new hosting environment can be straightforward when it is planned properly, but it also carries real risks if files, databases, URLs, or server settings are overlooked. A safe migration is not only about copying content. It also means preserving posts, pages, media, users, plugins, themes, SEO settings, and email-related configurations when they are part of the same hosting account. In a managed hosting or control panel environment such as Plesk, the process is often simpler because backups, databases, file management, and domain settings are available in one place.
If you want to migrate a WordPress website without losing data, the key is to work methodically: create a verified backup, move both files and the database, update configuration values where needed, test the site before switching traffic, and confirm that the DNS and SSL setup are correct after launch. The steps below cover both manual and control panel-based migration workflows, with practical notes for hosting platforms and Plesk-based environments.
What needs to be moved during a WordPress migration
A WordPress site is made of multiple parts, and all of them matter during migration. If one part is missing or incorrectly restored, the site may load with broken links, missing images, database errors, or login problems.
- WordPress core files – the application files located in the site’s document root.
- Media uploads – usually stored in
wp-content/uploads. - The database – contains posts, pages, comments, settings, users, menus, and metadata.
- The wp-config.php file – connects WordPress to the correct database and includes important settings.
- Plugins and themes – including custom code and child themes.
- Custom .htaccess or nginx rules – may affect redirects, caching, and permalink behavior.
- Domain and DNS configuration – determines where visitors are routed after the move.
In hosting environments, especially when changing providers or moving into a new managed server, it is important to identify whether email, subdomains, cron jobs, or SSL certificates are also tied to the account. These are often overlooked and can cause service disruption even when WordPress itself is migrated correctly.
Before you migrate: prepare the source website
Preparation reduces the chance of data loss and makes troubleshooting easier if something goes wrong. Before copying anything, audit the site and make sure you know exactly what is being moved.
Check the current WordPress setup
Confirm the WordPress version, active theme, and installed plugins. Note any custom code, must-use plugins, or caching layers. If the site uses a page builder or multisite setup, document that as well, because these configurations may require extra migration steps.
Take a full backup
Create a complete backup of both files and database. In a control panel such as Plesk, this is usually available from the backup manager. If you are using SSH, FTP, or a database tool, export the database separately and archive the website files.
A reliable backup should include:
- All WordPress files, including
wp-content - The MySQL/MariaDB database dump
- Any custom scripts, cron definitions, or configuration files
- Email data if mailboxes are hosted on the same account and need to be preserved
Store at least one backup off-server. If the destination environment has a problem during restoration, you will still have a safe copy.
Lower DNS TTL in advance
If you plan to switch the domain to a new server, reduce the DNS TTL at least 24 hours before migration if possible. A lower TTL helps DNS changes propagate faster, which reduces downtime during the cutover.
Freeze content changes if possible
For sites with frequent updates, orders, or user activity, avoid making content changes during the final migration window. If the site is an eCommerce installation or membership site, place it in maintenance mode or schedule the migration during a low-traffic period to avoid losing new orders, comments, or form submissions.
Choose the right migration method
There is no single best method for every WordPress migration. The ideal approach depends on the site size, the target host, and the tools available in the control panel.
Manual migration
Manual migration gives you full control and is useful when moving to a different hosting platform, when troubleshooting a broken site, or when the destination host does not offer a migration tool. It usually involves copying files and exporting/importing the database yourself.
Migration plugins
Plugins can simplify the process by packaging the site into an archive and restoring it on the new server. They are useful for small to medium sites, but they may fail on large databases, strict PHP limits, or restricted hosting accounts. Always verify the result instead of assuming the plugin completed everything correctly.
Host-assisted migration
Many managed hosting providers offer migration services or tools inside the hosting dashboard or Plesk interface. This is often the safest option for users who want minimal downtime and less manual work. Host-assisted migrations may include file transfer, database migration, domain updates, and testing on a temporary URL before launch.
How to migrate WordPress manually without losing data
The manual method is dependable because every part is visible and verifiable. It is also the best approach when you need to understand exactly what was transferred.
Step 1: Copy the website files
Download all WordPress files from the current host using FTP, SFTP, File Manager, or SSH. Make sure you include hidden files such as .htaccess if they exist. When moving to a Plesk environment, the document root is often under the domain subscription, so verify the correct path before uploading.
At minimum, preserve:
wp-adminwp-includeswp-contentwp-config.php- Root-level files such as
.htaccessand custom scripts
Step 2: Export the database
Use phpMyAdmin, the hosting control panel, or a command-line tool to export the WordPress database. If the database is large, prefer a compressed export format if supported. Make sure the dump includes all tables, especially any custom plugin tables.
Before importing, confirm the database name, username, password, and host on the destination server. In some hosting environments, the database host is not localhost and must be specified explicitly.
Step 3: Create the destination database
On the new hosting account, create a fresh database and a dedicated database user. Assign the required privileges. In Plesk, this can be done from the database management section linked to the subscription or domain. Avoid reusing old credentials unless you are intentionally keeping the same names and access pattern.
Step 4: Upload the files to the new host
Upload the website files to the destination document root. If the new host uses a different structure, make sure the files are not placed one level too deep or in the wrong subdirectory. This is a common reason for blank pages or 403/404 errors after migration.
Step 5: Import the database
Import the database dump into the new database. If the site is large, monitor for timeouts or incomplete imports. When using a hosting control panel, you may need to use phpMyAdmin or SSH import commands depending on the database size and server limits.
Step 6: Update wp-config.php
Edit wp-config.php so WordPress points to the new database credentials. Verify the following constants:
DB_NAMEDB_USERDB_PASSWORDDB_HOST
If table prefixes were customized, confirm they match the imported database tables. Also check any custom salt keys, caching definitions, or environment-specific values that may need adjustment.
Step 7: Fix the site URL if the domain or temporary URL changed
If the site is being tested on a temporary domain, staging URL, or subdomain, update the WordPress home and siteurl values carefully. Some plugins store absolute URLs in the database, so a simple change in settings may not be enough. Search and replace may be required for image links, page builder data, and serialized strings. Use a safe search-replace tool that respects serialized data.
Step 8: Test the site before changing DNS
Use a temporary URL, hosts file override, or staging environment to test the migrated site before switching the live domain. Confirm that:
- The homepage loads correctly
- Images and CSS are working
- Admin login works
- Permalinks resolve without 404 errors
- Contact forms submit correctly
- Any eCommerce checkout flow works as expected
Using Plesk for WordPress migration
Plesk can make migration easier because it combines file management, databases, domains, SSL, and backups in one interface. The exact workflow depends on the host configuration, but the general process is similar across many managed hosting environments.
Backup and restore in Plesk
If both servers use Plesk, you may be able to create a full subscription backup on the source server and restore it on the destination server. This is often the safest method because it preserves website data, database data, and configuration settings together.
When using backup/restore:
- Confirm that the backup includes domain content and databases
- Check whether mailboxes are included if needed
- Verify the restore destination has enough disk space
- Test the restored site under a temporary domain or preview URL
WordPress Toolkit
If WordPress Toolkit is available in Plesk, it can help with cloning, staging, or moving installations between domains inside the same server. It is useful for preparing a staging environment before final cutover. However, when migrating between different hosting providers, you still need to verify the database and domain mapping carefully.
Database and file manager tools
Plesk’s database manager and File Manager can be helpful for smaller migrations or final troubleshooting. If the site appears broken after the transfer, use these tools to check file paths, database credentials, and ownership/permissions.
Common data-loss risks during WordPress migration
Most migration problems are not caused by WordPress itself. They happen when file permissions, database imports, URL paths, or server settings are incomplete.
Missing uploads folder
If wp-content/uploads is not copied fully, older media files may disappear from posts and pages. This is one of the most common causes of “missing images” after migration.
Incomplete database export
If the export stops before completion, new tables from plugins or custom applications may be missing. This can break forms, memberships, analytics, or page builder layouts.
Wrong character encoding
Database encoding mismatches can corrupt special characters, especially in multilingual sites. Use the same collation and charset whenever possible, and verify content after import.
Serialized data broken by manual search and replace
WordPress stores some options in serialized format. If URLs are changed with a plain text editor or unsafe SQL query, data lengths may become invalid. Use a tool designed for WordPress-aware search and replace.
Incorrect file permissions
If permissions are too strict, WordPress may not be able to upload media or update plugins. If they are too loose, the site may be exposed to unnecessary risk. Use the host’s recommended permissions or the defaults suggested by the control panel.
Forgetting cron jobs or scheduled tasks
Some sites depend on scheduled tasks for backups, email notifications, or imports. After migration, check that system cron jobs or WordPress cron behavior still works on the new server.
Post-migration checklist
After the site is live on the new host, review the following items to confirm that the migration preserved the data and the site is functioning correctly.
- Log in to the WordPress admin dashboard and verify user access
- Check posts, pages, categories, tags, and menus
- Open several media files to ensure they load properly
- Test forms, search, comments, and checkout flows
- Review permalinks and regenerate them if needed
- Confirm SSL is active and the site redirects to HTTPS
- Inspect redirects, cache rules, and security plugins
- Verify email delivery if the website sends notifications
- Check Google Search Console, analytics, and sitemap settings
If you changed domains or server IPs, allow time for DNS propagation. During that period, some visitors may still reach the old server while others reach the new one. Keeping the old hosting account active for a short transition window helps avoid missed traffic or email issues.
How to reduce downtime during migration
Downtime can usually be minimized with preparation and a staged rollout. For many hosting setups, the actual transfer can happen while the old site remains online.
- Prepare the destination server in advance
- Lower DNS TTL before the migration window
- Use a staging URL or hosts-file test before launch
- Freeze content changes right before the final sync
- Take a final incremental backup or final database export
- Switch DNS only after validating the new site
For dynamic sites, a final database sync is especially important because content added after the initial backup can otherwise be lost. This applies to blogs with active comments, eCommerce stores, membership portals, and sites with customer submissions.
When to use a staging copy first
A staging copy is useful when the new host, PHP version, or caching setup differs from the old one. It allows you to confirm plugin compatibility, theme behavior, and server response before the live launch. This is particularly helpful in managed hosting environments where security rules, caching, and PHP handlers may differ from the source system.
Use staging first if:
- The site is business-critical
- The plugin stack is complex
- You are changing PHP versions or database engines
- The site uses custom code, page builders, or WooCommerce
- You need approval before the live cutover
FAQ
Will I lose posts, pages, or media during a WordPress migration?
Not if you migrate both the files and the database correctly. Posts, pages, comments, menus, and settings are stored in the database, while media files are usually stored in wp-content/uploads. Both parts must be transferred.
Do I need to reinstall WordPress on the new host?
Usually no. If you are moving an existing site, you can upload the existing files and database instead of installing a fresh copy. A fresh install is only needed if you want to rebuild the site from scratch or troubleshoot a severely damaged installation.
Can I migrate WordPress with only a plugin?
Yes, for many smaller sites a migration plugin is enough. However, for larger or more complex sites, manual migration or host-assisted migration is often safer because it gives you more control over the database, file transfer, and URL updates.
What is the safest way to migrate to a new hosting provider?
The safest approach is to create a full backup, restore it to the new server, test the site on a temporary URL, and only then update DNS. If available, using a hosting provider’s migration service or Plesk backup/restore workflow can further reduce risk.
Why does the site look broken after migration?
Common reasons include missing CSS files, incorrect site URLs, broken permalinks, plugin incompatibility, or file permission issues. Start by checking the browser console, WordPress settings, and the uploads folder, then review the web server configuration and error logs.
How do I migrate a WordPress site with a custom domain and email?
Move the website files and database separately from any mailboxes. If your email is hosted on the same account, back up and recreate mail accounts on the new server before changing MX records. If email remains with a different provider, update only the web hosting DNS records needed for the site.
Conclusion
Migrating a WordPress website without losing data is mostly about preparation, accuracy, and verification. Back up the full site, move both files and the database, update configuration values carefully, and test the restored installation before switching traffic. In hosting and Plesk-based environments, built-in tools for backups, databases, and file management can simplify the process and reduce the chance of mistakes.
When you follow a structured migration workflow, you preserve content, minimize downtime, and avoid the most common sources of post-migration problems. Whether you are moving to a new hosting provider, a managed server, or a different control panel environment, the same principles apply: verify everything, keep a rollback plan, and only consider the migration complete after the live site has been fully checked.