How do you migrate from OVH to Hetzner?

Inventory the estate and dependencies, build the destination, transfer and verify data at application level, switch writes in a controlled manner and document the return path. The method depends on the OS, database and services.

Is a vRack the same as a Hetzner Network?

No. vRack connects OVHcloud resources. Hetzner Cloud Networks and dedicated server vSwitch coupling have their own configuration and limits. Redesign the destination network.

Is rsync enough for a running database?

No. A file copy does not demonstrate a consistent database state. Use an engine-appropriate backup or replication method and verify restoration.

Must I clone the entire server?

No. For a bounded Linux application stack this guide recommends a new destination server and a selective transfer of configuration and data. An image migration requires its own compatibility checks.

Can I run OVH and Hetzner in parallel during migration?

Provisioning resources in parallel is a planning step. Writing services must not create two authoritative datasets unintentionally. Define costs, access paths and the authoritative dataset beforehand.

Is migration automatically cheaper?

No. Compare the source invoice, destination resources, transfer, parallel operations and operational services. The article claims no blanket saving.

Is changing DNS back a complete rollback?

No. Once the destination has new data, returning or retaining that data must also be resolved. An old server alone does not solve this.

What does WZ-IT offer for this?

OVH to Hetzner migration covers assessment of the starting point, target architecture and a scoped migration path. Subsequent operations are agreed for the destination environment.

OVH to Hetzner: Data, Networking and Migration Cutover

Timo Wevelsiep29.10.2026

#Cloud
#Migration
#Hetzner

Editorial note: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, prices, versions, licensing terms, and external content may change. Please verify the information provided independently, particularly before making business-critical or security-related decisions. This article does not replace individual professional, legal, or tax advice.

Scope the OVH move: Migrate OVH to Hetzner. Arrange a consultation.

An OVH to Hetzner move starts by identifying what is moving: a Linux application, several public cloud instances, a dedicated server or an environment with private networks and separate databases. This guide structures the process for Linux applications you administer. It is not a universal image import or an account of a customer project.

Sources as of October 2026. The checklists are our planning recommendations, the commands adaptable examples.

Record the estate and migration boundary
Plan vRack and the destination network separately
Prepare the destination before copying data
Transfer files and databases separately
Define cutover and the return path
Review costs and acceptance
Our approach at WZ-IT
Further guides

Record the estate and migration boundary

Our recommendation: keep a per-application list of services, data sources, connections, credentials and owners. A server list alone describes neither data flows nor acceptance.

Estate	Information to record	Destination check
Public cloud or dedicated server	OS, architecture, services, persistent paths	Suitable runtime and capacity
Database	Engine, version, extensions, roles, backup method	Restoration and business queries
vRack and public access	Networks, routes, permitted connections, DNS, certificates	Access through approved paths only
Files and object storage	Writing applications, metadata, retention	Readability, permissions and reconciliation
Operations	Backup, monitoring, updates, owners	Assigned responsibilities and restart procedure

Also define what will remain at OVH. A partially relocated system needs documented connections between both environments. The decision should allow an application to remain when replacement functionality is unresolved.

Plan vRack and the destination network separately

vRack connects OVHcloud services over a private network. This does not make its network configuration transferable to another provider. At Hetzner, a Cloud Network can connect dedicated servers through vSwitch coupling; the documentation specifies a limit of one vSwitch per Network.

Our migration conclusion: redraw the required connections rather than merely copying old VLAN names. Record source, destination, port, name resolution and approval per connection. Check for overlapping address ranges and plan access during parallel operations separately. A database must not become unintentionally public during the move.

We recommend a checkpoint for every change: the application reaches its database, administration reaches the destination and unapproved access is denied. These are acceptance criteria, not test results claimed here.

Prepare the destination before copying data

For a bounded application stack, we recommend a fresh destination installation. This avoids turning unreviewed source configurations into the destination architecture. Define OS, runtime, packages, service accounts, mountpoints and startup order explicitly.

Hetzner's data migration guide covers backing up and copying data and distinguishes this from transferring whole partitions. This article likewise covers application and data transfer. A full system image requires separate checks of bootability, drivers, filesystems and networking.

Before transfer, establish destination access, storage reserve and a recovery path. Transfer accounts and secrets selectively. Overwriting destination /etc or /boot wholesale is not part of our procedure.

Transfer files and databases separately

For ordinary application files, rsync over SSH is an option. In the rsync manual, --dry-run means a trial run; -a alone includes neither hardlinks nor ACLs or extended attributes. A trailing slash on the source path denotes its contents.

rsync -av --dry-run -e ssh /srv/app/uploads/ migration@TARGET_IP:/srv/app/uploads/

Replace TARGET_IP, account and paths. Removing --dry-run copies only the named path, not a whole machine. We recommend checking the destination path, file list and permissions first. If the application needs ACLs, extended attributes or particular owners, explicitly select the necessary options and permissions. Deletion reconciliation is a separate decision.

Databases need a separate transfer method. For PostgreSQL, pg_dump produces a consistent dump of a database; this does not capture global role definitions. For other engines, choose the relevant vendor procedure. Including a running database's data directory in file synchronisation is not evidence of consistency.

Our recommended sequence: initial file transfer, database restoration rehearsal, application checks, then an agreed write freeze for the final dataset. Include background jobs and external imports in the freeze when they change the dataset.

Define cutover and the return path

Before switching, record which data source becomes authoritative. Define who freezes writes, confirms final reconciliation and approves the destination. A reachable web server alone does not establish business acceptance of the application.

Our checklist:

Stop writing web requests, jobs and imports according to the runbook.
Transfer final files and database state and resolve discrepancies.
Check the destination application using the intended hostname.
Switch DNS, external allowlists and integrations according to plan.
Accept login, permissions, upload and a business write operation.
Decommission the source only after approval and resolving retention.

The return path must account for new destination data. Specify how it will be handled after an abort and when the source may write again. This decision belongs in the runbook; a generic reference to DNS does not replace it.

Review costs and acceptance

For cost assessment, we recommend a common assessment period and the same service assumptions. Record source resources, destination resources, data transfer, parallel operations and subsequent operational support. Use invoices and specific quotations instead of a blanket savings rate.

Acceptance should cover data, functionality and operations: agreed datasets, permissions, external integrations, backup, monitoring and restart. Record expected and actual results. This article provides a structure, not invented measurements or a migration duration.

Our approach at WZ-IT

OVH to Hetzner migration is the matching offer for this move. If destination selection is still open, the Cloud Exit Check assesses the estate, costs and dependencies before a decision. Hetzner expertise complements the destination platform.

An application list, network overview, database type, data volume and intended operational responsibilities help scope an enquiry. Implementation and subsequent operations are defined against that estate.