Cloud Lock-in Hub
Build your cloud lock-in strategy. Before dependency decides for you.
Track and measure your provider dependency, understand how it evolves and identify what prevents each workload from moving. Lock-in Hub helps your team plan and prepare for cloud repatriation, multicloud adoption or a provider change.
Read-only assessment Migration planning Workload-level evidence
Lock-in Hub · Illustrative assessment Cloud2Gether
Workload assessment payments-platform
Analysis ready
Lock-in Score
68 28
High dependency Healthy
Managed database High replacement effort High Resolved
Serverless runtime Provider-specific APIs High Resolved
Data gravity 4.2 TB to evaluate Medium
Container layer Portable foundation Low
12 dependency signals 3 migration paths 2 target clouds
Supporting your cloud strategy
Make cloud decisions with dependency in view
Evaluate the level of lock-in across your workloads before choosing a multicloud, migration or cost strategy. Understand where provider-specific services create value and where they limit your options.
Freedom to move and optimize
Be ready to move, optimize or stay by choice
Know what it would take to repatriate or change providers. Lock-in Hub combines three complementary assessment frameworks to measure provider dependency and estimate migration effort, including engineering hours, data movement, proprietary services that need replacement and required architecture changes.
How dependent is each workload?
Which services and data create dependency?
How is lock-in changing over time?
How many engineering hours could migration require?
Which AI-recommended actions should the team review?
Migration effort
Understand what moving to another provider could require
Estimate the engineering hours needed to migrate a workload and see which dependencies contribute most to the result. Lock-in Hub then turns those findings into a recommended sequence for team review.
Lock-in Hub · Migration effort Cloud2Gether
Estimated engineering effort 420 to 560h Planning range
Critical blockers 2 Require planning
AI migration plan Ready For team review
Primary effort drivers 2 blockers identified
High · Database layer Aurora PostgreSQL
4.2 TB and a managed-service replacement.
Medium · Event model Lambda + SQS
Provider-specific integrations require adaptation.
Recommended sequence
01 Evaluate database 02 Isolate event model 03 Retain containers
Lock-in Hub · Consensus assessment
Measure lock-in with a broader view of dependency
The Lock-in Score combines a consensus of three complementary frameworks to assess service portability, proprietary technology, data lock-in and migration complexity.
Proprietary service dependency
Identify services and architecture patterns that are difficult to replace.
Data portability
Evaluate data gravity, movement requirements and provider-specific formats.
Migration complexity
Connect technical dependency to the effort required to move each workload.
Lock-in Hub · Workload analysis Cloud2Gether
ServiceDependencyPortabilityScore
Aurora PostgreSQL Managed database high Low 82
AWS Lambda Runtime + event model high Low 76
Amazon SQS Messaging medium Medium 58
Amazon ECS Container workload low High 24
Amazon S3 Object storage medium Medium 46
Lock-in Hub · Historical comparison Cloud2Gether
Jan 14, 2026 Baseline
68 High dependency
2 critical findings −40 score points
Sep 29, 2026 Latest
28 Healthy
0 critical findings Managed database Replacement path approved Resolved
Serverless runtime Provider-specific APIs isolated Resolved
Container layer Portable foundation retained Retained
Dependency reduced through targeted actions Saved assessments show which architecture decisions changed the result.
Lock-in Hub · Progress over time
Track lock-in and actions over time
Understand how the score, migration effort and recommended actions evolve as your team reduces avoidable dependency.
Save every assessment and select any two executions to see how the score, dependency drivers and portability changed as workloads evolved.
Progress evidence
Compare two moments without relying on manual reports.
Investment visibility
Connect architecture and DevOps work to measurable dependency reduction.
Action tracking
See how completed recommendations affect portability and migration effort.
Vendor lock-in FAQ
Cloud portability, without the myths
Clear answers about dependency, repatriation, historical assessments and migration effort.
What is vendor lock-in in cloud computing?
Cloud vendor lock-in is the operational, technical or financial dependency that makes a workload harder to move away from a provider. It can come from proprietary managed services, data gravity, architecture choices, contracts, skills or migration cost.
What is cloud repatriation?
Cloud repatriation is the selective movement of a workload or data from public cloud to private cloud, colocation or on-premises infrastructure. It is not necessarily a full exit from cloud; the goal is to place each workload where cost, control, performance and risk make the most sense.
Is all cloud vendor lock-in bad?
No. Provider-specific services can improve speed, reliability and developer productivity. The risk appears when the dependency is invisible or no longer justified. Lock-in Hub helps teams measure that tradeoff before deciding to retain, modernize or migrate a workload.
How is the Lock-in Score calculated?
Cloud2Gether combines three complementary assessment frameworks into a consensus model. The score evaluates provider-specific services, portability, replacement complexity, data lock-in and migration effort to show where dependency is concentrated and which factors contribute most to the result.
Does CNCF recommend a percentage of vendor lock-in?
No. CNCF promotes portability and minimal avoidable vendor lock-in, but it does not prescribe one universal percentage. Cloud2Gether therefore evaluates dependency by workload and business context instead of treating zero lock-in as the correct target for every architecture.
Can I compare Lock-in Score assessments over time?
Yes. Lock-in Hub saves assessments so teams can select two executions and see how the score, dependency drivers and portability changed as the workload evolved.
Does Lock-in Hub migrate workloads automatically?
No. Cloud2Gether uses read-only access. It assesses the environment and recommends actions, but your team reviews the plan and executes any change in the cloud provider or delivery workflow.
What does migration effort include?
Migration effort considers services that require replacement, architecture changes, data movement and the complexity of each step. Lock-in Hub translates those signals into estimated engineering hours and an AI-assisted migration plan for team review. The estimate is a planning range, not a guaranteed delivery date.
Which cloud providers can be evaluated?
Cloud2Gether supports connected environments across AWS, Microsoft Azure, Google Cloud, Alibaba Cloud, Oracle Cloud and Akamai. Available comparisons depend on the services and workload being assessed.
Cloud Lock-in Hub
Understand your dependency.
Keep your options open.
Measure lock-in, estimate migration effort and create an action plan before a change becomes urgent.
Read-only access · Recommendations require team review