Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Server migration is the process of moving an application, website or database to new hardware, a new provider, or new cloud infrastructure, and without careful planning it can cause hours of downtime. This guide explains DNS TTL, blue-green deployment and database replication, and walks through the process of migrating with close-to-zero downtime, from inventory to the final DNS switch.
A downtime-free move is only possible by correctly combining four core concepts.
TTL determines how long a DNS record is cached by browsers and resolvers; lowering the TTL before a migration shortens the DNS propagation time at the moment of cutover.
A deployment model where the old (blue) and new (green) environments run simultaneously, and traffic is switched to the new one with a single change, DNS or a load balancer.
Setting up continuous incremental synchronization from the source database to the destination means only a few seconds of difference need to be closed at cutover time.
In a maintenance window, the site is temporarily made read-only or unavailable; true zero-downtime migration continues uninterrupted, including writes, without users noticing anything.
Every minute of downtime during a migration translates directly into a measurable cost.
For e-commerce and SaaS applications, downtime is directly proportional to lost orders and subscription revenue.
If search engine bots can't reach the site during migration or receive error responses, it can cause temporary or permanent ranking losses.
Users who hit an unexpected server error quickly lose trust in the site and the brand.
In an unplanned cutover, out-of-sync writes between the source and destination databases can cause data loss or conflicts.
A close-to-zero-downtime migration isn't improvised; it requires a sequence of steps that have each been tested beforehand.
List every file, database, cron job, environment variable and third-party integration (payments, email, CDN) that needs to move.
Lower the TTL to 300 seconds or less at least 24-48 hours before the cutover date so propagation is fast when the moment comes.
Prepare the application environment on the new server and start incrementally copying files from the source server with rsync.
Set up replication (e.g. MySQL master-slave) that continuously mirrors the source database to the destination, reducing the gap at cutover to seconds.
Without changing the real DNS, verify that every function on the new server, such as form submissions, payments and login, works correctly using a hosts file entry or a test domain.
Sync the last differences during a short read-only window, switch the DNS record to the new server, closely monitor traffic and error rates; thanks to the low TTL, you can quickly roll back to the old server if something goes wrong.
rsync -avz --delete -e ssh /var/www/site/ user@newserver:/var/www/site/
CHANGE MASTER TO MASTER_HOST='old-server-ip', MASTER_USER='repl_user', MASTER_PASSWORD='********', MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=4; START SLAVE;
SHOW SLAVE STATUS\G
dig +short yourdomain.com dig yourdomain.com | grep -i "ttl"
Turkey (Turkish)
Germany (German)
Worldwide (English)
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://yourdomain.com/healthrsync -avz --delete -e ssh /var/www/site/ user@newserver:/var/www/site/ mysqldump --single-transaction old_db | mysql -h newserver new_db
True zero downtime is achievable for the web server and static files; a write-heavy database usually still needs a read-only window of a few seconds to a few minutes. With careful planning that window can be short enough that users never notice it.
Lower the TTL at least one full current-TTL period before the cutover date, ideally 24-48 hours in advance, so that by cutover time most resolvers have already picked up the shorter TTL.
If you're using a CDN, you don't need to wait on DNS propagation at all: the DNS record already points to the CDN, so you just update the origin server IP in the CDN's dashboard, and the change propagates much faster depending on the CDN's own cache.
If you lowered the TTL in advance and kept the old server running for a while, you can roll back within minutes by pointing the DNS record back at the old server's IP, which is why it's important not to shut down the old server for at least a few days after cutover.
For read-heavy applications, replication makes a near-seamless cutover possible; but to guarantee data consistency, a short window where the last writes are paused is generally the safest approach.
A properly configured migration, with the same URL structure, correct redirects and uninterrupted access, should not affect SEO; but long outages, broken links or incorrect redirects can cause temporary or permanent ranking losses.
A reference explaining what DNS TTL is and how it affects propagation time.
The official reference for MySQL replication architecture and configuration.
The official documentation for every parameter of the rsync command.
Check out our Linux VPS plans with NVMe storage, high bandwidth and instant setup, ready for your migration.