Moving a WordPress site with All-in-One WP Migration can simplify a standard host-to-host move because the plugin packages the WordPress site into a .wpress backup that can be imported into another WordPress installation. The migration still needs planning: create an independent backup, confirm the destination environment, test the restored site and keep the old hosting account available until the move is verified.
This guide is specifically for a WordPress migration using All-in-One WP Migration. If you are moving a non-WordPress site or want a platform-neutral process, use our general website migration guide instead.
Before You Migrate the WordPress Site
Record the current WordPress version, PHP version, active theme, plugins, custom code, domain settings, DNS records and any email services connected to the hosting account. Check the live website for existing errors before the move so you do not mistake an old issue for a migration problem later.
Confirm that the destination environment supports the site’s WordPress and PHP requirements and has enough storage for both the imported site and the migration archive. If you are comparing a new managed WordPress environment, use the current WordPress hosting page for live plan limits and features rather than relying on package details in a tutorial.
1. Create an Independent Backup
Before using the migration plugin, create a separate backup of the website files and database where possible. Store the recovery copy outside the hosting account being migrated.
A plugin export is useful, but it should not be your only recovery option for an important production site. Verify that the backup exists and that its size is plausible before continuing.
2. Export the Site With All-in-One WP Migration
Install and activate All-in-One WP Migration on the source site. In the WordPress dashboard, open the plugin’s Export screen and choose the File export option.
ServMask’s official user guide states that the File option creates a backup archive in the plugin’s backup folder and allows the resulting file to be downloaded. Other export destinations require the relevant ServMask extensions. See the official All-in-One WP Migration user guide for the current workflow.
Wait for the export to complete and save the resulting .wpress file somewhere safe. For active stores, membership sites or websites receiving frequent form submissions, remember that changes made after the export are not automatically included in that archive.
3. Check Upload and Storage Limits Before Importing
Do not assume that a fixed “free plugin limit” applies to every installation. ServMask explains that the upload limit displayed by All-in-One WP Migration is derived from the hosting server’s configuration. PHP upload settings, web-server limits, firewall rules, CDN restrictions and available disk space can all affect the import process.
If the destination shows an upload limit below the size of your .wpress file, review the server settings or contact the hosting provider before starting the import. ServMask’s upload-size guidance explains how those limits are determined.
4. Prepare WordPress on the Destination Host
Create the destination site and install a clean WordPress instance. Confirm that the domain or temporary test address works, PHP is compatible, SSL can be enabled and enough disk space is available.
Install All-in-One WP Migration on the destination WordPress site. Avoid building new production content on this fresh installation before import because the migration will replace matching WordPress content and settings.
5. Import the .wpress Backup
Open All-in-One WP Migration on the destination site and use the Import screen to select the exported .wpress file. The plugin warns that the imported backup will replace existing website data before the final restore step.
Allow the import to finish without interrupting the process. The time required depends on site size, server resources and upload conditions.
After migration, ServMask notes that the user accounts and passwords from the imported site move with the site. Log in using credentials from the source website, not credentials created only for the temporary destination installation. Their migration instructions also recommend resaving the WordPress permalink settings after import. See the official migration instructions.
6. Test the Migrated Site Before Changing DNS
Test the restored site on the destination server before directing normal visitors to it. Depending on the hosting setup, this may use a preview URL, staging method or local hosts-file override.
Review:
- homepage and important landing pages,
- navigation and permalinks,
- images and downloadable files,
- forms and email notifications,
- WordPress login and user roles,
- search and custom functionality,
- e-commerce checkout in an appropriate test mode,
- redirects, robots.txt, XML sitemaps and canonical URLs,
- SSL and mixed-content warnings.
If links return 404 errors after the import, review and resave the permalink settings before assuming the content itself is missing.
7. Review DNS, Email and SSL Separately
A WordPress plugin migration does not automatically mean that every hosting-account service has moved. DNS zones, mailboxes, MX records and other server-level settings may require separate work.
If email stays with the existing provider, preserve the required MX and authentication records. If email is moving too, plan that migration independently and verify SPF, DKIM and DMARC after the change.
Make sure the destination site has a valid certificate before forcing HTTPS traffic to it.
8. Change DNS Only After Testing
Once the destination copy works correctly, update the relevant DNS records so the domain points to the new environment. DNS caches expire at different times, so some visitors may temporarily reach the old server while others reach the new one.
Keep the old hosting account available during this transition. Avoid making independent content changes on both copies of the website because those versions can diverge.
9. Run Post-Migration Checks
After traffic begins reaching the new server, review:
- forms and transactional email,
- server and application logs,
- analytics and tag loading,
- scheduled tasks and cron jobs,
- cache configuration,
- backup schedules,
- search-engine directives and sitemaps,
- payment or API integrations used by the site.
Create a fresh backup of the working destination site. Do not cancel the old hosting service until DNS, website functions, email dependencies and other critical services have been verified.
When All-in-One WP Migration May Not Be the Best Method
A plugin-based migration may be less suitable when the website is extremely large, server restrictions prevent reliable import, the site has complex infrastructure outside WordPress, or the migration must synchronize high-volume live transactions with minimal data loss.
In those cases, a host-assisted migration, command-line workflow or infrastructure-specific process may be more appropriate. The method should match the site’s size, architecture and tolerance for downtime.
Frequently Asked Questions
What does All-in-One WP Migration move?
The plugin creates a WordPress backup archive containing the site data it exports, including the WordPress database and site files handled by the plugin. DNS zones, external email systems and other hosting-account services still need separate review.
Does All-in-One WP Migration have one fixed upload limit?
Not for every installation. ServMask states that the upload limit displayed by the plugin comes from the destination server’s configuration. Other server, firewall, CDN and storage limits can also affect imports.
What should I check after a WordPress migration?
Check permalinks, images, forms, login, user roles, plugins, checkout features, redirects, SSL, email delivery, analytics, scheduled tasks, backups, robots.txt and XML sitemaps before considering the migration complete.
Should DNS be changed before testing the new WordPress site?
No. Test the migrated copy first, then change DNS after important pages and functions work correctly.
Should I cancel the old hosting account immediately after migration?
No. Keep it available until the domain is consistently reaching the new server and website, email and other dependencies have been verified.