How to Migrate a WordPress Site to a New Host Safely (2026)

A hosting move can look finished while the most important part of the site is quietly broken. The homepage loads, but order emails don’t arrive. Payments succeed, but WooCommerce never receives the confirmation. Or customers place orders on two different servers.

The safest approach is to copy first, test privately, briefly pause transactions, and then switch traffic. This guide covers moving WordPress to a new host in 2026 without changing your domain name, with extra precautions for WooCommerce stores and restaurant ordering sites.

Choose Your Migration Method and Prepare the New Host

Changing hosts means moving your site’s files and database to another server. Transferring a domain means moving its registration between registrars. Changing a domain name means changing the website address itself, which adds URL replacement, redirects, and SEO considerations.

These are separate jobs. You don’t need to transfer your domain registration to change hosting. For a straightforward move, keep the same address and registrar, then update the DNS records that direct web traffic.

Pick a method that matches your site

Host-assisted migration is usually the easiest route for beginners, especially with a busy store. Ask what the service includes: an initial copy, private testing, a final data sync, DNS changes, and post-launch checks aren’t necessarily part of the same package.

A migration plugin packages or transfers the database and files through a guided interface. That’s convenient for smaller sites, but upload limits, execution timeouts, available storage, and paid-feature restrictions can affect the process. Check the tool’s current documentation before relying on it.

Manual migration involves copying files, exporting and importing the database, and configuring WordPress at the destination. It offers control but requires confidence with database tools, file permissions, and server configuration. Your first attempt shouldn’t be during Friday dinner service.

Check the destination before copying anything

• Confirm the host meets the current WordPress hosting requirements and WooCommerce server recommendations, including supported PHP and database versions.
• Check required PHP extensions, memory, execution limits, storage, and inode allowances. Leave room for the site, an archive, extracted files, and backups.
• Confirm SSL certificate provisioning, scheduled-task support, staging or preview access, and an independent backup arrangement.
• Gather hosting, SFTP or SSH, database, WordPress administrator, registrar, and DNS credentials. Include access to two-factor authentication.

Compare PHP versions with the old host and check theme and plugin compatibility. Avoid combining migration day with a major WooCommerce, theme, or PHP upgrade unless compatibility makes it unavoidable.

Back Up Your Website and Record Essential Settings

A complete backup contains both the database and the files. A WordPress content export alone isn’t enough: it doesn’t capture your full configuration, plugin data, uploads, or server setup.

Back up the entire WordPress directory, including uploads, themes, plugins, must-use plugins, hidden configuration files such as .htaccess, and wp-config.php. Export every database table belonging to the installation, including custom plugin tables. WooCommerce stores using High-Performance Order Storage need their order tables included—not just posts and post metadata.

Download a copy somewhere outside both hosting accounts. Backups can contain customer addresses, password hashes, and integration credentials, so use encrypted storage with restricted access. Don’t leave a downloadable database archive in a public website folder.

Prove that the backup works

The strongest check is a restore into a private test environment. Confirm that extraction and database import complete, administrator login works, and expected pages, media, and recent orders are present. Merely seeing a ZIP file with a plausible size doesn’t prove recoverability.

Record when the backup was taken and which files and tables it includes. For stores, note several recent order IDs, their timestamps and statuses, plus stock quantities for a few active products. These become useful comparison points during cutover.

Make a small migration notebook

Export or screenshot the DNS zone, including A, AAAA, CNAME, MX, TXT, and relevant SRV records. Record nameservers, email routing, SPF, DKIM, DMARC, verification records, subdomains, and any CDN or proxy settings. If mailboxes live on the old host, their contents need a separate migration plan.

Also document redirects, server-level scheduled tasks, SMTP settings, payment webhooks, API connections, firewall rules, and IP allowlists. Host-level configuration usually won’t travel inside a WordPress backup.

For restaurants using FoodMaster’s WooCommerce restaurant ordering system, verify ordering hours, delivery zones, pickup options, QR table links, and connected kitchen displays and printers. Record SMS and POS connections too, where used.

A same-domain move often preserves URL-based connections, but changed IP addresses, server-local agents, authentication tokens, or provider security checks can require updates or reauthorization. Make sure someone with access to those accounts is available during launch.

Copy WordPress to the New Host Without Changing Live Traffic

Keep the original site serving customers while you build the destination. At this stage, you’re creating a rehearsal copy—not another live store.

Before importing, arrange protection at the destination. Password protection or an IP restriction can keep visitors out, but it won’t stop background processes from sending emails or calling external services. Ask the host to help isolate the copy if you aren’t comfortable managing those controls.

Follow a controlled plugin workflow

1. Check that your migration tool supports the current WordPress version, PHP environment, site size, and installation type. Multisite and unusually large databases may need a different process.
2. Create the destination site and database as required by the tool. Some tools need an empty WordPress installation; others use a standalone installer.
3. Generate a fresh migration package or initiate a direct transfer. Exclude disposable caches and redundant backup archives only when you know they’re unnecessary.
4. Import the database and files, then review the migration log for skipped tables, missing files, timeouts, and permission errors.
5. Check destination database credentials and host-specific configuration. Remove public installer files and migration archives once they’re no longer needed.

For a large media library or active store, host-assisted copying through SSH can avoid browser upload limits. Agree on how the final synchronization will work before accepting an initial transfer as “migration complete.”

Preview the original address on the new server

A hosts-file override maps your domain to the new IP address on your own computer. Everyone else still reaches the existing site through public DNS. Add mappings for the hostname you use, including the www version if needed, and remove them after testing.

The destination must be configured to serve that domain and present a valid SSL certificate. Ask about advance certificate provisioning, potentially using DNS validation. Clicking past certificate warnings doesn’t test a working HTTPS checkout.

A host-provided preview can also help, though temporary URLs may behave differently with redirects, cookies, payment integrations, and absolute links. Because the public address isn’t changing, a production-wide URL replacement normally isn’t required. Never run a blind SQL replacement across serialized WordPress data.

[IMAGE: Migration diagram showing public visitors reaching the old host while an administrator uses a hosts-file override to test the same domain on a private new server]

Keep the rehearsal from doing real work

Suppress outgoing customer email, disable automatic printing and SMS, and prevent live payment actions. Pause server cron and check for WooCommerce Action Scheduler workers or other background runners; disabling WP-Cron alone may not stop every job.

Use test-mode integrations only where appropriate, and remember that a later database import can overwrite those settings. Prefer destination-level safeguards that survive an import. Search-engine discouragement isn’t access control, and your computer’s hosts-file override doesn’t redirect external payment callbacks to the test server.

Protect New WooCommerce Orders During the Final Transfer

Your initial copy becomes outdated as soon as someone changes the live site. A customer places an order, a payment changes status, a manager issues a refund, or a stock connector updates availability. None of that automatically appears at the destination.

Suppose you copy a pizzeria’s database in the morning and switch hosts after lunch. Every order accepted in between remains on the old database unless you synchronize it. Copying only newly uploaded images won’t fix that.

Plan a short, explicit maintenance window

For beginners, a controlled pause is safer than assuming zero downtime. Choose a quiet period and tell staff when to stop dashboard edits, refunds, stock adjustments, and order processing. If possible, let in-flight checkouts and pending payment confirmations settle first.

Pause checkout and other database-changing activity on the old site. A maintenance page may block shoppers while leaving REST API clients, webhooks, subscriptions, and scheduled jobs active. Your plan must account for those writers too.

Coordinate external systems: pause connectors where supported and understand payment providers’ callback retry behavior. Record outstanding payments that may need reconciliation. Avoid acknowledging a payment callback as successfully processed if its update hasn’t actually been saved.

1. Confirm the source is no longer accepting new transactions or uncontrolled writes.
2. Take a final database-and-files backup and record the cutover time.
3. Import the latest complete database at the destination and synchronize changed files, including new uploads and deletions where relevant.
4. Recheck destination-specific configuration and ensure the import hasn’t reenabled test-copy emails, integrations, or background workers.
5. Compare recent orders, payment statuses, stock, customer records, and scheduled actions against the frozen source.

Do not try to merge two independently active WooCommerce databases by copying a few order tables. Orders connect to items, metadata, stock, customers, payment references, and scheduled work. That quickly becomes a specialist reconciliation task.

Only one server should accept new transactions. Keep the old site’s checkout disabled after the DNS change because some visitors will still reach it through cached DNS. Open the new site only after the final verification and routing change, and run production background workers only there.

For a tighter cutover, an experienced host can arrange for the old server to proxy requests to the new one. That needs deliberate configuration; an ordinary redirect to the same domain won’t solve stale DNS routing.

Switch DNS and Check the Live Website

DNS tells browsers and other clients where your domain lives. Its TTL, or time to live, tells resolvers how long they may cache an answer. A TTL of 300 seconds means five minutes, but lowering it doesn’t erase an answer already cached under the previous value.

Reduce the relevant records’ TTL ahead of the move, allowing at least the previous TTL to pass. Even then, don’t treat the switch as instantaneous: local caches, persistent connections, and different network paths can produce a mixed period.

Change web routing, not the entire DNS zone

Typically, you’ll update the root domain’s A record for IPv4 and its AAAA record if IPv6 is used. Check www separately: it may be a CNAME pointing to the root or have its own address records. A stale AAAA record can send some visitors to the old host even after the A record changes.

With a CDN or reverse proxy, the public records may stay unchanged while you update its origin configuration. Follow the actual traffic path rather than changing records by habit.

Leave MX and email-related TXT records intact unless email routing is intentionally changing. If nameservers must change, recreate the full zone first and coordinate DNSSEC settings where enabled. An incorrect DNSSEC transition can make the domain fail to resolve.

After updating DNS, remove your hosts-file override. Check resolution from more than one network and use hosting logs or a temporary harmless identifier to confirm which server handles requests.

[IMAGE: Restaurant migration launch checklist showing DNS and SSL checks alongside a mobile checkout, payment confirmation, kitchen ticket, and transactional email]

Test the customer journey from start to finish

• SSL and navigation: Check the certificate, HTTP-to-HTTPS behavior, preferred hostname, redirects, menu pages, images, and account login.
• Mobile ordering: Test product options, cart updates, delivery-address validation, pickup slots, coupons, taxes, and checkout on a phone.
• One controlled live order: Once production is intentionally enabled, use an authorized low-value purchase to confirm payment and order handling. Account for processing fees and any refund policy.
• Payment callbacks: Verify gateway confirmation reaches the destination and the order status updates correctly. A browser’s thank-you page alone isn’t proof.
• Messages and fulfillment: Confirm customer and staff emails, SMS where used, kitchen tickets, and printer output—without duplicates.
• Background work: Reenable the intended scheduler and review pending or failed actions before allowing an accumulated queue to run unchecked.
• Caching and integrations: Exclude cart, checkout, account, and personalized responses from full-page caching. Verify session handling, webhook access, API connections, and IP restrictions.

Purge destination and CDN caches after configuration changes. Shared cache infrastructure should use appropriate site-specific namespaces so the two installations don’t interfere with each other.

Restore normal DNS TTLs once the site is stable. Also confirm outbound server IP changes haven’t broken SMTP authorization or a printer, POS, inventory, or accounting connection.

Troubleshoot Problems and Retire the Old Host Safely

Start with the symptom, then inspect the smallest relevant layer. Repeatedly restoring the whole site can hide the cause—and overwrite useful evidence.

Database errors and broken page links

For “Error establishing a database connection,” check the database name, username, password, and hostname in wp-config.php. Confirm the database was imported and the user has permission to access it.

If the homepage loads but inner pages return 404 errors, save the permalink settings to refresh WordPress rewrite rules. Then check Apache rewrite configuration or the equivalent Nginx rules with your host; Nginx doesn’t read .htaccess.

Missing images and HTTPS loops

Missing images often mean incomplete upload transfers, incorrect permissions, filename case differences, or stale CDN paths. Inspect a failing image’s actual URL and response before assuming the media database is damaged.

For SSL redirect loops, check WordPress URL settings, web-server redirects, and proxy HTTPS detection. Conflicting redirect layers or incorrect forwarded-protocol handling can bounce requests indefinitely. Disabling HTTPS isn’t the fix.

Keep the old account until dependencies are cleared

Monitor payment failures, checkout errors, email delivery, scheduled actions, stock changes, server resources, and old-server traffic. Observe a representative busy service period, not just five quiet minutes after launch.

Keep old hosting for several days at minimum—and longer if mail, integrations, or DNS dependencies remain unresolved. Cancel only after the new site has a verified backup, traffic has moved, and nothing still depends on the old account. Check that cancellation won’t also terminate domain or email services.

Once the new store accepts orders, rollback requires another controlled pause and preservation of those new transactions. Restoring yesterday’s database would lose today’s orders. Reconcile payments, stock, and fulfillment before reopening anywhere.

A safe migration ends when customers can order, staff can fulfill, and you can recover the new installation. The homepage loading is just the first check.