In 2026, more organisations are re-checking whether every workload belongs in the public cloud. Not because cloud failed — but because migration decisions made between 2019 and 2022 do not always hold up under scrutiny in 2026. The practical trend is selective: some workloads stay cloud-native, while others move back to owned or colocated infrastructure when cost, latency, data handling, or operational control justify it.
If you are an IT manager in Singapore reviewing a cloud bill that has grown faster than your headcount, or a business owner about to face a compliance audit and wondering where your data actually sits, this trend is directly relevant to you.
What cloud repatriation actually means
Cloud repatriation is the process of moving workloads from public cloud infrastructure back to on-premises hardware or colocation facilities. It is selective, not wholesale. Businesses doing this are not ripping out Microsoft 365, abandoning Salesforce, or shutting down their AWS accounts. They are making workload-by-workload decisions about what makes sense to run on infrastructure they own or control.
The typical pattern: keep email, collaboration, SaaS applications, and customer-facing web services in cloud. Pull back database servers carrying large stable datasets, AI inference workloads running at scale, legacy applications lifted-and-shifted without re-architecting, and any processing that involves regulated data requiring Singapore residency.
What cloud repatriation is not: an exit from cloud or a return to the IT practices of 2010. Global cloud spending continues to grow. The businesses doing repatriation well are running hybrid environments with clear, deliberate logic behind which workloads sit where. That is categorically different from the reflexive "cloud-first" mandates that produced some of the overruns we are now seeing corrected.
What is driving it in 2026
Cost overruns that were not visible at contract time
Cloud pricing is rarely what it appears at the point of commitment. Compute costs are the headline figure. What compounds quietly are egress fees (charged every time data leaves the cloud region), IOPS charges on storage-intensive workloads, snapshot accumulation over time, managed service fees for databases and Kubernetes clusters, and support tier costs that escalate with usage.
The Flexera 2025 State of the Cloud Report — based on responses from 759 cloud decision-makers — found that 17% of organisations exceeded their cloud budgets. That is not a rounding error; it represents a significant cohort running materially over their planned spend. The same report found that 75% of organisations cite lack of in-house cloud expertise as a top challenge, which compounds the problem: environments that are not properly optimised accumulate idle resources, orphaned snapshots, and oversized instance types that nobody has reviewed.
Cloud pricing, usage patterns, and managed-service footprints can change materially after migration. A business that modelled costs in 2021, migrated in 2022, and has not revisited the numbers since may be paying more than the original business case assumed. The correction is not always dramatic, but it is worth checking.
AI workloads change the economics
Cloud AI APIs (OpenAI, Azure OpenAI, AWS Bedrock, Google Vertex AI) are the correct answer for low-volume, exploratory, or intermittent AI use. The economics shift when AI becomes part of daily operations at scale.
According to Acronis (2026), on-premise AI infrastructure can deliver 40 to 50% lower total cost of ownership over three years compared to cloud API spend once token volume becomes significant. A business processing thousands of documents a day, running AI-assisted customer service, or embedding inference into backend workflows is spending at a volume where the per-token cloud API cost starts to accumulate faster than the amortised cost of on-premise GPU hardware.
This is not a universal recommendation for GPU servers — it is a calculation that needs to be done at your actual projected usage volume. But the businesses that run the numbers seriously are increasingly finding that on-premise GPU is competitive, particularly where workloads are predictable and steady rather than spiky.
Data sovereignty and ASEAN localisation requirements
Singapore, Indonesia, and Vietnam are each strengthening their data localisation frameworks. For Singapore-headquartered businesses, the PDPA already requires reasonable protection of personal data and clear accountability for where it is processed. Businesses subject to MAS Technology Risk Management (TRM) guidelines face additional requirements around control and auditability of systems handling customer financial data.
Separately, a 2026 survey found that 57% of IT leaders globally feel the need to run infrastructure within a single country. For businesses with customers or operations across ASEAN, this is not a theoretical concern — it is a compliance and contracting issue that affects how you structure data flows across borders.
Keeping regulated data on Singapore physical infrastructure — whether that is your own server room or hardware hosted in a Singapore colocation facility like Equinix SG or GDS Singapore — provides a cleaner compliance narrative than a public cloud deployment where the actual physical location of your data is abstracted away by the provider. This matters when you are responding to an MAS audit, a PDPC data protection inquiry, or a customer due-diligence questionnaire.
Cloud expertise that never materialised
Cloud expertise deserves more attention than it typically gets. Cloud migration was sold, in many cases, as a simplification. In practice, managing a cloud environment well requires skills in IAM configuration, security group design, cost tagging and governance, auto-scaling policies, and cloud-native monitoring — none of which are trivial.
Businesses that migrated without building these skills often ended up with environments that reproduced their on-premise problems at higher monthly cost, and added new ones. Misconfigured security groups. IAM roles with excessive permissions. Storage buckets with no lifecycle policies accumulating years of snapshots. These are not hypothetical failure modes — they appear regularly in cloud security assessments.
Some businesses, on reflection, conclude that managing on-premise hardware (or having a managed services partner do it) is simpler and better-controlled than managing a cloud environment their team does not fully understand.
What workloads are typically being repatriated
Not everything, and not randomly. The workloads most commonly moved back share specific characteristics: high or growing cost, predictable and steady load (rather than spiky), and either compliance requirements or AI compute intensity.
Commonly repatriated:
- Database servers with large stable datasets. High storage and egress costs in cloud; on-premise or colocation is more cost-effective at steady load.
- AI inference at scale. Once token or compute volume crosses the threshold where on-premise GPU amortises favourably, the economics support repatriation.
- Regulated data processing. Financial records, personal data under PDPA, healthcare data — workloads where the compliance narrative is cleaner on physical infrastructure under your direct control.
- Legacy applications lifted-and-shifted without re-architecting. These applications often run inefficiently in cloud and do not benefit from cloud-native capabilities. They are simply running on someone else's hardware at a premium.
What typically stays in cloud:
- Email and collaboration (Microsoft 365, Google Workspace). These are pure SaaS; there is no infrastructure to repatriate.
- Customer-facing applications needing geographic distribution or CDN integration.
- Development and test environments with genuinely spiky, intermittent load.
- SaaS applications where the vendor manages the infrastructure entirely.
The decision is not cloud versus on-premise as competing ideologies. It is a workload-by-workload question with a financial and compliance answer.
What we typically see in practice
Working with Singapore businesses across manufacturing, professional services, financial services, and education, several patterns appear consistently.
The most common situation is a business that migrated in 2020 or 2021, reduced on-premise infrastructure significantly, and has not revisited the cloud architecture since. The initial migration was managed by the cloud vendor or a system integrator on a project basis. The ongoing management fell to an internal IT team that was not fully trained in cloud operations. Three years later, the environment has accumulated idle instances, redundant snapshots, and managed services that were enabled during the migration and never switched off. The monthly bill has grown, but nobody has done a line-by-line review.
A second pattern: businesses that moved to cloud primarily for flexibility, found the flexibility was never used (workloads are steady and predictable, not variable), and are now paying a premium for optionality they do not exercise.
A third: businesses under MAS TRM or with significant PDPA obligations that accepted cloud vendor assurances about Singapore-region residency during migration, but have not formally documented or verified this in a way that would satisfy an auditor. The data may well be in Singapore, but the audit trail is not in place.
The fourth pattern is the most actionable: businesses approaching a hardware refresh cycle — servers due for replacement in the next 12 to 18 months — who realise this is actually a three-way decision between replacing hardware, going fully cloud, or moving hardware to a colocation facility. For regulated Singapore businesses with existing on-premise applications, colocation is often the option that gets underweighted in that conversation.
What clients rarely come to us asking about cloud repatriation directly. They arrive with a different presenting problem: a cloud bill that has grown unexpectedly, a compliance review that has flagged data location questions, or a hardware refresh quote that prompts them to reconsider the whole infrastructure model. The repatriation question emerges from that conversation.
Is this relevant to your Singapore business?
Three scenarios where a review is warranted:
You moved to cloud three to five years ago and have not reviewed costs since. If your cloud bill has grown without proportional user or workload growth, a review is overdue. Specifically: pull your egress charges as a separate line item, look at snapshot storage accumulation, identify idle or stopped instances, and check what managed service fees you are paying for databases or container orchestration. These four items collectively account for most unnoticed cloud cost overruns.
You are approaching a server hardware refresh. When existing hardware comes to end of life, the replacement decision is not binary. The three options are: buy new hardware and keep it on-premise, migrate to cloud, or buy new hardware and house it in a colocation facility. For Singapore businesses with compliance obligations or significant data volumes, the colocation option often delivers the compliance benefits of on-premise without the facility management burden. Get a colocation quote before defaulting to cloud.
You are embedding AI into daily operations. Model your cloud API cost at target usage volume over three years. Compare it to the amortised cost of an on-premise GPU server (upfront hardware cost plus power, maintenance, and management) over the same period. If you are running AI at scale, the on-premise economics may be compelling. If volume is low or uncertain, cloud APIs remain the right answer.
How to do a workload-by-workload cost review
This does not need to be a long project. A structured review of most SMB cloud environments can be completed in a week with the right approach.
Step 1: List every system in cloud with costs broken out. Compute, storage, egress, managed service fees, and support tier should be separate line items. Cloud provider cost explorer tools can generate this; the key is not accepting a single monthly total.
Step 2: Classify each workload. SaaS (no infrastructure decisions to make), web application, data or database, AI or compute-intensive, backup and archive, or legacy application. This classification drives the analysis.
Step 3: For each workload running at steady predictable load, model the three-year on-premise or colocation cost. Include hardware purchase or refresh, hosting fees if colocation, power and cooling, and management or maintenance costs. Use Singapore colocation pricing (a half-rack in a Singapore Tier 3 facility currently runs approximately SGD 1,500 to SGD 3,000 per month depending on power allocation and provider).
Step 4: Identify compliance requirements. Does each workload involve personal data under PDPA? Financial data under MAS TRM? Does it require Singapore physical residency? Flag these explicitly — they affect both the cost comparison and the risk weighting.
Step 5: Surface candidates for repatriation. Workloads that combine high or growing cost, steady load, compliance requirements favouring physical control, or AI compute intensity are candidates. Low-cost or genuinely spiky workloads are not.
Step 6: Get quotes and do the three-year comparison properly. For shortlisted candidates, obtain colocation or hardware refresh quotes and build a proper three-year total cost of ownership model. The decision should be made on that model, not on gut instinct or vendor recommendations.
The discipline, not the direction
Cloud repatriation is a maturity signal. Businesses doing it well are not reacting to a crisis or reversing a failed strategy — they are applying the same cost discipline to cloud spend that they should have applied when they migrated. The migration decisions that now look expensive were often made under pressure, with vendor-provided cost models, by teams that lacked the operational experience to scrutinise them.
The correction is not a verdict on cloud as a model. It is a verdict on undisciplined adoption.
Singapore businesses reviewing their infrastructure in 2026 have an advantage that was not available in 2020: real cost data, from real environments, over several years of operation. Use it.
If your organisation has been running on cloud for more than three years without a structured review, or if you are approaching a hardware refresh decision and want a clear-eyed three-way comparison, Aggasys offers infrastructure assessments for Singapore businesses. We will review your current environment, model the alternatives, and give you a recommendation based on your actual workload profile and compliance requirements — not on which option we make more margin from.
Book an infrastructure assessment with Aggasys
Written by Lee Yang Sean, Aggasys Solutions | sean@aggasys.com | LinkedIn