Transferring web hosting means moving your website files, database, email, and DNS configuration from one hosting provider to another. Done in the right order — backup first, set up the new server, migrate content, test on the new server, then cut over DNS — the switch is invisible to your visitors and causes zero downtime. This guide covers the complete process step by step.
Before You Start: What You Need
- Access to your current host’s control panel or SSH credentials
- Your domain registrar login — you will update DNS records at the end
- The new VPS or hosting account already provisioned and reachable via SSH
- A verified backup of all files and the database from the current server
- At least 48 hours of buffer before any deadline — DNS propagation takes up to 48 hours
- A low TTL (300 seconds) set on your current DNS records 24 hours in advance — this reduces propagation delay at cutover
How to Transfer Web Hosting: Step by Step
- Back up everything on the current server. Files: rsync -avz /var/www/ /local/backup/. Database: mysqldump -u dbuser -p dbname > backup.sql (or pg_dump dbname > backup.sql for PostgreSQL). Verify the backup is complete and the SQL file opens correctly before continuing.
- Provision and configure the new server. Install your full web stack: NGINX or Apache, your language runtime (PHP, Python, Node.js), and your database engine (MySQL, PostgreSQL). Install SSL (Let’s Encrypt is free): sudo apt install certbot. Activate the Contabo Firewall at new.contabo.com → Network Services → Firewall before the new server IP is public.
- Transfer your files to the new server. rsync over SSH is the most reliable method for large sites: rsync -avz -e ssh /local/backup/ user@<new-server-ip>:/var/www/html/. For smaller sites, SFTP or scp work fine. Verify file counts and sizes match the source after the transfer.
- Import the database on the new server. Create the database and user first: CREATE DATABASE newdb; GRANT ALL ON newdb.* TO ‘dbuser’@’localhost’ IDENTIFIED BY ‘password’;. Then import: mysql -u dbuser -p newdb < backup.sql.
- Update your application’s configuration file. Change the database host, name, credentials, and any absolute URLs or environment variables that reference the old server’s IP or hostname.
- Test the site on the new server before touching DNS. Add a temporary entry to your local /etc/hosts file: <new-server-ip> yourdomain.com. Open the site in your browser — it should load from the new server. Test forms, logins, database reads and writes, and any APIs or webhooks.
- Set your DNS TTL to 300 seconds (5 minutes) at your registrar. Do this 24 hours before cutover so resolvers pick up the low TTL. This limits how long visitors are stuck on the old server after you change the A record.
- Update the DNS A record to your new server’s IP. Log in to your domain registrar, find the DNS zone for your domain, and change the A record to the new server IP. Propagation takes minutes to 48 hours depending on your resolver.
- Keep the old server running for 48–72 hours after cutover. Monitor your analytics and server logs to confirm traffic has moved. Only decommission the old server — and cancel the old hosting account — once you are certain all traffic is hitting the new server and everything works.
Transferring Email During a Hosting Migration
Email is the detail most people forget — and the one most likely to cause complaints. What you need to do depends on where your email is currently hosted.
If email is at a separate provider — Google Workspace, Zoho Mail, or your domain registrar’s mail service — no action is needed. Your MX records already point there independently of your hosting. Just verify MX records are unchanged after you update the A record.
If email runs on your current hosting server, export all mailboxes before cutover using imapsync or manually via IMAP. Set up the same accounts on the new server, import the mailboxes, and update your MX records at the registrar after confirming the new mail server works. Do this after files and database are confirmed — email cutover is a separate step.
A practical alternative when moving to a VPS: use a dedicated transactional mail service (Mailgun, Postmark, Amazon SES) for outbound mail and a hosted inbox (Google Workspace from $6/user/mo) for inbound. Running a self-hosted mail server is complex — SPF, DKIM, DMARC, IP reputation, and deliverability issues consume significant time to get right.
Why Migrate to a Contabo VPS?
The most common trigger for a hosting migration is outgrowing shared hosting: slow response times under load, resource limits that cap your app, and no root access to install or configure anything beyond what the host permits. A Contabo Cloud VPS gives you dedicated resources, full root access, and flat-rate pricing with no surprise bills when traffic spikes.
| Plan | vCPU | RAM | Storage | Price | Migrate from |
|---|---|---|---|---|---|
| Cloud VPS 4 | 4 | 8 GB | 100 GB SSD | €4.40/mo* | Small shared hosting plan, personal blog, dev environment |
| Cloud VPS 6 | 6 | 12 GB | 200 GB SSD | €6.00/mo* | WordPress on shared hosting, small e-commerce, growing site |
| Cloud VPS 8 | 8 | 24 GB | 300 GB SSD | €11.20/mo* | Busy CMS, multiple sites, database-driven app with real traffic |
| All plans include always-on DDoS protection and a free configurable Contabo Firewall. | |||||
FAQ: Transferring Web Hosting
Yes. Web hosting can be transferred from any provider to any other provider at any time. Your domain name and your hosting are separate — you can switch hosting without changing your domain name or losing your URL structure. The process involves backing up your files and database, setting up the new server, migrating content, testing, then updating DNS.
The technical migration — backup, file transfer, database import, config update, testing — takes 1 to 4 hours for a typical site. DNS propagation after cutover takes minutes to 48 hours depending on TTL. Setting TTL to 300 seconds 24 hours before cutover minimises propagation time significantly.
Not if you follow the correct order: back up first, migrate to the new server, test thoroughly, then update DNS. Never delete files from the old server until you have confirmed the new server is receiving all traffic. Keep the old server running for 48–72 hours after DNS cutover.
No. The migration is entirely under your control — you back up your own files, set up a new server, and update DNS. Only cancel your old hosting plan after you are fully migrated and satisfied the new server is working correctly. Check your old contract for notice periods before cancelling, but technically the migration itself requires no advance notice to the old host.
