Test the destination before directing visitors to it. Keep the source hosting active during the transfer and plan how to copy any data that changes before the DNS switch.
Migration steps
- Lower DNS TTL at the current host
- Export files and database from the source
- Import into Omega Digital under a staging hostname
- Fix URLs via search-replace
- Verify the staging site
- Switch DNS to Omega Digital
- 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, export the database and archive the files:
# 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 *.phpNo 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
# 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.phpStep 4: Create a fresh database and import
- In cPanel, create database cpuser_wpsite, user cpuser_wpuser, strong password.
- Assign user to database with All Privileges.
- Edit wp-config.php with the new credentials and the database host supplied for the service.
# 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.sqlStep 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).
# 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 flushStep 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 destination site, replace the staging hostname with the public domain:
wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com'
wp cache flush
wp rewrite flushNow change DNS. Either switch nameservers to Omega Digital, or (if you're keeping DNS elsewhere) change the A record to the new server IP. Cached records expire according to their previous TTL; check DNS responses before cancelling the old service.
Step 8: Verify the cutover
# Confirm DNS has switched
dig +short A yourdomain.com
# Expected: the Omega Digital server IP
# Check the server response for your domain
curl -sI https://yourdomain.com/ | grep -i server
# Expected: Server: LiteSpeed
# Issue SSL
# cPanel → SSL/TLS Status → Run AutoSSLStep 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
When the old site still appears
After the DNS change, cached records may still point to the old site. Compare responses from other resolvers:
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 # WindowsCommon issues
- 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.
- DNS caching. Lower TTL ahead of the move and allow existing cached records to expire.
- Changed authentication keys. Replacing keys and salts signs existing users out.
- Source site had hardcoded absolute paths in theme files. Grep for old server paths after the migration.
Contact support
Email [email protected] with the source host and preferred migration window. We will confirm the scope and any applicable charges.