For years, enterprise IT strategy largely pointed in one direction: towards the public cloud. Businesses moved applications, databases and growing volumes of data off-site to gain flexibility, scale quickly and reduce the need for upfront infrastructure investment.
That picture is changing.
Organisations are becoming more selective about where workloads and data should live. Predictable cloud bills, data sovereignty, latency and the sheer volume of data generated by AI and analytics are all influencing infrastructure decisions.
This shift is driving interest in cloud repatriation, where selected workloads or datasets move from public cloud environments back to on-premises, private cloud or colocation infrastructure.
It is not necessarily a retreat from cloud computing. Increasingly, it is about putting the right workload in the right environment.
What is cloud repatriation?
Cloud repatriation is the process of moving applications, workloads or data from public cloud infrastructure back to privately controlled environments such as an on-premises data centre, private cloud or colocation facility.
In practice, cloud repatriation is usually selective.
An organisation might move a large analytics repository or AI dataset onto dedicated infrastructure while keeping customer-facing applications in the public cloud. Another might run production databases locally but continue using cloud services for collaboration, development or short-term compute capacity.
Western Digital describes a similar shift from "cloud-first" thinking towards a more value-driven mix of public cloud, private infrastructure and colocation, with organisations considering cost, performance, governance and workload requirements when deciding where infrastructure should sit.
For most organisations, enterprise workload repatriation is therefore better understood as workload rebalancing rather than abandoning the cloud.
Why are businesses moving workloads back on-prem?
There is rarely one reason to move workloads from cloud to on-prem. Decisions are usually driven by a combination of cost, performance, control and changing data requirements.
Cloud storage and infrastructure costs
Public cloud works particularly well when demand is uncertain or highly variable. Infrastructure can be provisioned quickly without buying hardware in advance.
The economics can change once workloads become stable.
A database, data lake or AI repository running continuously with hundreds of terabytes or petabytes of persistent data behaves very differently from a temporary development environment.
Cloud expenditure can also extend beyond headline storage and compute prices. Depending on the service and architecture, costs can include data transfers, operations, replication, snapshots, support and other consumption-based services.
For predictable workloads, organisations can compare those recurring cloud storage costs with the multi-year cost of owning, leasing or operating dedicated infrastructure.
That does not make on-prem automatically cheaper. Power, cooling, networking, staffing, software and hardware lifecycle costs still matter. The meaningful comparison is total cost of ownership across the life of the workload.
Cloud egress costs
Storing data is only one part of the equation. Moving it matters too.
Cloud egress costs can apply when data leaves certain cloud environments or crosses particular provider, service or regional boundaries.
Those charges may be relatively insignificant for applications moving small quantities of information. For data-intensive workloads, they can become far more noticeable.
AI training datasets, high-resolution media, scientific information, analytics platforms and large data lakes can involve frequent movement between storage and compute environments.
Keeping frequently accessed datasets closer to the systems consuming them can reduce unnecessary transfers and make infrastructure spending easier to forecast.
Hammer Stack specifically positions Western Digital as its storage layer for keeping datasets and model artefacts local, helping reduce exposure to variable cloud storage and egress costs.
Latency and performance
Some workloads need consistent access to data rather than virtually unlimited elasticity.
Manufacturing systems, analytics, certain databases, high-performance computing and AI inference can all be sensitive to latency.
When storage and compute are placed closer together, organisations have greater control over network paths and performance characteristics.
Data gravity also becomes important as datasets grow. Moving an application can be relatively straightforward. Continually moving petabytes of information around a distributed infrastructure is not.
For some workloads, bringing compute closer to the data can therefore make more sense than repeatedly moving the data closer to compute.
Data control and sovereignty
Organisations in regulated or data-sensitive environments may also require greater control over where information is stored and processed.
This can apply to financial information, intellectual property, personal data, healthcare records, government workloads and proprietary AI datasets.
Running appropriate workloads on privately controlled infrastructure gives organisations more direct control over storage location, administrative access, infrastructure configuration and lifecycle management.
Hammer Stack reflects this requirement particularly strongly around AI, positioning on-prem infrastructure as a way to retain control over data, performance and costs while addressing sovereignty and governance requirements.
Which workloads are best suited to cloud repatriation?
Not every application is a good candidate for cloud to on-prem migration. The strongest candidates usually combine predictable demand with large data volumes, performance requirements or a need for greater infrastructure control.
Large, data-intensive workloads
Data lakes, analytics repositories, scientific datasets, media archives, backup repositories and large object stores can all justify closer evaluation.
The key questions are not simply how much data exists, but how quickly it is growing, how frequently it is accessed and where it needs to be processed.
Predictable 24/7 workloads
Cloud elasticity has considerable value when demand changes rapidly.
For a workload operating at relatively stable utilisation around the clock, however, an organisation may be paying continuously for flexibility that it rarely uses.
Databases, storage clusters and other steady-state production environments can therefore be strong candidates for a detailed cloud versus on-prem TCO comparison.
AI, analytics and HPC workloads
AI training, analytics and high-performance computing can involve large datasets and sustained compute demand.
Public cloud remains useful for experimentation and burst capacity, but established production workloads may justify dedicated infrastructure once utilisation becomes predictable.
Western Digital's current data-centre portfolio specifically addresses environments including AI, HPC, analytics and scalable data infrastructure.
Latency-sensitive workloads
Applications requiring consistent low latency can benefit from being closer to their data.
Examples include real-time analytics, industrial systems, interactive media and AI inference close to where information is generated.
Sovereignty or compliance-sensitive workloads
Where data location, governance or access must be tightly controlled, privately managed infrastructure may provide organisations with more direct oversight.
That does not mean every associated service needs to move on-prem. Sensitive data can remain locally controlled while selected cloud services continue to be used elsewhere.
How can cloud repatriation reduce infrastructure costs?
Cloud repatriation can reduce costs when a workload's characteristics have changed since it originally moved to the cloud.
A young application may initially have uncertain demand, making public cloud a natural choice. Several years later, the organisation may know exactly how much compute, storage and network capacity it consumes.
That predictability makes it possible to size dedicated infrastructure around real operating data.
A realistic comparison should include:
- compute and storage charges
- data transfer and egress
- backup and replication
- software and licensing
- servers and storage hardware
- networking
- power and cooling
- support
- data-centre or colocation costs
- staffing
- lifecycle replacement
- expected data growth
The objective is not simply to find the lowest storage price. It is to calculate the total cost of operating the workload over its expected lifecycle.
Repatriation can also improve cost predictability. Hammer Stack, for example, combines on-prem control with subscription and leasing options intended to avoid both large upfront investment and highly variable monthly infrastructure bills.
What role does storage play in cloud repatriation?
Storage is often one of the most important parts of a cloud repatriation strategy because large datasets are difficult, expensive and time-consuming to move.
A repatriated environment needs enough capacity for today's data while allowing room for future growth. It must also deliver the throughput, resilience and availability the application requires.
This usually leads to tiered storage rather than a single technology.
Flash can provide high performance where low latency or high IOPS are required. High-capacity HDDs can provide the capacity layer for large persistent datasets where cost per terabyte and storage density matter.
Western Digital positions Ultrastar enterprise HDDs for the parts of hybrid infrastructure organisations directly control, including local data centres, server rooms, edge environments and colocation facilities. Its hybrid cloud guidance highlights workloads including analytics, backup, archive and compliance.
At platform level, Western Digital's Ultrastar Data Series provides high-density JBOD storage for data-intensive environments. Current configurations support up to 3.26 PB of scalable raw storage, with Western Digital positioning the platform for AI, HPC, cloud and software-defined architectures.
The objective is not simply to recreate public cloud storage inside a data centre. It is to create a scalable storage foundation that supports the economics and performance requirements of the workloads being repatriated.
How does cloud repatriation support data sovereignty?
Data sovereignty and data residency are closely related, but they are not the same thing.
Data residency usually refers to where information is physically or geographically stored.
Data sovereignty concerns the jurisdiction, governance requirements and legal frameworks applying to that data.
Cloud repatriation can give organisations greater direct control over those variables by allowing selected datasets to remain within defined infrastructure and geographic boundaries.
This can be particularly important where sensitive information, intellectual property or AI training data is involved.
A hybrid approach can also be useful. Controlled datasets can remain on-prem or in colocation while appropriate cloud services continue to provide additional compute, analytics or application functionality.
Hammer's current sovereign infrastructure guidance follows this workload-placement approach, recommending that organisations first identify where data resides, where it can move and what compliance or audit restrictions apply.
Public cloud, on-prem or hybrid infrastructure?
No single infrastructure model is right for every workload.
Public cloud provides elasticity and rapid deployment. On-prem infrastructure provides greater direct control and can offer predictable economics for stable workloads. A hybrid infrastructure strategy allows organisations to use both.
|
Consideration |
Public cloud |
On-prem infrastructure |
Hybrid infrastructure |
|
Initial investment |
Typically lower |
Hardware investment, finance or leasing required |
Depends on workload placement |
|
Cost model |
Consumption-based and potentially variable |
More predictable once deployed |
Different models for different workloads |
|
Elasticity |
Very high |
Requires capacity planning |
Local baseline with cloud capacity when required |
|
Large persistent datasets |
Convenient, with recurring consumption costs |
Can be attractive at sustained scale |
Core data can remain local while cloud services are used selectively |
|
Egress exposure |
Can apply to outbound data movement |
No cloud egress charge for locally retained data |
Can reduce unnecessary transfers |
|
Latency |
Depends on network and region |
Greater control over local performance |
Workloads can be placed according to latency needs |
|
Data control |
Provider manages underlying infrastructure |
Direct infrastructure control |
Sensitive workloads can remain controlled locally |
|
Best suited to |
Variable workloads and rapid experimentation |
Stable, data-intensive or control-sensitive workloads |
Mixed workload requirements |
The table also illustrates why cloud repatriation is rarely an all-or-nothing decision.
An organisation could keep a large AI dataset on-prem while using public cloud for temporary compute. An analytics platform might run locally at a predictable baseline while using cloud infrastructure during demand peaks.
Western Digital's hybrid cloud guidance similarly presents public cloud, privately controlled infrastructure and colocation as complementary parts of a broader architecture rather than mutually exclusive alternatives.
When does cloud repatriation not make sense?
Cloud repatriation should not be treated as the default response to a high cloud bill.
Highly variable workloads often continue to benefit from public cloud elasticity because purchasing enough on-prem capacity for occasional peaks can leave expensive infrastructure sitting idle.
Short-term projects and proof-of-concept environments may also be cheaper and simpler to run temporarily in the cloud.
Applications built extensively around managed databases, serverless functions or proprietary cloud services can be difficult to repatriate because infrastructure savings may be outweighed by the cost of re-engineering the application.
Operational capability matters too. On-prem infrastructure requires monitoring, security, lifecycle management, resilience and capacity planning.
The useful question is therefore not, "Should we leave the cloud?"
It is, "Which parts of this workload genuinely benefit from running somewhere else?"
How to build a cloud repatriation strategy
A successful cloud repatriation strategy starts with the workload, not the hardware.
1. Profile workloads and data
Measure current compute utilisation, storage capacity, throughput, network traffic and growth.
Identify application dependencies and determine which datasets are frequently accessed, rarely touched or repeatedly transferred between environments.
2. Model cloud and on-prem TCO
Compare the full lifecycle cost of the existing cloud environment with the proposed infrastructure.
Include hardware, cloud consumption, storage, egress, software, power, cooling, support, staffing and expected growth.
3. Design the target infrastructure
Size compute, storage and networking around observed workload requirements.
Storage architecture should account for capacity growth, performance, resilience, backup and disaster recovery rather than simply matching the amount of data currently stored.
4. Pilot the migration
Begin with a workload that has predictable utilisation, clear dependencies and manageable business risk.
Plan data movement carefully, particularly when hundreds of terabytes or petabytes are involved. Transfer time, migration egress costs, encryption and validation all need consideration.
5. Measure results and retain flexibility
Compare actual performance and operating costs with the assumptions used in the business case.
Where possible, keep the architecture portable enough to use cloud resources when they provide value.
Hammer's AI infrastructure guidance follows a similar sequence: define the workload, map the data, determine workload placement and then build the full infrastructure platform around those requirements.
Cloud repatriation FAQs
What is cloud repatriation?
Cloud repatriation is the selective movement of applications, workloads or data from public cloud infrastructure to on-premises, private cloud or colocation environments.
Why are businesses moving workloads back on-prem?
Common drivers include cloud storage costs, egress charges, predictable utilisation, latency requirements, data sovereignty and the need for greater infrastructure control.
Which workloads are best suited to cloud repatriation?
Large data-intensive workloads, predictable production applications, AI and analytics environments, latency-sensitive systems and sovereignty-sensitive data are common candidates.
Can cloud repatriation reduce costs?
It can when sustained utilisation makes dedicated infrastructure more economical over the workload's lifecycle. Businesses should compare complete TCO rather than hardware and cloud prices in isolation.
Does cloud repatriation mean abandoning public cloud?
Usually not. Most repatriation strategies are selective. Public cloud can remain valuable for variable demand, temporary projects, cloud-native services and burst compute while suitable workloads run on privately controlled infrastructure.
From cloud-first to workload-first
Cloud repatriation is not evidence that public cloud has failed. It reflects a more mature approach to infrastructure.
As data volumes grow and workloads become easier to predict, businesses can make more deliberate decisions about where applications and information should live.
For data-intensive environments, that increasingly means evaluating public cloud, on-prem and colocation infrastructure as complementary options.
The question is no longer simply whether a business should be in the cloud.
It is where each workload and dataset can deliver the right balance of cost, performance, scalability and control.
