How to Migrate From Contabo Without Downtime

If you run production workloads on Contabo and your application has started feeling sluggish during peak hours, you are not alone. The most common reason customers contact our team about Contabo migrations is inconsistent disk IO and noisy-neighbor behaviour on shared nodes. This guide walks through a clean migration path that keeps downtime under sixty seconds in most cases, using nothing more than DNS TTL preparation, rsync, and a short cutover window.

Why People Leave Contabo

Contabo offers aggressive pricing, and for static workloads that price often wins. The trade-off becomes visible once your VPS sits next to a noisy neighbour. Common symptoms our team sees during onboarding:

• iowait regularly climbing above 15% on otherwise idle systems
• Random fsync() latency spikes that hurt MySQL, PostgreSQL, and Redis persistence
• Inconsistent network throughput between Contabo regions
• Backup windows extending well beyond their normal duration

If two or more of those sound familiar, a migration is usually worth the half-day of preparation it requires.

What You Will Need

Before starting, confirm you have:

1. Root SSH access to your current Contabo VPS
2. A registered MMITech Cloud VPS or AMD VPS account with a provisioned target VPS
3. Access to your DNS provider control panel
4. A list of services running on the source VPS (databases, web servers, cron jobs, queue workers)
5. Approximately one hour of supervised time for the cutover

The Migration Plan

Our recommended sequence is the same one we use internally when relocating customer infrastructure between datacenters.

Step 1: Lower DNS TTL (24 to 48 hours before cutover)

The single biggest cause of post-migration downtime is stale DNS. Lower your A and AAAA records to a 300-second TTL at least 24 hours before you plan to switch:

example.com.    300    IN    A    <current_contabo_ip>
www.example.com. 300   IN    A    <current_contabo_ip>

This guarantees that when you flip the records later, resolvers worldwide pick up the new IP within five minutes.

Step 2: Provision and Prepare the Target VPS

On your new MMITech VPS, install the same OS family and matching major versions of your application stack. Match PHP, MySQL or PostgreSQL, Node.js, and Python versions exactly. Mismatched minor versions are fine; mismatched major versions cause subtle bugs that appear hours after cutover.

Step 3: First-Pass Rsync (no downtime)

While the source server is still serving traffic, run an initial rsync of the file system. This handles the bulk transfer without affecting users:

rsync -avz --numeric-ids \
  --exclude=/proc --exclude=/sys --exclude=/dev \
  --exclude=/tmp --exclude=/run --exclude=/mnt \
  --exclude=/var/log \
  -e "ssh -i ~/.ssh/migration_key" \
  root@source.contabo.example:/ /mnt/migration/

Depending on dataset size and your Contabo upload speed, this typically takes one to six hours.

Step 4: Database Replication or Dump

For most small to medium workloads, a logical dump taken during the maintenance window is sufficient. For larger databases, set up replication 24 hours ahead:

# MySQL/MariaDB logical dump (run during cutover)
mysqldump --single-transaction --routines --triggers \
  --all-databases | gzip > /mnt/migration/db-final.sql.gz

For PostgreSQL, pg_dump with --format=custom is the cleanest option.

Step 5: Maintenance Window Cutover

This is the only step that incurs downtime. Aim for fifteen to thirty minutes of buffer; real downtime is usually under one minute.

1. Put your application into maintenance mode on the source
2. Stop databases, queue workers, and cron jobs on the source
3. Run a final rsync delta (this is fast, only changes since step 3 transfer)
4. Import the final database dump on the target
5. Start services on the target and run a smoke test against its IP directly
6. Update DNS A and AAAA records to the new MMITech IP
7. Monitor logs on both source and target for thirty minutes

Step 6: Decommission Window

Keep the Contabo VPS running for seven days after cutover. Some recursive resolvers ignore TTL, and a small percentage of users may still hit the old IP for a few hours.

Comparison: Contabo vs MMITech Cloud VPS

Common Migration Pitfalls

We see the same three mistakes repeatedly:

Forgetting non-web services. Mail queues, fail2ban databases, and custom systemd timers do not migrate themselves. List systemctl list-unit-files --state=enabled on the source and reconcile on the target.

Hardcoded IP addresses. Application configs, firewall rules, and SSL certificate ACME challenges sometimes reference the old IP. Grep for it: grep -r "<old_ip>" /etc /opt /var/www.

SSL certificate Let's Encrypt rate limits. If you regenerate certificates on the target before cutover and again after, you can hit the duplicate-certificate limit. Either copy /etc/letsencrypt over with rsync or use DNS-01 challenges.

Why MMITech for the Destination

Our Cloud VPS platform runs on Ceph-backed storage with 40GbE cluster networking, which gives you predictable IO regardless of what other tenants are doing. Every VPS includes Proxmox Backup Server with deduplicated, encrypted, off-cluster backups. Our infrastructure sits in an EU datacenter with redundant power and connectivity, and our team responds in seven languages including English, Slovenian, German, Italian, Croatian, Czech, and Hungarian.

If you prefer AMD Ryzen performance for single-threaded workloads, our AMD VPS line uses the same Ceph backend.

FAQ

How long does a typical Contabo migration take? For a single VPS running standard web and database workloads, expect four to eight hours total, with one to thirty minutes of actual downtime depending on database size.

Can I keep my Contabo IP address? No. IPs are assigned per provider and cannot be transferred between ASNs. This is why DNS TTL preparation matters.

What if my dataset is too large for rsync? For datasets above 500 GB, we recommend using rsync --inplace combined with database replication. For datasets above 2 TB, contact our team and we will set up a temporary high-bandwidth transfer link.

Do you offer managed migration? Yes. Our team can perform the entire migration on your behalf. Contact us through the support portal with your current Contabo specifications and we will quote a fixed price.

Is there a trial period? You can provision a VPS, run it in parallel with your Contabo instance during the migration, and decide based on real performance before cutting over DNS.

Ready to Migrate?

If predictable IO and an EU-based provider matter to your workload, provision a Cloud VPS and run it in parallel with your current Contabo instance during the migration window. You will see the IO difference within the first hour.