Hosting Migration: Switching Sites Without Downtime
A step-by-step guide to moving your website and email to a new server without downtime, using a full backup, a test environment and a planned DNS cutover.
Aurora YazılımEditorial team
6 min read
To migrate hosting, you first take a full backup of the files and database, upload it to the new server and test it using the hosts file. Once everything works correctly, the DNS records are pointed to the new server. Lowering the TTL before the switch and keeping the old server running for a few days prevents downtime.
What Is Hosting Migration?
Hosting migration means transferring your website's files, database and, often, email accounts from one server to another. For the visitor the address does not change; what changes is the machine the site runs on behind the scenes.
The need to migrate a site usually arises from slowness, insufficient resources, security problems, dissatisfaction with support, or a move to a new software stack. Whatever the reason, the goal is the same: a switch that visitors won't notice.
Hosting migration should not be confused with a domain transfer. Changing your domain registrar is a separate process, covered in our domain transfer article. Doing the two one after the other rather than at the same time reduces risk.
Take an Inventory Before Moving
Most outages are caused by a forgotten piece. Before you start migrating, list completely everything that runs on the old server:
- Site files: Code, uploaded images, documents and configuration files.
- Databases: Every database the site uses, along with its users and character set.
- Email: Accounts, forwards and old messages; if email is on the same server, it needs its own plan.
- Scheduled tasks: Cron jobs that run reports, backups or synchronization.
- Server settings: PHP or Node.js version, memory limits, redirect rules, SSL certificate.
- External connections: IP-based permissions in payment, shipping or API connections.
How to Take a Full Backup
The first and most important step of a migration is a complete, verified backup that makes it possible to roll back. The backup is both the source of the migration and your safety net if something goes wrong. We covered the details of a backup strategy in our how to back up your website guide.
If your control panel offers a full backup feature, you can use it. If you have SSH access to the server, you can also take the database and files from the command line:
mysqldump -u kullanici -p --single-transaction --default-character-set=utf8mb4 veritabani > yedek.sql
tar -czf site-dosyalari.tar.gz -C /var/www siteVerify the backup
Is the backup file a sensible size, does the archive open, does the end of the SQL file contain the line showing it completed? A backup that won't open is not a backup. Also download a copy to your own computer or to separate storage.
Transferring to the New Server
On the new server, prepare the environment first: the same or compatible software versions, the database and its user, required extension modules and directory permissions. Then transfer the files and the database. For a direct transfer between two servers, rsync is a fast and reliable method:
- Update the database name, user and password in the configuration file for the new server.
- Check file and folder permissions; upload folders must be writable.
- Recreate the cron jobs on the new server.
- Install the SSL certificate on the new server or reissue it.
rsync -avz -e ssh /var/www/site/ kullanici@yeni-sunucu:/var/www/site/
mysql -u kullanici -p veritabani < yedek.sqlHow to Test Without Changing DNS
Trying the site on the new server before going live is the most critical step of a migration. To do this, you add a line to your computer's hosts file that maps your domain name to the new server's IP address. That way only your computer opens the site from the new server, while visitors keep seeing the old one.
203.0.113.10 alanadiniz.com www.alanadiniz.comcurl -I --resolve alanadiniz.com:443:203.0.113.10 https://alanadiniz.comWhere is the hosts file?
During testing, try the forms, the payment step, member login, search and the admin panel one by one. When you are done, don't forget to delete the line you added.
- Windows: C:\Windows\System32\drivers\etc\hosts (Notepad must be opened as administrator).
- macOS and Linux: /etc/hosts (edited with sudo).
DNS Cutover and TTL Settings
If the test is successful, it is time for the DNS cutover. At least one day before the switch, lower the TTL value of the A records and, if needed, the MX records; this way the change propagates across the internet faster. We explained how DNS records and TTL work in our what is DNS article.
At the moment of the switch, point the A record to the new server's IP address. If your site receives live data, for example if it saves orders or reservations, you need to transfer the database again right before the switch. To avoid new records being created in that short gap, the safest way is to put the site into maintenance mode for a few minutes.
Do not shut down the old server right after the switch. Until DNS propagation is complete, some visitors may still reach the old server; keeping it running for a few days provides a safe buffer.
Be Careful When Moving Email
Email is the most sensitive part of a migration. Create the accounts on the new server with the same names, move old messages with an IMAP transfer, and change the MX record as the last step. Don't forget to update the SPF, DKIM and DMARC records for the new server too; otherwise the emails you send may end up in spam folders.
Keeping email on a separate business email service, apart from the website, makes future server changes much easier. That way email is not affected at all when the site is moved.
If you are moving to a new site or infrastructure, you can also treat the migration as an opportunity. Not carrying old, unused files, test folders and unnecessary database tables over to the new server reduces both the risk of security holes and the backup size. If the web design is being renewed from scratch, a redirect plan from old URLs to new ones should also be added to the migration schedule.
Post-Migration Checklist
The first 48 hours after the switch should be monitored closely. Check the following:
If any of these checks shows a problem, because the old server is still running, you can roll back by restoring the DNS record and return to the previous state within minutes. A migration with a rollback plan always carries less risk than one done in a hurry.
- Do all pages open over HTTPS, and is the SSL certificate valid?
- Are forms sending email, and are orders and payments being recorded?
- Are images and file downloads complete?
- How do server response time and page speed compare with before?
- Is there an increase in search engine crawl errors?
- Are new warnings appearing in the error logs?
When Is Changing Servers Necessary?
The decision to change servers usually comes with a complaint about slowness, but the source of slowness is not always the server. Heavy images, unnecessary scripts or wrong cache settings can also slow a site down. Measuring before you migrate makes sure you are solving the right problem. We handle this measurement and improvement across the image, code, server and cache layers together as part of speed and performance optimization.
If you are migrating for security reasons, be careful: if you move a site infected with malicious code, the problem moves to the new server as well. Clean first, then migrate; we described the steps to follow in our hacked website article.
For systems that process live data, such as an e-commerce store or industry-specific software, a migration must be planned without interrupting the order and stock flow. For businesses using an e-commerce platform or Aurora solutions, this move can be planned together with our team.
Frequently Asked Questions
01Does the site go down during a hosting migration?
If planned properly, it does not, or there is only a few minutes of maintenance time. Testing on the new server, a low TTL and keeping the old server running for a few days largely prevent downtime.
02Does migration affect search engine rankings?
As long as the address and content stay the same, a migration alone does not affect rankings. However, if the site stays unreachable for a long time during the move, or speed drops significantly, visibility can be affected negatively.
03How long does a DNS change take to propagate?
It depends on the record's TTL value and on internet service providers' caches. If the TTL was lowered beforehand, the change usually propagates quickly; if not, it can take longer for the old record to expire from caches.
04Can I do the migration myself?
For a simple, static site, yes, control panel tools may be enough. For sites with a database, email, payment connections and a live order flow, working with an experienced team reduces the risk of data loss.
A zero-downtime hosting migration consists of a full backup, a test environment, a planned DNS cutover and post-migration monitoring. To plan a faster, more secure setup on the new server together with measurement, you can explore Aurora's speed and performance optimization service or reach us through the contact page.
