Migrating a WordPress site from another host (step-by-step)

Moving a WordPress site from another host to Omega Digital is routine, but moving one without downtime takes discipline. This article covers the process we recommend: build the new site on a staging hostname, verify, then cut over via DNS.

The strategy at a glance

01. Lower DNS TTL at the current host
02. Export files and database from the source
03. Import into Omega Digital under a staging hostname
04. Fix URLs via search-replace
05. Verify the staging site
06. Switch DNS to Omega Digital
07. Monitor for 48 hours and decommission the old host

Step 1: Lower TTL (day 0, 24 hours before cutover)

At the current DNS host, set the A record TTL to 300 seconds. This means worldwide caches will refresh within 5 minutes once you change the record, instead of hours.

Step 2: Export from the source

If you have shell access on the old host, this is the cleanest path:

bash

# On the old host
ssh [email protected]
cd public_html

# Database export
wp db export /tmp/site-db.sql --add-drop-table

# Files tarball (exclude caches)
tar --exclude='wp-content/cache' \
    --exclude='wp-content/uploads/cache' \
    -czf /tmp/site-files.tar.gz \
    wp-config.php .htaccess wp-content/ index.php wp-admin wp-includes *.php

No shell access? Use the Duplicator or All-in-One WP Migration plugin on the old host to produce a single archive, then download it.

Step 3: Upload and extract on Omega Digital

bash

# Pull files into the new account (from your workstation, or scp between hosts)
scp site-files.tar.gz [email protected]:/home/cpuser/
scp site-db.sql [email protected]:/home/cpuser/

# SSH in
ssh [email protected]
cd public_html

# Empty the directory first (if anything is there)
rm -rf ./* ./.htaccess

# Extract
tar -xzf /home/cpuser/site-files.tar.gz -C .

# Fix permissions
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Step 4: Create a fresh database and import

01. In cPanel, create database cpuser_wpsite, user cpuser_wpuser, strong password.
02. Assign user to database with All Privileges.
03. Edit wp-config.php with the new credentials and our DB_HOST=localhost.

bash

# Import the database dump
wp db import /home/cpuser/site-db.sql

# If the dump uses a different table prefix than wp-config expects, fix it first:
# sed -i 's/\`oldprefix_/\`newprefix_/g' /home/cpuser/site-db.sql

Step 5: Stage under a temporary hostname

Add the domain to your Omega Digital account, and also create an addon or temporary subdomain like staging.yourdomain.com pointed at the same document root. Or use the preview URL cPanel provides (e.g. cpuser.your-server.omdigital.cc).

bash

# Rewrite URLs in the database from live to staging
wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --dry-run
wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com'

# Flush caches so changes take effect
wp cache flush
wp rewrite flush

Step 6: Verify the staging site

Walk through the checklist below. Do not proceed to DNS cutover until every item passes:

· Homepage renders correctly
· A recent post has the right content and images
· You can log into wp-admin
· Media library images load (not 404)
· Contact form submits and arrives
· No mixed-content warnings in browser console
· Page loads under 2 seconds from a private browser window

Step 7: DNS cutover

On the new site, run search-replace back to the real domain:

bash

wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com'
wp cache flush
wp rewrite flush

Now change DNS. Either switch nameservers to Omega Digital, or (if you're keeping DNS elsewhere) change the A record to the new server IP. Because you lowered TTL to 300 yesterday, propagation completes within 5–10 minutes.

Step 8: Verify the cutover

bash

# Confirm DNS has switched
dig +short A yourdomain.com
# Expected: the Omega Digital server IP

# Confirm the new server is actually serving your domain
curl -sI https://yourdomain.com/ | grep -i server
# Expected: Server: LiteSpeed

# Issue SSL
# cPanel → SSL/TLS Status → Run AutoSSL

Step 9: Post-cutover

· Raise TTL back to 3600 once you're confident the cutover held
· Keep the old host live for 48 hours as a safety net, then cancel
· Set up backups on the new account
· Watch Google Search Console for crawl errors over the next week

The 'still serving old site' bug

After cutover, your browser may still show the old site for a while. Nine times out of ten, this is local DNS cache. Check from a neutral vantage before panicking:

bash

dig @1.1.1.1 +short A yourdomain.com
dig @8.8.8.8 +short A yourdomain.com

# Flush your local cache
sudo dscacheutil -flushcache                     # macOS
sudo systemd-resolve --flush-caches              # Linux
ipconfig /flushdns                               # Windows

Common gotchas

· Forgetting to search-replace URLs. Site loads, admin is broken, images 404.
· Table prefix mismatch. Old site used wp_ and the dump has wp_ tables, but you set $table_prefix = 'wp9x_'. Edit one or the other to match.
· Skipping TTL lowering. Cutover takes 12+ hours to propagate instead of minutes.
· Not migrating wp-config salts. Logged-in users lose sessions; usually not a problem, but it startles admins.
· Source site had hardcoded absolute paths in theme files. Grep for old server paths after the migration.

Still stuck?

Email [email protected]. We offer free migration assistance on every plan. Include the source host name and a reasonable window.