The new homepage opens. That is encouraging—but it does not prove the move preserved your enquiries, customer orders, email or search URLs.
A WordPress website migration should solve a defined hosting problem while keeping the business operational. Treat it as a controlled release: prepare, test, reconcile data, switch traffic and verify. The important question is not “Have the files moved?” but “Can customers and staff still complete the tasks that matter?”
This guide covers moving hosting while keeping the same domain and page URLs. A new domain, changed URL structure or switch to another ecommerce platform needs a separate redirect and migration plan. No process can guarantee zero downtime or unchanged rankings.
Your migration checklist at a glance
| Stage | What must be established | Reason to pause |
|---|---|---|
| Before preparation | Access, account ownership, backups and the move’s scope | Nobody can recover the site or administer a critical provider |
| Before cutover | Working staging site, email plan, URL checks and data synchronisation | Forms, checkout, login or restore checks fail |
| During the switch | Named decision-maker, final data snapshot and rollback rules | New orders or enquiries could be overwritten |
| After the switch | Correct production, received messages, order records and monitored traffic | A critical task is broken or records disagree |
Download the WordPress migration acceptance checklist to record the owner, evidence and result for each stage. It is a working checklist, not a promise that every move has the same risks.
First confirm that hosting is the problem
A slow WordPress site may have heavy media, a theme bottleneck, plugin conflicts or expensive database queries. Changing the server without diagnosing the defect can reproduce it elsewhere.
Write down the reason for the move: capacity, unreliable service, renewal cost, unsupported software, operating access or a confirmed infrastructure issue. Use the public website audit for initial technical signals, then request deeper evidence where necessary.
For WordPress website migration in Saudi Arabia, the operating essentials are the same: identify the business’s hosting and email requirements, supported provider accounts and the time window the team can approve. Remote delivery does not remove the need for a client-side decision-maker.
Establish access before scheduling the move
Confirm access to the registrar, DNS, old and new hosting, WordPress administration, files, database and backup location. Record email, payment, shipping, analytics and other external services separately.
The domain does not always need to move between registrars when hosting changes. DNS changes and registration transfers are different tasks. If another provider owns the account, settle permission and recovery access before the launch date.
Use named provider roles where possible. Do not send customer databases or shared passwords in an ordinary project brief. The ownership and handover guide explains the operational information the business should retain.
Back up everything—and prove that it can be restored
Include the files, database, uploads and relevant configuration. Email mailboxes and external services are not necessarily included in a WordPress backup.
Record the snapshot time and a restore procedure. Have the technical provider verify the restored copy in an isolated environment. A “backup completed” notification does not prove the archive is complete or usable.
For an active store, identify orders, customers, stock changes and messages that arrive after the backup. Those records need a cutover strategy; restoring yesterday’s database can lose today’s business.
Prepare and test the new environment
Check the destination’s compatibility with the site’s current WordPress, PHP, database, extensions and operating requirements. Avoid combining a host move with unplanned major software upgrades.
Use a protected staging environment or an appropriate local hostname mapping to test before public DNS changes. Keep staging unavailable for public indexing and prevent unintended mail, payment or fulfilment actions. Do not rewrite production URLs to a temporary address merely to make a test copy load.
The WordPress migration handbook provides the technical reference. Database replacements require care; serialized data and plugin-specific records are reasons to use a suitable migration method rather than blind text replacement.
Keep your existing URLs and search access
Prepare a list of important service, product, category and article URLs. Check status codes, content, images, canonical URLs and internal links on the destination.
For a hosting-only move, retain the existing URLs and avoid unnecessary changes to page content or structure. Ensure production remains crawlable, retains verification requirements and does not inherit staging restrictions. Google’s hosting-move guidance also describes DNS preparation and monitoring old and new infrastructure.
If a URL must change, document its destination and appropriate redirect before launch. Do not send every missing product or article to the homepage. Keep search visibility checks separate from operational tests; a crawlable site can still have a broken contact form.
Plan email independently of the website
Establish where business mailboxes are hosted, whether they need transferring, and which DNS records must remain. Changing nameservers can affect mail even when the website migration succeeds.
Record the relevant MX, SPF, DKIM and DMARC configuration and have the responsible provider check it. Confirm form delivery and transactional messages separately from ordinary inbox access.
Test a received enquiry and incoming/outgoing business mail. A form success screen does not prove delivery. If an external email provider remains unchanged, preserve the required records rather than creating replacement mailboxes without a reason.
A Raphia lesson: a store needs more than a homepage test
Raphia’s coffee store connects coffee discovery, grind and weight selection, accounts and bilingual shopping. Those features show what a migration acceptance plan for this kind of store must cover.
Test a product choice in both languages, confirm the selected options and total persist in the basket, and verify a controlled order reaches administration with the right information. Check order messages and the agreed stock workflow.
This is a recommended test plan based on the delivered functionality—not a claim that I performed a particular Raphia migration or measured its downtime.
Agree a data cutover and rollback decision
Before changing DNS, agree when content changes stop, how new orders or enquiries are reconciled, and which environment is authoritative. DNS propagation means requests may reach different servers during the transition.
Your technical provider should document the applicable maintenance window, final synchronisation and handling of any overlapping writes. Keep old hosting available for the agreed recovery period. Do not leave both copies accepting business data without coordination.
Write the rollback rule before the switch: who decides, what constitutes a critical failure, how traffic returns and how data collected on the new environment is preserved. Restoring an old database blindly can lose records; recovery includes data reconciliation, not only changing DNS back.
Verify production before retiring the old hosting
- Check priority URLs from more than one network and confirm the intended environment.
- Test HTTPS, mobile navigation, login, forms and important downloads.
- Verify a controlled enquiry, and the relevant order and payment workflow for a store.
- Review error logs, missing assets, redirects and Googlebot access.
- Recheck mail, backups, monitoring and account access.
- Observe remaining traffic on the old environment before shutting it down.
Continue monitoring after the first successful test. Timing depends on DNS behaviour, the site’s workflow and the recovery agreement—not a universal fixed number of hours.
Frequently asked questions
Will changing hosting damage my SEO?
It can create risks if URLs, access, content or performance change incorrectly. Preserve important URLs and monitor the move, but do not promise unchanged rankings.
Does a WordPress backup include my business email?
Not necessarily. Identify the mailbox provider and backup or transfer requirements separately, then test delivery after the DNS change.
Can a store keep taking orders during migration?
Sometimes, with an appropriate synchronisation plan. Otherwise an agreed pause may be safer. Decide how to preserve orders arriving after the snapshot before the move begins.
Can I cancel the old hosting immediately?
Not safely merely because the new homepage loads. Keep it for the agreed recovery period and verify traffic, data and operational tasks before retiring it.
Share the move’s scope before choosing a date
Send the current URL, reason for moving, CMS, hosting and email providers, whether the site takes orders, and the preferred time window. Do not include passwords or customer records.
I can review the requirement and scope hosting and server setup or WordPress work for Saudi businesses. If the problem can be repaired without moving, that should be considered first.
