Cloud repatriation is the planned move of workloads, including virtual machines (VMs), from public cloud back to on-premises, colocation, or private infrastructure. Enterprises do it mainly to cut costs on steady workloads, meet data-residency or compliance requirements, and get more predictable performance. Most do it selectively rather than leaving the cloud entirely: IDC reports that only 8-9% of companies plan full workload repatriation.
Key Takeaways
Repatriation is selective, not a mass exit. IDC's survey figure for full repatriation is 8-9%, and Flexera's 2026 report finds 73% of organizations operating hybrid environments.
Cost surprise is the common trigger. IDC found that close to half of cloud buyers spent more than expected in 2023, and Flexera's 2026 report cites wasted cloud spend at 29%, the first increase in five years.
Exit is harder than entry. AWS VM Export cannot export instances with AWS-provided Windows or SQL Server software, Marketplace-derived images, multiple disks or multiple network interfaces, so many production VMs need a backup-based or in-guest migration path instead.
Free egress is built for full exits. AWS's data-transfer waiver covers moving all data off AWS, not selected VMs, so partial repatriation should budget standard transfer fees.
Repatriated VMs need a new protection design. CISA advises offline, encrypted, regularly tested backups, and a cloud-native backup policy does not carry over automatically.
Best candidates are steady, predictable, data-heavy VMs. Bursty, globally distributed, or managed-service-dependent workloads usually belong in the cloud.
What is Cloud Repatriation?
Cloud repatriation means moving a workload, its data, or both from a public cloud provider to infrastructure the organization controls. For VM-based workloads, that usually means rebuilding the same VM on an on-premises hypervisor, in a colocation facility, or on a private cloud platform.
The move can cover one element or the whole stack. IDC's survey work notes that organizations more often repatriate specific elements such as production data, backup processes and compute than entire workloads.
How Repatriation Differs from Related Terms
Term | What it means | How it differs from repatriation |
Cloud repatriation | Moving workloads or data from public cloud back to controlled infrastructure | The reference term for this guide |
Cloud exit | Leaving a cloud provider entirely | A subset of repatriation: every workload leaves, and the account may be closed |
Cloud-to-cloud migration | Moving workloads between public cloud providers | Destination is another public cloud, so the hypervisor, billing, and shared-responsibility model change less |
Hybrid cloud | Running some workloads in cloud and some on-premises | The end state many organizations reach after partial repatriation |
Lift and shift | Moving a VM unchanged to a new platform | A method, not a goal: repatriation can use it, but may also re-platform |
Where Repatriated VMs Land
On-premises data center: Full control over hardware, network, and security; you carry capacity planning and refresh cycles.
Colocation: Your hardware in a provider's facility; removes the building and power burden, not the hardware and platform operations.
Private cloud: A VM platform with self-service and automation on dedicated infrastructure, on-premises or hosted.
The destination decides which hypervisor formats, drivers, and backup integrations matter later in this guide.
Why are Enterprises Moving VMs Back On-Premises?
Five drivers account for most repatriation decisions: cost that does not match expectations, steady workloads that gain little from elasticity, data-heavy or latency-sensitive systems, security and compliance control, and AI workloads with strict data requirements. The first has the strongest published evidence.
Driver | Why it pushes VMs back | Evidence | Most relevant when |
Cost overruns | Cloud bills grow faster than planned, and unused capacity still bills | IDC Cloud Pulse 4Q 2023: close to half of cloud buyers spent more than expected, and 59% of them expected similar overruns in 2024. Flexera 2026: 85% name managing cloud spend a top challenge | The monthly bill is high, and utilization is flat |
Steady-state workloads | Pay-per-use pricing rewards variable demand; a VM that runs 24/7 at constant load uses little of that flexibility | Reasoning from the pricing model; no single survey isolates this | Databases, ERP, file services, internal apps with stable demand |
Data gravity and egress | Large datasets are costly to move and to read back out | Moving data out incurs transfer charges unless a waiver applies (see below) | Data-heavy VMs that feed on-premises systems |
Security and compliance control | Some regulated data must stay in a location or under a control model the organization owns | Flexera 2026: 53% of cloud leaders cite security and compliance as the top challenge for cloud-based AI | Regulated data, sovereignty rules, AI on sensitive data |
Performance and latency | Local storage and network avoid shared-tenancy variance and WAN round trips | Depends on workload and design; no universal benchmark | Latency-sensitive systems co-located with factory, clinic or trading equipment |
What the evidence does not show
Plans are not completed moves. IDC's 8-9% figure is a stated plan for full repatriation, not a measured count of workloads already moved.
Cost data describes the cloud, not the alternative. A cloud bill that disappoints does not prove on-premises will be cheaper once hardware, staff, power, refresh cycles, and backup are counted.
Public numbers are scarce. Beyond a few disclosed cases (covered below), there is little verifiable cost data from completed repatriations. Treat any single "X% of enterprises are repatriating" headline cautiously and check which question the survey asked.
The practical reading is that repatriation is a workload-level decision. The next section shows how to make it.
Which VMs Should Move Back, and Which Should Stay?
Move VMs whose demand is steady, whose data is large or location-bound, and whose dependencies are portable. Keep VMs whose value comes from elasticity or from cloud-managed services. Judge each VM, not the whole estate.
Decision Matrix
Factor | Leans toward repatriation | Leans toward staying in cloud |
Demand pattern | Flat, predictable load running 24/7 | Spiky, seasonal or unpredictable load |
Data profile | Large datasets read often by on-premises systems | Data already produced and consumed in cloud |
Service dependencies | Plain VM with OS and application only | Tied to managed databases, queues, serverless or identity services |
Latency and location | Must sit near local equipment, users or data | Users are globally distributed |
Compliance | Data must stay under organization-controlled infrastructure | Provider certifications already satisfy the requirement |
Commitment status | Reserved or committed term ending soon | Long commitment with significant remaining term |
Operations capacity | Team already runs virtualization, backup and DR | No on-premises platform team, hardware or facility |
Disk and NIC layout | Simple layout that exports cleanly (see next section) | Multi-disk, multi-NIC, encrypted or marketplace-derived instances that are hard to export |
Scenario-Based Recommendations
Always-on line-of-business VM, simple layout: Strong candidate. Savings come from removing continuous rental of capacity that never flexes.
Seasonal web tier with autoscaling: Keep in cloud. Elasticity is the reason it exists there.
Large file or database VM serving on-premises users: Candidate if the data is already mirrored locally or can move once.
VM using the provider's managed database: Re-architect before moving. Repatriating the VM alone breaks the dependency.
Pre-Decision Checklist
☐ Utilization data for each VM covers at least one full business cycle.
☐ Cloud cost includes compute, storage, snapshots, licenses and data transfer for this VM.
☐ On-premises cost includes hardware, hypervisor licensing, power, network, backup storage and staff time.
☐ Every service dependency is documented and has an on-premises equivalent.
☐ The export method is confirmed feasible for this VM's disk, NIC, encryption and licensing.
Why is Getting a VM Out of the Cloud Harder Than Getting It In?
Because provider export tools are built around simple images, and the VMs with the largest savings potential are often the ones those tools refuse. The constraints below come from each provider's own documentation and can change by version, region, and configuration, so confirm them before you plan.
Provider | Native export route | Documented constraints that matter for repatriation |
AWS | VM Import/Export to OVA, VHD or VMDK, written to an S3 bucket | Cannot export instances containing third-party software provided by AWS (for example Windows or SQL Server instances, or any Marketplace image); more than one virtual disk; more than one network interface; encrypted EBS snapshots; instance store volumes; volumes larger than 1 TiB. Destination bucket must be in the same account and cannot use SSE-KMS. Default limit is 5 concurrent conversion tasks per Region |
Microsoft Azure | Download a managed disk as a VHD through a SAS URL | The disk cannot be downloaded while attached to a running VM: stop and deallocate it, or snapshot the disk. A snapshot of a running VM is crash-consistent. SAS links expire (60-day maximum), and an active SAS blocks the VM from starting until you cancel the export |
Google Cloud | Export a custom image to Cloud Storage | Default output is a tarred, gzipped disk.raw; vmdk, vhdx, vpc, vdi and qcow2 are available through the export-format option. Only images you created or imported can be exported; Google-provided public images cannot. Cloud Build sessions last at most 24 hours, so very large images need a manual export |
How Do you Repatriate a VM From Public Cloud to On-Premises?
Classify the VM, confirm an export path, build and protect the landing zone, pilot, convert and validate, then cut over with a rollback window. Each step has a failure point worth planning for.
1. Inventory and classify. Record vCPU, memory, disks, NICs, OS and license type, data size, dependencies, and compliance needs for each VM. Failure point: hidden dependencies on managed cloud services that only surface after cutover.
2. Build the per-VM business case. Use the payback formula from the previous section, including transfer and parallel-run cost.
3. Choose and size the target platform. Match the hypervisor, storage, and network capacity to the VM profile. Decide the backup design now, not after cutover.
4. Pick the export method per VM. Use the provider's native export when the VM qualifies. Use a backup-based or in-guest migration when it does not. Failure point: discovering an export restriction after the maintenance window is booked.
5. Pilot a low-risk VM. Prove the full chain: export, transfer, conversion, boot, network, application test.
6. Transfer and convert. Move the image to the target and convert the disk format and drivers. See the platform table below. Failure point: a VM that boots in the pilot but fails with a different disk controller or boot mode.
7. Validate before cutover. Test application function, authentication, DNS, time sync, licensing, and monitoring on an isolated network.
8. Cut over with a rollback window. Keep the cloud VM stopped but intact until the on-premises VM has passed an agreed observation period. Failure point: deleting the source too early, then needing it.
9. Protect and decommission. Take the first backup, run a test restore, then delete cloud snapshots, disks, SAS links, and idle resources to stop billing.
Example commands
These are provider and platform commands for one export path each. Check the current documentation for your version before running them.
Export a Google Cloud image as qcow2, from the Google Cloud export guide:
gcloud compute images export \
--destination-uri DESTINATION_URI \
--image IMAGE_NAME \
--export-format qcow2
Import a disk into Proxmox VE 7.2 or later in one step, from the Proxmox migration guide:
qm create VMID --scsi0 STORAGE:0,import-from=/PATH/TO/DISK.IMG --boot order=scsi0
For Azure, there is no single command in this workflow: stop and deallocate the VM, open the disk's export page, generate a SAS URL, and download the VHD, as described in Microsoft's download guide.
How Does the Target Hypervisor Change the Migration?
The target decides which disk format you need, which guest drivers must be present, and how the VM boots. Cloud export formats map to on-premises platforms as shown below. This depends on the platform, version, and configuration, so test each combination in a pilot.
Target platform | Formats available from cloud export | What to check |
VMware vSphere / ESXi | AWS exports OVA or stream-optimized VMDK; AWS documents compatibility with vSphere versions 4, 5 and 6 | Confirm the image imports on your current vSphere release; the AWS page does not name newer versions |
Microsoft Hyper-V | AWS exports VHD, documented as compatible with Hyper-V and Citrix Xen; Azure downloads managed disks as VHD | Match VM generation to the guest's boot mode; verify integration services after boot |
Proxmox VE | Any disk image that qemu-img or qm disk import accepts; Google Cloud can export vmdk, vhdx, vpc, vdi or qcow2 | Per the Proxmox guide: one-step import-from needs Proxmox VE 7.2 or later; VMDK converts with qemu-img convert; OVF imports with qm importovf; UEFI guests need --bios ovmf; Windows guests need extra drivers for SCSI, so temporarily boot from SATA |
KVM-based platforms (oVirt, RHV, OLVM and similar) | Google Cloud can export qcow2 directly | Check the disk bus (VirtIO or SATA) and that the guest has the matching drivers |
XenServer / Citrix Hypervisor | AWS exports VHD | Install Xen guest tools after the first boot |
Troubleshooting Common Repatriation Failures
Symptom | Likely cause | Fix |
Export task rejected | VM has multiple disks or NICs, encrypted snapshots, a volume over 1 TiB, or AWS-provided Windows or SQL Server software | Choose a backup-based or in-guest migration; see the AWS limits above |
Azure VM will not start after download | An active SAS is still attached to the disk | Select Cancel export on the disk's export page, then start the VM |
Azure download fails with 403 | The SAS link expired or was created with a longer lifetime than the 60-day maximum | Revoke it and generate a new SAS |
Google Cloud export fails or leaves resources behind | Session ended, export job failed, or image too large for one Cloud Build session (24-hour limit) | Delete leftover temporary disks, instances, and buckets; export very large images manually |
Windows blue screen at first boot | Boot disk controller driver missing on the target | Boot from SATA first, install the target's storage drivers, then switch the controller (Proxmox guide) |
Boots into firmware or no boot device | BIOS/UEFI mismatch between source and target VM definition | Match the target's firmware mode to the source; on Proxmox, set --bios ovmf for UEFI guests |
No network after boot | New virtual NIC model or MAC address, so the guest sees a different interface | Reconfigure the interface in the guest; check VLAN and gateway on the target |
Cloud-specific agents or metadata services fail | Guest still expects the provider's metadata endpoint or agent | Remove or disable provider agents; this depends on the guest OS and how the image was built |
Windows asks to reactivate | Licensing is tied to the original environment | Check your license terms and activation method; this depends on the license type |
How Should you Protect VMs after They Move Back On-Premises?
Design backup and recovery before cutover, because on-premises you own the full recovery chain that the cloud provider previously handled for you. That includes backup storage, a copy the production network cannot reach, and tested restores.
What to design
Offline or isolated copy. CISA's ransomware guide advises maintaining offline, encrypted backups, because many ransomware variants try to find and delete or encrypt accessible backups.
Tested restores. The same guide advises regularly testing the availability and integrity of backups in a disaster recovery scenario. A backup that has never been restored is an assumption.
Recovery priorities per VM. NIST SP 800-34 Rev. 1 is a contingency planning guide for information systems; use its approach to set recovery requirements and priorities for each system, then record the recovery time and recovery point targets you will actually test.
Restore to a different host or platform. Test restoring to a host other than the original. Repatriation often changes the hypervisor, so a restore that only works on identical hardware gives false confidence.
Immutability needs care. CISA notes that some cloud vendors offer immutable storage and advises using it with caution because misconfiguration can be costly. Test retention settings before relying on them.
Where Vinchin Fits
Backup tooling also helps with the move itself when native export is refused. Vinchin Backup & Recovery lists AWS EC2 among its supported public cloud platforms, alongside on-premises platforms including VMware vSphere, Microsoft Hyper-V, Proxmox VE, XCP-ng, Citrix Hypervisor, oVirt, Red Hat Virtualization and Oracle Linux Virtualization Manager. Its cross-platform recovery converts a backed-up VM by analyzing the source and target VM formats, and the product describes this as agentless.
Two cautions apply. The cross-platform page does not state which platforms work as source, target or both, so confirm your exact pair with the vendor. The compatibility page is version-specific: at the time of writing it did not list vSphere 9.x or Windows Server 2025 Hyper-V hosts.
What Do Real Repatriation Cases Show?
Two documented cases show large savings, and both involved steady workloads, in-house engineering depth, and years of effort. Both figures are company-reported, so treat them as case evidence rather than industry averages.
Case | What happened | Reported result | What to learn |
Dropbox, 2015-2016 | Moved the vast majority of user content to custom-built infrastructure, per its 2018 S-1 filing | GeekWire reported that the S-1 cited $74.6 million in cumulative savings over two years and that Dropbox still used AWS for under 10% of its storage needs | The workload was storage at very large scale, with a purpose-built platform. Few enterprises can copy this approach |
37signals, 2022-2025 | Moved applications off AWS onto owned servers, then began moving S3 data to Pure Storage arrays | DHH reported in September 2023 that monthly cloud spend excluding S3 fell from about $180,000 to under $80,000, a 60% drop, after about $500,000 of new servers. The Register reported in May 2025 a roughly $1.5 million, 18 PB storage purchase and AWS waiving $250,000 in download charges | Stable workloads, an experienced operations team and a staged approach (compute first, storage later). The May 2025 article did not confirm that the AWS account deletion had been completed |
Best practices
Start with a pilot VM that exercises export, conversion, boot and backup, then scale.
Move by workload group, not by VM, so dependent systems cut over together.
Keep the source intact for an agreed observation period after cutover.
Back up the cloud VM before migration so you have a restorable copy if native export is refused.
Measure after the move. Compare real on-premises run cost and performance against the business case.
Re-check provider terms for data-transfer waivers, commitments and notice periods before you schedule.
FAQs
Q1: Does repatriating VMs mean returning to the hypervisor I used before the cloud?
No. The target platform is a separate decision. Cloud exports produce formats such as VMDK, VHD and qcow2 that several platforms can use, so the choice rests on skills, licensing terms, features and backup support. Whatever you pick, test boot and driver behavior in a pilot.
Q2: Is a snapshot of a running cloud VM safe to migrate from?
Not always. Microsoft notes that a snapshot of a running Azure VM is crash-consistent and is generally safe only when the VM has a single OS disk; with data disks, stop the VM first. Databases may need to run recovery on first boot from a crash-consistent copy.
Q3: How long does downloading a large VM disk take?
It depends on disk size and connection speed. Microsoft's guide says large Windows VHDs can take several hours. Estimate from your measured throughput, and plan the maintenance window around the slowest VM.
Q4: Can I keep a copy in the cloud for disaster recovery after repatriating?
Yes, and many hybrid designs do. Remember that restoring from cloud storage back on-premises moves data out of the cloud, so standard transfer charges may apply. Price a full restore in your DR plan, not only the monthly storage cost.
Q5: Is on-premises infrastructure less secure than public cloud?
Neither is secure by default. Security depends on who operates which controls and how well. On-premises, you own patching, physical security, network segmentation and backup protection, which is why guidance such as CISA's emphasizes offline and tested backups.
Q6: What happens to reserved or committed cloud spend if I move VMs out?
This depends on your provider contract. Check remaining term, minimum commitments, and any notice requirements before setting a cutover date, because a commitment can outlast the VM it was bought for.
Q7: Can Vinchin move a VM from AWS EC2 to Proxmox VE?
Vinchin's compatibility page lists both AWS EC2 and Proxmox VE as supported platforms, and its cross-platform recovery converts VMs between platforms. The page does not spell out every source and target pair, so confirm the exact combination and your versions in the compatibility matrix before planning around it.
Conclusion
Repatriation is a per-VM engineering and finance decision, not a strategy to adopt wholesale. Steady, portable, data-heavy VMs justify the move; elastic or service-dependent ones rarely do. Two checks decide most outcomes: whether the VM can actually leave the provider's platform, and whether transfer and backup costs still leave a worthwhile payback. Run both before buying hardware.
