Moving a WordPress website to a new host can improve how you manage hosting, but a rushed transfer can leave visitors facing errors, stale content or a checkout that no longer works. A WordPress migration usually involves the site files, database, configuration and domain routing; it may also affect email if DNS records are changed without checking them. The work is not finished when a copy appears on the new server. Before starting, identify what the current host manages, what the new plan includes and who controls the domain and mail. This checklist follows a practical order: document the current setup, create recoverable backups, prepare a safe test copy, verify important functions, then schedule the DNS change and inspect the live site. Keep the old hosting active until the new version has been checked and you know how to revert if necessary. The exact steps differ by host, domain registrar, site complexity and email setup, so confirm responsibilities and timing before you begin.
Content
Set the scope
Build a migration inventory
Before comparing migration methods or requesting a transfer, write down what the site consists of and what must keep working. Record the website address, the WordPress installation’s location, the current host and hosting plan, and whether the site shares a server or account with other websites. Note the WordPress version, PHP version, database type and version if available, and any server-specific settings. You can usually find these details in the hosting control panel or ask the current provider. If a detail is unknown, mark it for confirmation rather than guessing.
List the site’s important components: active theme, essential plugins, custom code, connected services and any scheduled tasks, such as backups or regular imports. Identify functions that rely on the host, including a staging site, caching, security rules, server-side redirects or a web application firewall. Record what each dependency does and who manages it. This helps distinguish a straightforward WordPress move from one that may need configuration changes or input from a developer or service provider.
Map the domain and email arrangements separately. Record where the domain is registered, who controls its DNS, which nameservers are in use, and whether the website uses subdomains. Note where business email is hosted and identify the relevant DNS records, such as MX records and any mail authentication records. Website hosting and email can be provided by different companies; changing the website host does not necessarily require moving email. Keep a current copy of the DNS settings so they can be checked when planning the change.
List external connections and data that could be affected. These might include payment or booking services, customer databases, membership or shop functions, analytics, maps, forms, and links to third-party APIs. Note where credentials or configuration are held, who can update them, and whether a service restricts access by domain or server address. For sites that accept orders, bookings or submissions, establish how often information changes and who will check that recent data is present after the move. Avoid assuming that copying the site alone transfers information held by an external service.
Confirm access before work begins. Identify the people who can access the WordPress administrator, hosting account, domain registrar, DNS provider and any connected services. Check that the business—not only a former staff member or contractor—can reach the necessary accounts and complete any required identity checks. Do not put passwords in a shared planning document; use an appropriate password manager or secure access process, and grant only the access needed for the work.
Finally, assign responsibilities and record constraints. Name who approves the scope, who can authorise changes to hosting and DNS, who performs the technical work, and who tests the site’s business-critical functions. Note deadlines, busy trading periods, maintenance windows, privacy obligations and any required sign-off. A concise inventory gives the people involved a common view of what must be moved and protected, and reveals missing access or decisions before a migration method is chosen.
Secure a rollback
A rollback is only useful if you can restore a known-good version of the site and still have somewhere to run it. Before changing hosts, make separate copies of the WordPress files and database. Do not rely solely on a backup stored in the hosting account you are leaving: an account issue, deletion or failed transfer could make that copy unavailable when you need it. Store the backups somewhere access-controlled, and protect them because site files and database exports may contain passwords, personal information or other sensitive data.
Make backups you can actually restore
Include the complete site files, such as WordPress core, themes, plugins, uploads and configuration files, as well as a database export. Keep configuration files private, since they can contain database credentials. Record when each copy was made and where it is stored, and make sure the files are transferred completely. For an archive, check that it opens and that expected folders and files are present. For the database, check that the export is not empty and can be imported into a separate test database. These checks do not prove every feature will work, but they can reveal a damaged or incomplete backup before migration day.
Where practical, test a restore in a non-public environment rather than relying only on the backup process reporting success. Confirm that the restored site can connect to its database and that important content and media are present. Keep the original backup unchanged; if you need to troubleshoot, work from a copy. Limit access to the backup location and remove temporary copies securely when they are no longer required.
Agree the recovery point and keep the old host
Agree with everyone involved on the recovery point: the date and time of the backup you would restore if the migration has to be reversed. Record the time zone and who is responsible for taking, checking and retaining the final copies. If the site can receive edits, bookings, orders or form submissions, decide how to handle activity during the move. You might pause changes for an agreed period or arrange a final database backup immediately before the switch. Otherwise, restoring an earlier copy could lose newer information. For sites that continue taking transactions, get a clear plan for reconciling activity before attempting a rollback.
Keep the existing hosting account and site available while the new installation is being checked. Confirm the account will not expire, and avoid deleting files, databases or settings just because a copy has been made. The old site may be needed to compare content or restore service, but it can become out of date once the new site starts receiving changes. Agree which version is authoritative at each stage and who can make changes. If you do need to revert, consider new orders, submissions or edits first; simply switching back could send visitors to an older copy and create conflicting records.
Also allow for DNS changes to take time to be seen consistently across networks. Reverting DNS is not necessarily immediate, so retaining the old host is valuable breathing room, not a guarantee of instant recovery. Set a review point for deciding whether to proceed, pause or revert, and keep the backup locations and relevant hosting access details available to the people responsible. Clear recovery steps reduce rushed decisions if a problem appears during testing.
Prepare a staging copy
Prepare a staging copy
Before changing the live site, create a separate copy in a staging environment. This is a private test version hosted away from the public website, such as a staging tool provided by the new host or a temporary subdomain. Confirm where it will be hosted, who can access it and how it will be removed or updated after testing. Keep the live site available while you work on the copy.
Protect staging access. Use password protection or an IP restriction where available, and avoid sharing its URL publicly. A search engine visibility setting in WordPress can ask search engines not to index the copy, but it is not a security measure and does not prevent access. Use access controls as well, and check that staging cannot be indexed. If the copy contains personal or commercially sensitive information, limit access and consider whether you can test with a reduced or anonymised dataset instead.
Copy the site’s files and database using a method suitable for its size and setup. Then check that the staging configuration points to the staging database and location, not the live site. Review settings that may contain production URLs, credentials or external service details, including the WordPress configuration and any relevant plugin settings. Keep credentials private, and don’t publish them in notes or support requests.
Check the new host’s published requirements against the site before relying on the staging copy. Compare the PHP version and required PHP extensions with the needs of WordPress, the active theme and plugins. Check the database type and version against the site’s requirements, and confirm that the hosting environment provides suitable storage and any other required resources. If a required version or extension is unavailable, ask the host or a developer about the implications before proceeding; do not assume that a site will behave the same across different environments.
Load the staging site and look for errors before beginning detailed tests. Confirm that the address resolves to staging, pages do not redirect to the live domain, and media and styles load from the expected location. Check that WordPress can connect to the staging database and that key configuration values are correct. If you change the PHP version or other server settings during preparation, note what changed so you can identify the cause if something stops working.
Prevent the copy from sending real messages or carrying out live transactions. Forms, order notifications and password resets can reach real people if they remain connected to production services. Where possible, disable these actions or route them to a controlled test destination. For an online shop, do not place real orders or process live payments on staging; use a test mode only if the payment provider and site setup support it, and verify the arrangement before testing. Also take care with scheduled tasks, webhooks and integrations that could update live records.
Keep staging clearly separate from production throughout the work. Label it for staff, record any changes made during testing, and avoid treating it as the final site until you have completed the checks and agreed how the tested changes will be transferred. A staging copy can reveal configuration problems before launch, but it is not a substitute for a verified backup or a rollback plan.
Test the site
Test the site before launch
Treat the staging copy as a rehearsal, not just a quick visual check. Use a checklist of the pages and tasks that matter to customers, and test them on the new host before changing DNS. Where possible, view the staging site on a desktop and a mobile device; check that navigation, buttons, text and forms remain usable at different screen sizes. If the staging address is protected by a password or uses a temporary URL, make sure that setup is not masking problems customers could encounter on the live domain.
Start with the pages people rely on: the home page, main service or product pages, contact details, and any booking, checkout or enquiry pages. Follow internal links and use the site search, if there is one. Look for missing pages, incorrect links, layout shifts, error messages and content that has not transferred. Check a sample of older or high-traffic URLs as well as the main navigation, particularly if the site has many pages.
Test forms from beginning to end. Submit each important form with valid details, then check that the confirmation appears and that the submission reaches the expected inbox or system. Use test details and tell relevant staff before testing, so a trial enquiry is not mistaken for a real customer request. Also check required fields, error messages and any file-upload or consent options. A form that looks right but fails to deliver its submission is not ready for launch.
Sign in and out using the relevant account types, such as an administrator and a standard user. Check the pages and functions each role should be able to access, and confirm that password reset and other essential account steps work. For a shop, booking system or other live transaction process, use its supported test mode where available. Do not place a real order or create live bookings unless the business has agreed how to handle and reverse them.
Inspect images, documents, video and other media on key pages. Check that files load, links open the intended resource, and images are not stretched, missing or unexpectedly large on mobile. Review page titles, descriptions and headings alongside the visible content. In the site’s search visibility settings, confirm the staging copy is discouraged from indexing, then verify that the production site will not retain a staging-only noindex setting. Check canonical URLs, robots.txt and the XML sitemap where relevant; do not assume a setting is correct simply because it was correct on the old host.
Finally, test business-critical functions that may depend on services outside WordPress, such as payment, shipping, appointment availability, maps or customer records. Check any connection or error notices and confirm with the service provider or site administrator if a function depends on credentials, allow-listed addresses or other host-specific settings. Record each issue, its impact and who will resolve it. Fix launch blockers first; document minor cosmetic differences so they can be assessed without overlooking failures that could interrupt enquiries or transactions.
Repeat the key checks after the domain points to the new host. A successful staging test does not confirm that the live domain, secure connection or external integrations behave the same way. Keep the checklist available during launch and have someone responsible for checking the site on both desktop and mobile.
Plan the switch
Coordinate the DNS cutover
Choose a switch time when someone responsible for the website, hosting and domain settings can be available to make and check the change. For a small business, this may be outside its busiest trading period, but avoid a time when staff or support are unavailable. Agree who will update DNS, who will test the site and who can authorise a rollback. Before the change, confirm that the new copy is ready and that you have access to the domain’s DNS control panel. If DNS is managed by a separate provider, changing hosts does not automatically move DNS management there.
Identify the records that direct visitors to the website. Depending on the setup, these may include an A record pointing to an IP address, an AAAA record for IPv6, or a CNAME for a website hostname such as www. Confirm the correct values with the new host rather than guessing. Record the existing values before editing them, so they can be restored if necessary. Check whether the domain uses nameservers that control the entire DNS zone: changing nameservers can affect more than the website, including email and verification records.
Treat email records as a separate part of the plan. MX records direct incoming mail, while TXT records may support sender authentication, such as SPF and DKIM, or domain verification. Preserve the records required by the current email provider unless you are deliberately moving email too and have a separate migration plan. Hypothetical: If a business keeps email with a separate provider, its DNS plan should preserve that provider’s mail records while the website points to the new host. A mistake to an MX or authentication record can interrupt email even when the website itself loads correctly.
If your DNS provider allows it, lower the relevant website records’ TTL (time to live) in advance, following the provider’s guidance. A lower TTL can reduce how long some resolvers retain the old destination, but it does not make the change immediate everywhere. Allow for DNS caches and check the site from more than one network or using DNS-checking tools. Keep the previous hosting account active during the agreed checking period; switching DNS does not erase the old site, and retaining it provides a practical fallback.
At the scheduled time, update only the records included in the plan. Then check that the domain and www version resolve to the intended destination and load over HTTPS without certificate warnings. Test important pages, forms, logins and other business-critical functions, and confirm that email can still be sent and received. Review the new host’s error logs or monitoring tools if available, and watch for broken links, missing images, server errors or unexpected changes in site content. Record what was changed and when, so the team can distinguish migration issues from unrelated problems.
Decide in advance what would trigger a rollback, such as persistent access errors or a critical function failing, and who makes that decision. If needed, restore the recorded website DNS values to point to the old host, then allow for caches to update. Rollback is not always a simple undo: visitors may reach either host during the transition, and changes made on the new site after cutover—such as orders, bookings or new form entries—may not exist on the old copy. For sites that accept transactions or frequent updates, agree how to pause activity or reconcile changes before launch. Keep the old host available until the new site and related services have been checked and the migration is accepted.
Conclusion: verify and monitor
Conclusion: verify and monitor
Before calling the migration complete, check the live domain over HTTPS and test the pages and functions customers rely on: navigation, forms, logins and, where relevant, bookings or checkout. Confirm images load, important URLs resolve or redirect appropriately, and the site is not accidentally set to discourage search engines from indexing it. If email uses the same DNS zone, verify that sending and receiving still work.
Keep the old hosting available while you monitor the new site. In the first few days, revisit key pages on desktop and mobile, submit a test form, check for browser or server errors, and review any available uptime, error or search-console reports. Look for broken links, missing content, unexpected redirects, slow or failed transactions, and messages that do not arrive. Record issues and when they occur so they can be traced.
Get specialist help if the site shows recurring database or server errors, important data is missing, a business-critical function fails, or you are unsure which DNS records must remain unchanged. A developer or hosting specialist can investigate the setup and advise on recovery before a small fault disrupts customers further.
Explore related information: Booking Website Design & Development; Web Design Sunshine Coast.
