{"id":178,"date":"2016-03-06T07:00:47","date_gmt":"2016-03-06T01:30:47","guid":{"rendered":"https:\/\/www.merahost.org\/blog\/?p=178"},"modified":"2026-10-23T11:10:23","modified_gmt":"2026-10-23T05:40:23","slug":"how-to-migrate-a-website-from-one-server-to-another","status":"publish","type":"post","link":"https:\/\/merahost.org\/blog\/how-to-migrate-a-website-from-one-server-to-another\/","title":{"rendered":"How to Migrate a WordPress Website to a New Server with Zero Downtime (Step-by-Step Guide)"},"content":{"rendered":"

Executing an infrastructure migration between hosting providers is one of the most critical operational procedures a systems administrator or agency operator will perform. Done incorrectly, server transitions result in broken database serializations, lost customer transactions, email bounce loops, and catastrophic search engine ranking drops. However, by leveraging structured asynchronous data synchronization and pre-cutover DNS staging, you can execute a seamless transfer with literally zero minutes of service disruption to MeraHost<\/a>.<\/p>\n

<\/p>\n

Zero-Downtime Server Migration: The Definitive Engineering Summary<\/h2>\n
\n

Direct Answer:<\/strong> Achieving zero downtime when migrating a website from one server to another requires a 5-phase pipeline: (1) Lowering DNS Time-to-Live (TTL) to 300 seconds 48 hours prior to migration; (2) Performing an initial asynchronous data sync of all media and core files via encrypted rsync<\/code> while the live site continues serving traffic; (3) Exporting a consistent database dump using mysqldump --single-transaction<\/code>; (4) Verifying full application functionality on the target server using local \/etc\/hosts<\/code> override mapping; and (5) Executing DNS record updates. Visitors will transition seamlessly to the new server with zero dropped connections.<\/p>\n<\/div>\n

The 5-Phase Technical Migration Pipeline<\/h2>\n

Phase 1: Pre-Flight Audit & DNS TTL De-escalation<\/h3>\n

The primary reason site owners experience prolonged DNS caching delays during migrations is neglected TTL settings. Standard domain zone files configure TTL between 14,400 seconds (4 hours) and 86,400 seconds (24 hours). If you update nameservers without lowering TTL first, global ISP resolvers will continue routing user traffic to the deactivated legacy server for up to a full day.<\/p>\n

Forty-eight hours prior to migration<\/strong>, access your authoritative DNS manager (Cloudflare, cPanel Zone Editor, or domain registrar) and reduce the TTL on your primary A<\/code>, AAAA<\/code>, and CNAME<\/code> records to 300 seconds (5 minutes)<\/strong>:<\/p>\n

; Lower TTL to 300 seconds on your authoritative DNS\nexample.com.        300    IN    A        198.51.100.42  ; Old Server IP\nwww.example.com.    300    IN    CNAME    example.com.<\/code><\/pre>\n
Phase 2: Asynchronous File Transfer via Encrypted Rsync<\/h3>\n
Instead of downloading massive ZIP files through browser HTTP connections (which frequently timeout on multi-gigabyte wp-content\/uploads<\/code> directories), execute a direct server-to-server synchronization using rsync<\/code> over SSH. This transfers 98%+ of static media and plugin assets without stressing the live production application:<\/p>\n
# Run from the target destination server (MeraHost NVMe Node)\nrsync -avzP --exclude 'wp-content\/cache\/*' \\\n            --exclude 'error_log' \\\n            -e \"ssh -p 22\" \\\n            root@source-server.com:\/home\/username\/public_html\/ \\\n            \/home\/username\/public_html\/<\/code><\/pre>\n
\n  Sysadmin Tip:<\/strong> The --exclude 'wp-content\/cache\/*'<\/code> flag prevents copying gigabytes of stale cached HTML files, dramatically accelerating the transfer and ensuring your target server generates clean, fresh caches upon deployment.\n<\/div>\n
Phase 3: Consistent Database Extraction & Import<\/h3>\n
For high-concurrency platforms or WooCommerce stores handling live transactions, locking tables during export can cause application timeouts. Utilize the --single-transaction<\/code> flag to snapshot InnoDB tables in a consistent transaction state without blocking database writes:<\/p>\n
# 1. Export database on legacy server\nmysqldump -u db_user -p --single-transaction --quick --routines --triggers db_name > \/tmp\/site_db_backup.sql\n\n# 2. Transfer SQL dump to new MeraHost server\nscp -P 22 \/tmp\/site_db_backup.sql root@new-server.com:\/tmp\/\n\n# 3. Import SQL dump into target database on new MeraHost server\nmysql -u target_db_user -p target_db_name < \/tmp\/site_db_backup.sql<\/code><\/pre>\n
Update your target server's wp-config.php<\/code> credentials with the new database name, username, and password:<\/p>\n
\/\/ wp-config.php database connection configuration\ndefine( 'DB_NAME',     'wpmh_production' );\ndefine( 'DB_USER',     'wpmh_dbuser' );\ndefine( 'DB_PASSWORD', 'SecureGeneratedPass#2026' );\ndefine( 'DB_HOST',     'localhost' );\ndefine( 'DB_CHARSET',  'utf8mb4' );\ndefine( 'DB_COLLATE',  'utf8mb4_unicode_ci' );<\/code><\/pre>\n
Phase 4: Staging Verification via Local Hosts File Mapping<\/h3>\n
Never update public DNS records without thoroughly testing the migrated environment first. You can force your local development workstation to render the website directly from the new server's IP address without altering public DNS routing:<\/p>\n