How to Migrate WordPress Without Downtime

A WordPress migration does not need to begin with downtime.

The safest approach is to leave the current website serving visitors while you prepare and test a separate copy on the new host. DNS changes only after the new copy is ready.

This workflow reduces risk because the old host remains a working fallback throughout most of the project.

1. Inventory the current website

Do not start by copying files. Start by understanding what must move.

Record:

• The primary domain and any aliases
• WordPress and PHP versions
• Active theme and plugins
• Database size
• Uploads directory size
• Custom cron jobs
• External DNS records
• Email accounts and forwarding rules
• Payment, form, analytics, and SMTP integrations

Pay special attention to services that use an IP allowlist, absolute file path, license restriction, or callback URL. They may need an update after the move.

For WooCommerce or membership sites, identify when the database changes. Orders, accounts, comments, bookings, and form submissions created during migration must not be lost.

2. Create a complete backup

Take a fresh backup before making changes.

A complete WordPress backup includes:

• The database
• The wp-content directory
• WordPress configuration
• Server-specific rules such as .htaccess
• Any files stored outside the standard WordPress directories

Download or store the backup somewhere independent from the current hosting account. A backup that exists only on the server being changed is a weak fallback.

Confirm that the archive opens and that the database export contains tables. “Backup completed” is useful only when the result is restorable.

3. Prepare the destination

Create the hosting package before changing DNS.

Match the important runtime settings first:

• Use a PHP version supported by the site
• Create the database and credentials
• Check upload and memory limits
• Enable SSL or prepare certificate issuance
• Configure required PHP extensions
• Add scheduled jobs if the application depends on them

Do not use this moment to upgrade WordPress, replace plugins, change the theme, and migrate the host simultaneously. Each additional change makes troubleshooting harder. Move the known site first; improve it after the migration is stable.

4. Copy files and database

Migration tools can automate this step, but the underlying process is straightforward:

1. Copy WordPress files to the new hosting space.
2. Import the database.
3. Update database credentials in wp-config.php.
4. Replace URLs only if the test environment requires a temporary domain.
5. Preserve serialized WordPress data by using a WordPress-aware search-and-replace tool.

Avoid a raw text replacement inside the SQL file. WordPress stores serialized values whose length metadata can break when URLs change incorrectly.

5. Test without public DNS

The new copy needs a private test path.

Depending on the host, use a temporary URL, preview domain, local hosts-file entry, or staging feature. The goal is to load the new server while the public domain still points to the old one.

Test more than the home page:

• Login and logout
• Main navigation
• Forms and email delivery
• Search
• Images and downloadable files
• Mobile layouts
• Checkout and payment sandbox flows
• Account pages
• Redirects and custom post types
• Admin actions and scheduled tasks

Open the browser console and network panel to catch mixed content, missing scripts, blocked fonts, and requests still pointing to the old location.

6. Plan the final database sync

Static company sites can often use the first copied database at launch. Dynamic sites need a final sync.

For WooCommerce, bookings, forums, memberships, or active forms, choose one of these approaches:

• Put the old site in brief maintenance mode while exporting the final database.
• Sync only the tables that changed, if you understand the application data model.
• Use a migration service designed to capture changes during the move.

The maintenance window can be short because files and the initial database are already at the destination. Communicate the window to the people who manage orders or content.

7. Lower DNS TTL in advance

DNS time to live, or TTL, tells resolvers how long to cache a record.

Lower the relevant TTL before launch—ideally at least one previous TTL period in advance. This can help visitors receive the new address sooner after the change.

Do not delete unrelated DNS records. A website migration often needs only an update to the root and www records. MX, SPF, DKIM, verification, and service records may support email or other systems.

Export the current DNS zone before editing it.

8. Switch traffic and watch both servers

After the final data sync:

1. Point the website records to the new host.
2. Confirm public DNS from more than one network or resolver.
3. Verify the SSL certificate.
4. Retest critical pages on the public domain.
5. Check forms, payment notifications, and outgoing email.
6. Monitor error logs and uptime.

Some visitors may reach the old server while DNS caches expire. Keep the old website online and avoid making independent content changes there.

For a dynamic site, you can place a clear maintenance message or redirect on the old server once the new site is receiving traffic.

9. Keep a rollback path

Do not cancel the old hosting immediately.

Keep it available for several days while you monitor:

• Application errors
• Missing media
• Email delivery
• Payment webhooks
• Scheduled tasks
• Search-engine crawling
• Traffic and conversion changes

If a serious problem appears, DNS can point back to the previous host while you investigate. Record any new transactions before rollback so they can be reconciled.

10. Finish the migration

Once the new host is stable:

• Raise TTL to the normal value
• Remove temporary URLs and migration accounts
• Confirm automatic backups
• Run a malware scan
• Update documentation and credentials
• Cancel the old hosting only after its data is no longer needed

A no-downtime migration is not one clever switch. It is a sequence that keeps the working site available until the replacement has earned your confidence.

Ask VeyoHost to plan your migration or review the hosting plans.

A better hosting decision starts with a clear question.

Tell us what you are running. We’ll help you choose the practical next step.

View plans