The first cloud migration was the easy one. Pick a hyperscaler, lift-and-shift, watch the on-premises rack go quiet. Three years in, the bill is different, the workloads are everywhere, and the egress fee for moving anything back out reads like a hostage note. Cloud vendor lock-in in Malaysia rarely shows up on a procurement scorecard. It shows up at the renewal cycle, when the negotiating advantage has already shifted. This is how to design cloud vendor lock-in solutions that actually work in practice.
What Is Cloud Vendor Lock-In?
Cloud vendor lock-in is the situation where moving workloads from one cloud provider to another becomes too expensive, too disruptive, or too technically complex to be a real option. It rarely happens by accident. Proprietary services, data formats, and pricing structures accumulate over years until the cost of leaving outweighs the cost of staying, even when staying is the wrong long-term choice.
What Vendor Lock-In Looks Like in Practice
The scenarios below show what cloud vendor lock-in can look like:
- The renewal-cycle shock. After a few months or years of a hyperscaler contract, committed-use discounts roll off, and suddenly the renewal quote lands 30 to 40% higher than expected. The architecture team has no room to negotiate.
- The regulator-driven decision. Bank Negara updates RMiT cloud expectations. A financial institution running on a single overseas hyperscaler needs sovereign hosting for parts of its estate.
- The acquisition surprise. A retail group acquires a competitor running on a different cloud. Two payment integrations, two identity systems, two billing tools. The six-week integration plan becomes an 18-month programme.
The Five Forms of Cloud Vendor Lock-In
Lock-in has five overlapping forms. Each one carries a different exit cost.
- Data gravity. Years of accumulated data sit in proprietary object storage. Moving it costs egress fees, time, and engineering effort.
- Proprietary APIs. Managed services from one provider rarely have one-to-one equivalents at another.
- Egress fees.SpendArk’s 2026 benchmark puts data transfer at 15 to 25% of the average cloud bill, with media and AI workloads at the higher end.
- Identity and IAM. Roles, policies, and federation patterns tie users and services to one provider’s permission model.
- Skill specialisation. Teams who have spent five years on one platform have shortcuts, scripts, and runbooks that all assume that platform. Reskilling carries real cost.
How to Audit Your Lock-In Exposure
Before drafting an exit plan, audit the dependency surface.
- Service inventory. Every managed service in use, mapped to whether it has a portable equivalent or is genuinely proprietary.
- Data residency map. Where each dataset lives, its size in TB, and the cost to move it at current egress rates.
- Identity dependency map. Federation, machine identities, and policy structures, with notes on which patterns are reusable across clouds.
Create a heat map of high, medium, and low lock-in surfaces.
In our experience auditing Malaysian mid-market enterprises, around 2/3 (66.6%) of workloads are typically portable, while roughly 1/3 (33.3%) tend to remain tied to a specific cloud provider. The least portable components are usually managed databases and serverless functions that have become business critical over time. Industry guidance from AWS, Google Cloud and Gartner similarly identifies managed databases, serverless services and proprietary cloud-native capabilities as the primary sources of vendor lock-in. The extent of these dependencies often determines whether a phased migration or a full replatforming effort is the most appropriate exit strategy.
The Four-Stage Hybrid Cloud Exit Playbook
- Containerise. Move stateless workloads into containers running on Kubernetes. Once a workload runs in a container with a defined manifest, the underlying cloud becomes a deployment target rather than a dependency.
- Portable infrastructure-as-code. Replace cloud-specific templates (CloudFormation, ARM) with Terraform or Crossplane modules that abstract the provider. The code lives in Git. Recreating the environment elsewhere becomes a CI/CD job, not a project.
- Cross-cloud data plane. Pick storage and database layers that run consistently across clouds (Postgres, ClickHouse, MinIO, MongoDB Atlas). Set up replication so production data is no longer pinned to one provider.
- Cross-region failover. Once the first three stages are in place, run live traffic across more than one cloud or region. This is the point at which lock-in stops being a contract problem and becomes an operational choice.
Each stage takes one to two quarters for a mid-sized enterprise. None requires a full freeze on business-as-usual development.
Cost Modelling: What Re-Platforming Actually Costs
Three cost lines determine whether the exit is worth running this year or next.
Egress and migration cost
Calculate at current rates and forecast under any committed-use discount. The 2024 free-egress announcements from AWS, Azure, and Google Cloud cover provider-to-internet transfer for customers leaving the platform, in response to the EU Data Act. Cross-AZ traffic and NAT Gateway processing charges remain in place, and those line items often dominate the bill for distributed architectures.
Re-architecture cost
Developer hours, testing cycles, and parallel-run overheads. Containerisation cost varies widely with application complexity. Budget for a structured per-engagement estimate before committing.
Recurring savings or premium
A different cloud, sovereign provider, or hybrid model often costs less per unit, after the re-architecture is paid down. Break-even depends on the size of the original cloud bill and how much of it was egress.
Escaping Vendor Lock-In With Net Onboard’s AmplifyChoice
AmplifyChoice is Net Onboard’s cloud architecture solution. The remit is to match each workload to the right platform and design portability from the start, so the next renegotiation, the next regulation, or the next outage does not turn into a re-platform project.
Over more than 20 years, Net Onboard has delivered hybrid cloud solutions for Malaysian organisations, helping them save both time and cost:
- 121Advisor. CEO Thiagarajah P. Suppiah’s fintech advisory platform accelerated innovation on a responsive multi-cloud strategy, delivering 2x faster innovation cycles and better customer experiences. Portability across providers means new features ship on the product team’s cadence.
- Awfatech. CEO Razali B. Ahmad’s edtech platform expanded digital learning access on AmplifyCloud, empowering more than 10,000 students and schools while platform scalability held through demand peaks.
- Pathlab. Regional IT Manager Tan T. H.’s nationwide diagnostics network runs on hybrid cloud infrastructure delivering 99% service reliability, with the uptime and continuity needed for a clinical operation that cannot afford regional incidents.
None of these were fire drills. The architecture choices were made before the lock-in surface became expensive, which is the difference between an AmplifyChoice engagement and an emergency repatriation.
Designing a Cloud Exit That Works
A hybrid cloud exit needs more than a containerisation push and a Terraform repo. It needs sequencing, a defensible business case, and the operational muscle to keep production running while the platform changes underneath it.
If you are renegotiating a cloud committed-use agreement or modelling a multi-cloud failover after a recent outage, the answer is rarely about which hyperscaler to pick next.
Cue Net Onboard, where our end-to-end managed cloud experts run the audit, the playbook, and the operational handover for your businesses.
Talk to our team about our cloud vendor lock-in solutions today.