How exposed are you to cloud dependency? A multicloud assessment for IT leaders

What this assessment helps you evaluate

Key takeaway: This assessment estimates how much exposure you carry. The output is a short read on which parts of your stack would resist a change you might need to make. The score is for an internal conversation that surfaces specific decisions.

This is a worksheet that estimates how much of your current cloud setup would resist a change you might actually need to make: a new region for a regulated customer, a migration to settle a price negotiation, or a restoration onto an alternative provider after an outage. 

The output is a short exposure read you can take to a working session. Reducing this kind of lock-in has also become a regulatory priority: the EU Data Act now requires cloud providers to remove barriers to switching between services, and the international standard ISO/IEC 19941 defines, vendor-neutrally, how cloud portability and interoperability should work.

The four areas of multicloud exposure

Cloud dependency tends to concentrate in four places. Score each area on its own; combined scoring obscures where the actual exposure lives.

1. Provider dependency. How tightly is your application tied to one provider's services, identity model, or proprietary primitives?
2. Migration friction. How long would a planned move to another supported provider actually take? Hours, days, weeks, or unclear?
3. Workflow inconsistency. Do your teams use the same delivery workflow across providers, or do they branch by cloud?
4. Governance gaps. Are your audit controls, secrets, and access rules portable across providers, or do they live per console?

Score your current state

For each area, give yourself a score from 0 to 3.

• 0 Strong: portable, documented, evidence available on demand.
• 1 Partial: portable in principle, but slow or under-documented.
• 2 Weak: significant work is required to change anything; tribal knowledge is involved.
• 3 Exposed: change is blocked by structural decisions you cannot quickly undo.

Use these prompts to assign each score:

1. Vendor lock-in: If you had to choose another provider tomorrow, what percentage of your stack would need rebuilding?
2. Migration friction: From scratch, how quickly could you transfer your data and workload to a different cloud provider?
3. Workflow inconsistency: Do your teams use the same deployment steps and tooling on every provider, or does the process change depending on which cloud they're targeting?
4. Governance gaps: Can you produce audit evidence for one workload across multiple providers in a single query?

A combined score of 0 to 4 is healthy. 5 to 8 means there is real exposure worth working on. 9 to 12 means dependency has shaped your operating model.

Book a multicloud assessment review 

What high-risk patterns look like

Three patterns are reliable signals of high exposure:

• One CI/CD pipeline per cloud for the same workload. Even if it works today, this doubles your operational surface and guarantees drift.
• Audit evidence was reconstructed manually from multiple consoles. Time-to-evidence is a reliable proxy for governance debt.
• A platform team divided by provider expertise. When the team is split by cloud, the workload is too.

If any one of these is present and persistent, you are scoring 2 or 3 in at least one area. If two are present, the exposure compounds.

What improvement usually looks like

Improvement moves are smaller than people expect. Three changes account for most of the reduction in exposure:

• One application definition, committed to Git, that targets any supported provider without rewrite. This is the foundation; without it, the other moves do less work.
• Policy declared as code, applied at the platform layer. Governance stays the same across clouds, so audit cycles shrink.
• One delivery workflow across teams. Developers do not learn a new pipeline when the deployment target changes.

Upsun is built to this model and supports AWS, Azure, Google Cloud, IBM Cloud, and OVHcloud from a single platform.

What to review next internally

Take your two highest-scoring areas to a 30-minute working session with the team that owns the workload. Ask three questions: what decision made this exposure permanent? What would change need to look like? What is the cost of leaving it as-is for another twelve months?

The answers are usually clear within the session. The hard part is choosing whether to act.

Read the Migration playbook: escaping lock-in without disruption 

Frequently asked questions (FAQs)

What is cloud dependency?

Cloud dependency is the degree to which your applications, operations, and governance are tied to a specific cloud provider. It shows up as services that cannot easily move, workflows that only work on one cloud, and audit evidence that only one console can produce. The higher the dependency, the slower and more expensive any change becomes.

How do you measure exposure to vendor lock-in?

Exposure is measurable across four areas: provider dependency (how tightly the application is tied to one provider's services), migration friction (how long a planned move would take), workflow inconsistency (whether teams use the same workflow across clouds), and governance gaps (whether controls are portable). Score each area on a 0-to-3 scale to see where the exposure concentrates.

What are the signs of high cloud exposure?

Three signs reliably indicate high exposure: maintaining one CI/CD pipeline per cloud for the same workload, reconstructing audit evidence manually from multiple consoles, and a platform team divided by provider expertise. Anyone is a problem worth fixing. Two together compound the exposure faster than any single architectural decision.

Can you reduce cloud dependency without migrating providers?

Yes. Most of the reduction in cloud dependency comes from changes at the delivery layer. One portable application definition, policy declared as code, and a single delivery workflow reduce dependency without requiring a migration. Provider choice becomes a downstream decision once the delivery layer is consolidated.

How do you reduce multicloud exposure in practice?

Three changes account for most of the reduction in multicloud exposure: one portable application definition committed to Git, policy declared as code applied at the platform layer, and a single delivery workflow regardless of target cloud. The first change is the foundation; without it, the others do less work.