On-Premise to Cloud: When It Makes Sense and When It Doesn't

The real question stopped being cloud versus on-premise

The framing of this decision as a single, once-and-done migration is out of date. Gartner projects that around 90% of organisations will run multi-cloud or hybrid architectures by 2027, and public cloud spending is still growing strongly, forecast at over 20% in 2025 alone to roughly US$723 billion. Neither of those facts fits the narrative of a wholesale retreat from cloud, and neither fits the narrative of cloud winning outright either. The honest picture is that most businesses of any size are running a mix, deliberately, workload by workload, not because a migration went wrong.

Cloud repatriation headlines do capture something real, but the numbers get stretched. Barclays' CIO survey found 86% of CIOs planning to move at least some workloads back to on-premise or private infrastructure, a figure widely quoted as evidence of a cloud exodus. IDC's data tells a more precise story: only around 8 to 9% of companies are planning full repatriation of anything. The gap between those two figures is the difference between "we are rethinking where specific workloads run" and "cloud failed us," and it is strategically important not to confuse the two when making your own decision.

Where the physics still favours local, not the pitch deck

Two conditions consistently justify keeping infrastructure on-premise or hybrid in 2026, and they map closely to where ASEAN businesses actually operate: manufacturing floors, plantations, ports, retail chains, and multi-site operations spread across a region with uneven connectivity.

Sensor and machine data

A single factory floor with a few hundred sensors tracking vibration, temperature, and throughput generates a continuous stream of telemetry that is mostly, correctly, uninteresting. The standard architectural pattern in edge computing, well established by now in manufacturing deployments, is to process that stream at the source and send only the exceptions, the anomalies, and the periodic summaries upstream, rather than the raw feed. Sending everything to the cloud unprocessed is not just an unnecessary egress cost, it is frequently the wrong design: control-loop decisions, such as shutting down a machine before a bearing fails, need a response measured in milliseconds, and a round trip to a cloud region does not reliably deliver that. Processing at the edge, where the sensor is, is not a compromise in these cases. It is the correct architecture, with the cloud used for aggregation, model training, and longer-term analytics rather than every individual reading.

Multi-site and low-connectivity operations

The second condition is organisational rather than technical: operations spread across several sites where connectivity is inconsistent, expensive, or simply not the business's to control. A warehouse network, a palm oil plantation estate in East Malaysia, a port terminal, or a regional branch network across Singapore, Malaysia, Indonesia and the Philippines cannot always assume a reliable low-latency link back to a central cloud region. If a site's point-of-sale system, warehouse management, or safety monitoring stops functioning the moment its internet connection drops, that is an operational risk that hybrid architecture is specifically designed to remove: the local infrastructure keeps running the business, and it synchronises with the cloud when connectivity allows. This is the "data needs to traverse, not simply transmit" case: it is generated locally, used locally in real time, and only needs to reach a central system on its own schedule, not continuously. A twelve-site retail chain and a single flagship store are not the same infrastructure decision, even if every other variable looks identical on paper.

Azure Local: the clearest example of hybrid done properly

Azure Local, Microsoft's rebrand of Azure Stack HCI, is the most concrete illustration of what a genuinely hybrid platform looks like rather than a marketing label attached to two unrelated products. It runs virtualised and, increasingly, containerised workloads on hardware the business owns, ranging from a single node at a remote edge site to multi-rack deployments running hundreds of servers, while being managed through the same Azure portal, billing, and governance tooling used for the public cloud. Microsoft now positions it explicitly as a private and sovereign cloud platform rather than simply an on-premise virtualisation product, and it supports genuinely disconnected operation, not just intermittent connectivity, which matters directly for the multi-site case above.

The 2026 addition that changes the calculation for AI specifically is GPU support extending from professional-grade NVIDIA RTX cards through to the Blackwell Server Edition, which means AI inference, not just training, can run locally against a business's own data rather than being sent to a cloud region by default. Combined with Arc, which extends Azure's management plane to non-Microsoft infrastructure as well, this is the practical shape of hybrid: one control plane, workloads placed where the data and the latency requirement actually sit.

The detail worth knowing before scoping a project is what actually runs on top of the platform. Kubernetes workloads run through AKS enabled by Arc, so a containerised application built for the public cloud does not need re-architecting to run at the edge. Arc-enabled data services extend SQL Server and other data platforms with the same patching, backup, and security baseline used in Azure, which matters directly for the sensor and machine-data case: the database sitting next to the factory floor gets the same governance as the one in the cloud region, rather than becoming the unmanaged exception that eventually causes an audit finding.

Sovereign AI: the newest driver, and it is not just a government concern

Data sovereignty used to be a compliance checkbox for a narrow set of regulated industries. It is becoming a broader strategic question, driven by national AI ambitions rather than only data protection law. Singapore has invested directly in this: its National Multimodal Large Language Model Programme has produced SEA-LION and MERaLiON, sovereign language models built for Southeast Asian languages and context under the National AI Strategy 2.0, with the Monetary Authority of Singapore among the organisations already using them in production. That is a government building its own AI capability specifically so the country, and the businesses operating in it, are not entirely dependent on foreign-hosted models for sensitive workloads.

Malaysia's move is more direct still. Budget 2026 allocated RM2 billion to a government-controlled sovereign AI cloud, coordinated through the Malaysian Communications and Multimedia Commission and the National AI Office, explicitly to keep national data and compute within Malaysian borders. The practical knock-on effect is already visible: data centre applications unrelated to that push have been paused, and state-level environmental reviews are now rejecting roughly 30% of new proposals as scrutiny tightens. A private business is not directly bound by a national sovereign AI cloud, but a business planning to lease data centre capacity, or relying on a vendor who does, is operating in a market where the ground rules are visibly shifting toward keeping data and inference in-country.

Elsewhere in ASEAN, the requirement is already explicit rather than directional. Indonesia's Government Regulation 71/2019 imposes data localisation and electronic systems governance requirements on businesses handling certain categories of data, and Vietnam's Decree 53/2022 requires international companies to store specified data locally and establish a local branch or representative office. A business operating across all four markets is, in effect, already managing a patchwork of sovereignty rules rather than one uniform cloud strategy, whether or not it has framed the decision that way yet.

None of this creates a blanket legal obligation for most private businesses in Singapore or Malaysia today. It is, however, a clear enough direction of travel that treating data residency as a live planning question, not a hypothetical one, is the more defensible position going into 2027 and beyond. Financial services and other MAS-regulated entities already have a more concrete version of this obligation; see the governance section of the AI Agents vs Chatbots guide for what that looks like in practice.

The hybrid vendor landscape, and the lock-in that actually matters

Every major infrastructure vendor now offers some version of hybrid, and they are not interchangeable in how much genuine portability they provide.

The lock-in worth worrying about is rarely the one buyers focus on first. Committing to a hardware or hypervisor ecosystem, what might be called brand lock-in, is largely unavoidable at scale and not especially different from decisions businesses have always made about their primary vendor. The lock-in that creates real switching cost is data gravity: the accumulated cost and operational risk of moving large volumes of data, and everything built to process it, out of wherever it currently lives. A platform that makes it cheap and straightforward to move workloads is solving brand lock-in. Data egress fees, proprietary data formats, and the sheer volume of data that would need to move are what actually make an exit expensive, regardless of which vendor's logo is on the hardware.

Containerisation is the one architectural choice that meaningfully reduces this risk regardless of which platform in the table above is selected. A workload packaged to run on Kubernetes, rather than built around one vendor's proprietary virtual machine format, can move between Azure Local, Google Distributed Cloud, and the public cloud with materially less rework. It does not eliminate data gravity, moving the data itself is still the hard part, but it keeps the compute layer genuinely portable, which is the part of the stack a vendor has the least legitimate claim to lock down.

When cloud still wins outright

None of the above is an argument for defaulting to on-premise or hybrid. For a genuinely large share of ASEAN SMEs, public cloud remains the simpler and cheaper choice, and it is worth being equally direct about when that is true.

• Single-site operations with reliable connectivity. If the business runs from one location with a stable internet connection and no regulatory driver for data residency, the operational overhead of running any infrastructure locally rarely pays for itself.
• No dedicated infrastructure capacity. Hybrid and on-premise platforms still need someone to patch, monitor and maintain them. A business without that capacity, or the budget to outsource it properly, will get worse reliability from owned infrastructure than from a well-run cloud tenancy, not better.
• Genuinely variable or spiky demand. Workloads with unpredictable peaks, seasonal retail traffic, a marketing campaign, an annual reporting cycle, are what cloud elasticity was built for. Owning capacity for the peak and leaving it idle the rest of the year is the classic case where cloud's pay-for-what-you-use model wins cleanly.
• Early-stage and fast-changing environments. A business still finding its product-market fit, or restructuring its systems every few months, benefits from the cloud's low commitment more than it needs the control that on-premise infrastructure provides.
• Knowledge work with no sensor or plant data at all. A professional services firm, an agency, or most fintech and software businesses have no equivalent of a factory floor or a remote site generating physical telemetry. For this profile, the entire premise of this guide simply does not apply, and the cloud-first default remains the right one without qualification.

A simple decision framework before committing either way

• Map where your data is actually generated, and how much of it there is. A rough sensor or transaction volume estimate, done before any vendor conversation, tells you more than any product brochure.
• Separate real-time control decisions from analytics. If a decision needs a response in milliseconds, it needs to happen close to the data. If it can wait minutes or hours, the cloud's latency is irrelevant.
• Check your actual regulatory and sovereignty exposure, not the assumed version. Confirm what, if anything, your industry or your clients' due diligence genuinely requires, rather than guessing.
• Run the realistic five-year cost, including people. Hardware and subscription costs are the easy part to compare. The harder, more honest number is the operational capacity required to run infrastructure locally, whatever platform you choose.
• Pilot on the one site or workload where the case is clearest. Hybrid architecture proves itself fastest where the sensor volume, connectivity problem, or sovereignty requirement is most obvious, not rolled out everywhere on the strength of an average case.

For the broader technology planning discipline this decision sits inside, see Where to Start When Everything Feels Urgent and the compliance dimension covered in the M365 licensing guide.

Frequently Asked Questions

Is cloud repatriation actually happening, or is it overstated?

Both things are true at once. Barclays' CIO survey found 86% of CIOs planning to move some workloads back to on-premise or private cloud, which sounds dramatic until IDC's data shows only around 8 to 9% of companies are planning full repatriation. Gartner still expects public cloud spending to grow over 20% in 2025 alone. The accurate read is that repatriation is selective and workload-specific, not a retreat from cloud, and Gartner's own forecast is that roughly 90% of organisations will run multi-cloud or hybrid architectures by 2027, which is the trend that actually matters for most businesses.

When does keeping infrastructure on-premise or hybrid still make sense in 2026?

Two conditions consistently make the case: sensor or machine data generated continuously in large volumes, where sending everything to the cloud unprocessed is expensive and often unnecessary, and distributed operations across multiple sites with unreliable or costly connectivity, where a site needs to keep running even when its link to the internet does not. Regulated data with a genuine sovereignty requirement is a third, growing driver. Outside of those conditions, and without dedicated infrastructure staff, cloud is usually still the simpler and cheaper default.

What is Azure Local and how is it different from a traditional on-premise server?

Azure Local, formerly Azure Stack HCI, is Microsoft's hyperconverged infrastructure platform for running virtualised and containerised workloads on hardware you own, while managing it through the same Azure portal, billing and governance used for the public cloud. Unlike a traditional standalone server, it supports disconnected and intermittently connected operation, scales from a single edge node to multi-rack deployments, and as of 2026 supports NVIDIA GPUs up to the Blackwell Server Edition, enabling AI inference to run locally rather than only in the cloud.

Do Singapore or Malaysia businesses need to worry about data sovereignty for AI?

Directly, only a minority of businesses face an explicit legal requirement to keep AI data and processing in-country today. Indirectly, the direction of travel is unmistakable. Singapore has invested in its own sovereign large language models, SEA-LION and MERaLiON, under its National AI Strategy 2.0, with the Monetary Authority of Singapore among the organisations already using them. Malaysia allocated RM2 billion in Budget 2026 to a government-controlled sovereign AI cloud and has already tightened approvals for data centres unrelated to that push. Neither move creates a blanket obligation for private businesses yet, but both are reasons to treat data residency as a live planning question rather than a hypothetical one.

Related Guides

• Cloud-Managed Networking for ASEAN Businesses: The five-year TCO reality and the vendor lock-in that actually matters.
• The IT Due Diligence Checklist: What Buyers Actually Look At: What buyers actually check in a technology due diligence review before signing.
• Building a Technology Roadmap Without a Full-Time Tech Leader: Prioritising technology decisions with a risk register, without a full-time tech leader.