Prepare the decision: Cloud Exit Check before repatriation. Arrange a consultation.
Cloud repatriation means moving workloads back from a public cloud. HPE includes on-premises infrastructure, private clouds and alternative hosting environments in its definition. This article uses the narrower return path to your own infrastructure or a private cloud. Definition.
The actual target architecture matters. The tables below are our decision aid, not market statistics. As of October 2026.
Contents
- Distinguish repatriation, cloud exit and migration
- Define the return path per application
- Assess target architecture and operations together
- Compare costs over the same period
- Plan repatriation with acceptance and a return path
- When remaining in the cloud should be assessed
- Our approach at WZ-IT
- Further guides
Distinguish repatriation, cloud exit and migration
These terms describe different questions. The following working distinction makes them useful for planning; it claims no binding standard. Repatriation is also used more broadly, as the HPE definition shows.
| Term | Working distinction in this article | Decisive question |
|---|---|---|
| Cloud migration | Umbrella term for moving workloads or data | What moves, and where? |
| Cloud exit | Leaving an existing cloud service or provider | Which dependency is being removed? |
| Cloud repatriation | Return from public cloud to your own infrastructure or a private cloud | Which operating and control model results? |
| Cloud-to-cloud migration | Movement between public-cloud providers | Which services need replacing at the destination? |
A move from AWS to Hetzner Cloud is therefore initially a cloud-to-cloud migration in the narrow sense used here. Selecting a destination alone does not establish whether the environment is a private cloud. Your own virtualisation deployment can instead be assessed as a repatriation destination. Describe the actual design before assigning it a label.
A complete cloud exit is also not a prerequisite for an individual repatriation. Our planning recommendation: assess a clearly bounded workload and document every connection intended to remain after the move.
Define the return path per application
Start with the business service rather than the virtual server. Inventory the application and owner, user access, data sources, background jobs and external interfaces. Each entry should have a configuration source and a responsible person.
Our recommended inventory distinguishes:
| Area | Questions to resolve |
|---|---|
| Application | How is it built, deployed, started and checked? |
| Data | Which dataset is authoritative, who writes and which history must be retained? |
| Identities | Which users, machine accounts, secrets and permissions are needed? |
| Connections | Which name resolution, certificates, networks and external services remain? |
| Restart | Which order and dependencies does a restart require? |
This produces a scope that can pass acceptance. “Bring all servers back” becomes meaningful only when application dependencies are named too. A backup of the dataset does not replace this mapping.
Assess target architecture and operations together
The HPE definition includes on-premises infrastructure and private cloud as possible target models. For actual selection, we recommend deciding location and operations separately. Control requires a named responsibility; it does not follow merely from owning a machine.
| Possible design | Our assessment task |
|---|---|
| Infrastructure at your own site | Resolve power, networking, physical access, spare parts and restart procedures |
| Your own virtualisation deployment in a hosting environment | Specify the contract, administrative access, networking and responsibility boundaries |
| Private cloud with commissioned operations | Define platform scope, changes, backup and incident handling |
| Partial repatriation with remaining cloud services | Document the authoritative data source and dependencies across both environments |
A possible virtualisation foundation can be assessed through Proxmox consulting. This does not make it a recommendation for every application. The platform must fit the functions actually needed and the organisation responsible for operations.
“Private cloud” also does not replace a security assessment. We recommend a separate acceptance list for access, patching, monitoring, backup and recovery. This article derives no blanket security or compliance advantage from a local site. Contracts and regulatory requirements belong in the assessment by the responsible specialists.
Compare costs over the same period
Compare existing and planned operations over a common assessment period. This table is a costing framework, not a model claiming average values.
| Cost block | Include in the decision |
|---|---|
| One-off transition | Design, application changes, transfer, acceptance and return path |
| Transition period | Source and destination resources needed simultaneously |
| Target resources | Hardware or rental, storage, capacity reserve and networking |
| Ongoing operations | Staff or service providers, licences, maintenance and monitoring |
| Recovery | Backup destinations, retention, replacement capacity and recovery checks |
| Remaining cloud | Services and connections still needed by the repatriated application |
Our recommendation: use measured estate data and documented quotations. Separate fixed costs, variable usage and unresolved assumptions. A lower resource bill must not be treated as total savings while additional operational services are missing.
Different load assumptions may be useful for the decision. Label them as scenarios and record which assumption changes the result. This article deliberately gives no general repatriation rate, payback period or savings figure.
Plan repatriation with acceptance and a return path
We recommend a process with verifiable outputs rather than a blanket timetable:
- Document the estate and authoritative data source; confirm responsibilities.
- Specify the target environment and required function replacements.
- Select representative data and application paths for acceptance.
- Describe transfer, write freeze, final reconciliation and switching criteria.
- Check recovery, permissions and business-level application results.
- Specify the return path including new destination data and possible deletions.
- Decommission the source only after acceptance and clarification of retention requirements.
The return path deserves a separate decision: once new data is created at the destination, simply resetting a DNS record is not a complete rollback. We recommend specifying the authoritative data state and permitted write paths before switching. This is a planning rule, not a statement about tests already performed.
When remaining in the cloud should be assessed
An open assessment must also allow remaining in the cloud or partial repatriation. Examine these options particularly when required function replacements are unclear, target responsibility is missing or calculations depend on unconfirmed assumptions.
We recommend documenting unresolved points as decision blockers. A partially defined target model should not be replaced by a general promise about cost or security. For a straightforward provider switch, the European AWS alternatives comparison is the more relevant companion guide.
Our approach at WZ-IT
The Cloud Exit Check assesses the estate, costs, lock-in, target architecture and migration path. It is the entry point before a repatriation decision. Proxmox consulting and Multi-Cloud Operations are subsequent specialist paths when they fit the target architecture or distributed operations.
Useful enquiry information includes cloud services in use, data volumes, invoices, operational responsibilities and the reason for repatriation. Migration and subsequent operations are scoped appropriately. This article promises neither a particular repatriation period nor a savings figure.
Further guides
- Cloud exit strategy for SMEs
- Select European destination providers after AWS
- Hetzner alternatives by operating model
Assess repatriation: Define the estate and target path with the Cloud Exit Check. Arrange a consultation.
