A successful migration means more than displaying the homepage on new hosting. Preserve content, recent data, domain-related services and important journeys. Define what changes, what must keep working and how you would return to a controlled state.
This guide covers WordPress and separates infrastructure moves, URL changes and email. It does not promise zero interruption or guaranteed preservation of rankings.
1. Define the scope first
- Hosting only: domain and paths stay the same; the server changes.
- Address changes: domain, protocol or paths change; prepare a URL mapping.
- Redesign or platform change: content and functions may change too; separate stages where practical.
- Email: state explicitly whether it stays where it is or whether accounts and messages must move.
For a move without URL changes, do not add redirects merely because hosting changes. Verify the new infrastructure and site behavior first. Google’s hosting-move guidance.
2. Inventory the site and prepare recovery
Account for content, media, downloads, configuration, scheduled jobs and external services. Record important pages, linked URLs, landing pages and commercial actions. Check access to the domain, hosting and search-engine reports.
Prepare a recoverable backup and a copy of DNS settings. Define who authorizes cutover and which problems would trigger a return. Changing DNS back does not merge orders created on two servers; plan data ownership and reconciliation too.
3. Prepare an isolated destination copy
Set up the required software versions and resources. Protect the preparation environment and prevent unintended indexing. Disable outgoing messages, payments and other external effects; do not use real transactions for a routine test.
Transfer files and database with a WordPress-aware method. Where addresses occur inside serialized data, a raw text replacement can damage it. Use a method that handles that format correctly. Moving to a different address may require a migration procedure beyond restoring a backup. WordPress migration documentation.
4. Test before cutover
- Open representative page types, images and downloads.
- Check navigation, search, administration and required permissions.
- Test form submission and message receipt with a controlled test recipient.
- For a shop, test cart and checkout using the payment solution’s test mode.
- Check integrations, scheduled tasks and useful-event measurement.
- Prepare the final domain’s certificate and HTTPS behavior with the host.
Record the expected result for each check. A working homepage does not establish that product pages, downloads and forms are working.
5. Map URLs when addresses change
Create a line for every important old URL, its destination and treatment. Choose a genuinely equivalent page. For removed content without a suitable replacement, use an appropriate response rather than redirecting everything to the homepage.
For URL changes, use suitable permanent redirects, update internal links, canonicals and sitemaps, then monitor old and new addresses. Google recommends keeping redirects for at least a year; temporary ranking fluctuations remain possible. Google’s URL-move guide.
Fictional mapping: /old-service/ → /services/service/ when the service genuinely corresponds. Shops need more detailed review of categories, products, variants and meaningful parameters.
6. Protect recent writes and email
Data can arrive between the first copy and cutover: orders, bookings, accounts, comments and form records. Define a temporary write freeze or a controlled synchronization method. Perform the final copy under that plan and avoid operating two independent sources of truth.
For email, record routing and authentication. If mailboxes move, prepare accounts and message transfer separately. Keep old access until results are confirmed; a DNS change does not copy email archives.
7. Run a controlled cutover
- Confirm tests and the final recovery copy.
- Apply the plan for recent writes.
- Change only the prepared DNS destinations or delegation, considering TTL and DNSSEC.
- Remove preparation restrictions that should not apply to public pages, while retaining appropriate restrictions elsewhere.
- Enable the planned URL rules and services without executing the same production jobs from two copies.
- Verify the final site, messages and commercial functions.
Do not cancel the old service as soon as your browser displays the new homepage. Retain an appropriate verification period for the project and caches, with clear ownership of recent data.
8. Check the following days
Review page responses, redirects, links, media, errors and forms. Check analytics collection too: a collection change can look like a traffic decline. Monitor indexing and important pages in Search Console and Bing Webmaster Tools.
Use supported change-of-address tools only when applicable to the type of move; they are not required for every hosting change. Keep a dated log of issues and corrections instead of changing several settings without a record.
Tools mentioned in the original article
Search Console supports Google-specific monitoring; Screaming Frog SEO Spider inspects URLs and links; Moz Pro provides monitoring context. Redirect Path helps inspect a redirect journey but does not itself configure server rules. Redirect functions in Yoast SEO depend on the product used.
PageSpeed Insights, GTmetrix and Pingdom supply performance observations. WordPress, Shopify and Magento remain the platforms named in the earlier selection; a platform name does not guarantee migration success. This workflow covers WordPress. Changing platforms also requires a data and functionality plan.
Checklist and frequently asked questions
- Scope, owner and return criteria defined.
- Recoverable copy and DNS configuration retained.
- Important destination journeys tested.
- URL rules prepared where addresses change.
- Recent data and mail handled explicitly.
- Post-cutover checks completed and issues recorded.
Must URLs change when I change hosting?
No. Keep them when your project does not require a change.
Can I change everything at once?
Separating hosting, domain, structure and design where practical makes unexpected behavior easier to investigate.
For an iMasterWeb migration, describe the site and intended scope. Do not send passwords through the form.