• Contact us
  • Docs
  • Login
Watch a demoFree trial
Blog
Blog
BlogProductCase studiesNewsInsights
Blog

The cloud optionality blueprint: standardizing the stack to end vendor lock-in

clouddeveloper workflowplatform engineeringcloud application platformconfigurationmigration
30 April 2026
Share

Key takeaway: Real cloud strategy isn't about running the same workload everywhere at once; it’s about the freedom to move when you need to. By standardizing the unified configuration file, Upsun enables true cloud optionality, moving provider migration from a re-architect project to a data move project.

TL;DR: The exit strategy is the strategy

  • The risk: Every proprietary cloud service you adopt (like DynamoDB or SQS) is a clause in a contract that makes migration financially and operationally prohibitive.
  • The gap: Live multicloud is an expensive, complex distraction for most enterprises. It introduces a "Kubernetes tax" without solving the core problem of portability.
  • The solution: Upsun provides options for AWS, Azure, GCP, IBM Cloud, and OVHcloud, using a unified application spec to ensure your stack remains provider-agnostic.

Cloud providers don't want you to be portable

The “sticky cloud” is a business model. Cloud providers don't just sell compute; they sell ecosystems designed to be difficult to exit. Every time a team adopts a proprietary database, a specialized serverless runtime, or a provider-specific IAM policy, the cost of moving increases exponentially.

In 2026, the CTO’s biggest challenge isn't finding a cloud provider; it's maintaining leverage over the ones they already have. Without an exit strategy, you aren't a partner; you’re a tenant with no move-out rights.

Distinguishing live multicloud from cloud optionality

Key takeaway: Live multicloud is a technical burden; cloud optionality is a strategic asset. You don't need to run on two clouds at once; you need the ability to switch on terms you control.

The market has conflated two very different concepts.

  • Live multicloud: Actively running the same workload across multiple providers simultaneously. This is expensive, requires massive "glue" teams to manage differing runbooks, and often results in least common denominator architecture.
  • Cloud optionality: The ability to move your entire stack (applications, services, and data) to a different provider with minimal friction.

Upsun focuses on cloud optionality. We provide the standardization layer that allows you to treat the cloud as a commodity. By defining your application layer, service definitions, and deployment pipelines in a portable .upsun/config.yaml, you decouple your architecture from the provider's proprietary trap.

The unified configuration file: migration as a data move

Key takeaway: When the stack is standardized via a unified configuration file, the hard work of migration shifts from re-architecting to data synchronization.

On a traditional DIY stack, moving from AWS to GCP requires a multi-month audit. You have to map AWS-specific services to GCP equivalents, rewrite Terraform scripts, and re-train the team on new dashboarding and security protocols.

On Upsun, that effort has collapsed. Because the unified configuration file remains constant across providers:

  • Integrated services stay the same: Whether your MariaDB or Redis is an integrated service on AWS or OVHcloud via Upsun, the configuration is identical.
  • Standardized service versions: All services defined in your configuration haven't been modified in any way to keep you locked in. They are standard, open-source versions that you can migrate easily to another cloud or even on-premise.
  • Deployment pipelines stay the same: Your CI/CD doesn't care which underlying provider you use.
  • The developer experience stays the same: There is no "per-cloud" runbook divergence.

The project changes from a high-risk architectural overhaul to a predictable operational task: plan the data migration, test production-perfect clones in the target environment, and then synchronize data for a seamless transition.

Pragmatic simplicity over the "Kubernetes tax"

Key takeaway: True portability shouldn't require a dedicated team of 20 SREs. Upsun delivers Kubernetes outcomes without the complexity lock-in of manual orchestration.

Competitors often suggest that "bringing your own cloud" (BYOC) or managing your own Kubernetes clusters is the only way to avoid lock-in. 

This is the hidden Kubernetes tax. You trade provider lock-in for significantly more toil and a hidden tax on senior engineering capacity.

Upsun offers a different path:

  1. Standardized environments: We manage orchestration, scaling, and maintenance, removing most of the operational glue that typically slows teams down.
  2. Global reach: Upsun provides options for AWS, Azure, GCP, IBM Cloud, and OVHcloud in multiple regions.
  3. Cost governance: When you have cloud optionality, you can move workloads to a different provider to take advantage of better regional pricing or specific compliance requirements (like moving a project to OVHcloud for localized European data sovereignty).

Taking back control

Cloud optionality is about de-risking your business. It allows you to say "no" to price hikes and "yes" to better regional availability. By using Upsun to standardize your infrastructure, you ensure that your team stays focused on building features, not managing the divergent quirks of five different cloud consoles.

The cloud should be your engine, not your cage.

Frequently asked questions (FAQ)

Does Upsun support "Active-Active" multicloud deployments?

Upsun primarily focuses on cloud portability and optionality. While we enable you to deploy the same application stack to any major provider using identical workflows, our goal is to provide the portability needed to facilitate your own automated cross-cloud failover and disaster recovery strategies without the complexity of managing multiple proprietary stacks.

How does Upsun handle data migration during a provider switch?

Because Upsun manages your integrated services, we facilitate the export and import of data across providers using the same CLI tools you use for local development. Our production-perfect preview environments allow you to test the entire migrated stack before you flip the switch.

Can I move from a proprietary AWS service to a standardized one on Upsun?

Yes. We help teams decouple from proprietary sticky services (like AWS RDS or SQS) by moving them to integrated services, such as PostgreSQL, MariaDB, RabbitMQ, or Kafka, within the unified application spec. Because these services haven't been modified to keep customers locked in, your stack remains portable and ready to move to any other cloud provider, or even on-premise, without an architectural overhaul.

What is the "Kubernetes tax" you mention?

The "Kubernetes tax" refers to the massive amount of engineering time, salary, and mental overhead required to build and maintain a custom Kubernetes platform just to achieve portability. Upsun gives you those outcomes out of the box, without having to operate those systems directly.

Stay updated

Subscribe to our monthly newsletter for the latest updates and news.

Your greatest work
is just on the horizon

Free trial