How to Migrate From OVH: A Complete Guide

OVH built much of the European hosting market, and many of our customers ran on OVH for years before migrating. The trigger is usually one of three events: the 2021 Strasbourg datacenter fire that destroyed SBG2 and damaged adjacent halls, a support ticket that took days to resolve, or simply outgrowing the dedicated server offering. This guide covers the migration end to end, with specifics for both VPS and dedicated server workloads.

Risk Framing: Why Single-Provider Dependence Matters

The Strasbourg fire on 10 March 2021 destroyed an entire datacenter building and took thousands of services offline for days, with some customers losing data that had been backed up only within the same campus. The lesson was not that OVH is unsafe; the lesson was that any provider can have a bad day, and if your backups live with your primary infrastructure, you have no backups.

Most customers who migrate to our platform keep their previous OVH instance running for some time afterward as a secondary site, and several keep it as a permanent off-site backup target. We support both approaches.

Pre-Migration Checklist

Before you start, gather the following:

1. Root SSH access to the OVH source (VPS or dedicated)
2. OVH manager access for IPv4 failover, reverse DNS, and any vRack configuration
3. A provisioned MMITech Cloud VPS or dedicated server matching or exceeding your current specifications
4. Access to your DNS registrar
5. A current backup that lives outside OVH

If you do not have the last item, take one now using restic or borg to an S3-compatible bucket or a separate location before touching anything else.

Migration Path: VPS Workloads

Step 1: Inventory Services

OVH VPS instances often accumulate auxiliary services over time. Run a quick audit:

systemctl list-unit-files --state=enabled
crontab -l -u root
ls /etc/cron.d/
netstat -tlnp

The netstat output reveals every listening service. Anything unexpected gets investigated before migration, not after.

Step 2: Lower DNS TTL

48 hours before the planned cutover, drop your A and AAAA record TTLs to 300 seconds. If you use OVH DNS, change it in the OVH manager. If you use an external DNS provider, change it there.

Step 3: Initial Rsync

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

OVH upload speeds vary by location. Strasbourg and Roubaix typically push 400 to 800 Mbit; Gravelines is slower for southern European destinations.

Step 4: Database and State

For most workloads:

mysqldump --single-transaction --routines --triggers \
  --master-data=2 --all-databases | \
  ssh root@target.mmitech.example "gzip > /root/db-final.sql.gz"

The --master-data=2 flag records the binary log position, which is useful if you later decide to set up replication during the final cutover instead of taking a hard switch.

Step 5: Cutover

Maintenance window steps:

1. Enable maintenance mode on the source
2. Stop application services on the source (systemctl stop)
3. Final delta rsync (typically under five minutes)
4. Import the database dump on the target
5. Start services on the target
6. Validate over the target's direct IP using a hosts file entry
7. Update DNS A and AAAA records
8. Update OVH IPv4 failover or vRack routes if applicable

Migration Path: Dedicated Server Workloads

Dedicated server migrations are more involved because hardware specifications, RAID configurations, and licensed software all matter. The general approach:

1. Provision an MMITech dedicated server with equivalent or higher specs
2. Replicate the storage layout (LVM, ZFS, or hardware RAID) on the target
3. Use rsync for the bulk of data, but consider block-level tools like ddrescue or lsyncd for large datasets
4. Replicate database state via logical dump or native replication
5. Validate licensed software (cPanel, Plesk, MS SQL) before cutover

For Plesk migrations specifically, the Plesk Migrator tool handles most of the work, including IP preservation logic if you coordinate the cutover with our team.

Comparison: OVH vs MMITech

What Customers Tell Us After Migrating

Two themes come up repeatedly. The first is response time: when our team answers a support ticket, the answer comes from someone who can actually log into the cluster and check, not from a first-tier dispatcher. The second is backup confidence: included Proxmox Backup Server with deduplicated off-cluster backups means recovery is a known quantity, not a paid add-on.

Pitfalls Specific to OVH

OVH-specific kernel modules. Some OVH templates ship with custom kernel parameters or vRack-specific networking. Verify /etc/network/interfaces (Debian) or /etc/sysconfig/network-scripts/ (RHEL) for vRack VLAN configuration that will not exist on the target.

Hardcoded OVH IPs in firewall rules. OVH provides anti-DDoS at the network layer and customers sometimes encode OVH-specific filtering. Audit iptables-save for OVH netblocks.

Failover IP attachment. If you use OVH failover IPs, they cannot move between providers. Plan to switch to MMITech-native IPs and update DNS accordingly.

License keys tied to IP. cPanel, Plesk, and some commercial software license against IP. Coordinate license reissuing with the vendor before cutover.

FAQ

Can I keep using OVH as a backup target after migration? Yes, and many customers do exactly this. Our Proxmox Backup Server supports remote sync targets, so you can replicate backups to an OVH-hosted PBS instance for geographic separation.

How does pricing compare for equivalent specs? For VPS workloads, MMITech is broadly comparable to OVH on raw resources, with included backup that OVH charges separately. For dedicated servers, pricing depends on configuration; our team will quote based on your current OVH spec.

Do you support OVH's vRack equivalent? Our Cloud VPS supports private VLANs between your instances at no additional cost. This covers the same use case as vRack for inter-VM communication.

What about IPv6? Every MMITech Cloud VPS includes a /64 IPv6 allocation. If you currently use OVH's larger blocks for SMTP reputation reasons, talk to our team about allocation options.

Is there a migration discount? We offer extended trial periods for customers migrating from another provider. Provision a VPS, run it in parallel for the migration window, and only pay for full service once cutover is complete.

Start Your Migration

If you have a current OVH instance and want EU-located hosting with predictable performance and direct operator support, provision a Cloud VPS and run it alongside your OVH server during the migration. The parallel-running phase costs little, removes all risk from the cutover, and gives you real performance data before you commit.