The New "Poison Pill": Architectural Lock-In
For the last decade, "cloud-native" was the gold standard in due diligence. It implied scalability, modernity, and lower CapEx. In 2026, however, sophisticated acquirers are realizing that "cloud-native" often really means "AWS-dependent" or "Azure-locked." We are seeing a shift where architectural dependency operates as a de facto poison pill for strategic exits.
The Three Tiers of Dependency
Not all cloud usage is lock-in. In our technical due diligence practice, we classify target companies into three tiers of portability risk:
- Tier 1: Infrastructure Lock-In (Low Risk). The target uses EC2, S3, or standard VMs. Migration is a matter of configuration, not code. The "switching cost" is primarily operational downtime, not engineering refactoring.
- Tier 2: Service Lock-In (Medium Risk). The target relies on managed services like RDS, ElastiCache, or standard Kubernetes implementations. While these have proprietary wrappers, the underlying engines (PostgreSQL, Redis) are open standards. Migration requires data piping, but not a code rewrite.
- Tier 3: Logic Lock-In (High Risk). This is the valuation killer. The target has built business logic directly into proprietary platforms like AWS Lambda, Google Cloud Spanner, or Azure Durable Functions. The application code cannot run elsewhere without a total rewrite.
Our data shows that Tier 3 companies trade at a 15-20% discount when the acquirer operates a competing cloud ecosystem (e.g., a Microsoft-backed strategic acquiring an AWS-native firm). The cost of "re-platforming" is deducted directly from enterprise value.
The 2027 Regulatory Cliff: From Contractual to Technical Moats
Historically, vendor lock-in was legal and contractual. You were locked in because you signed a 3-year enterprise discount plan (EDP) with a massive commit. The EU Data Act, fully enforceable by January 2027, effectively bans switching charges for cloud providers, theoretically lowering the barrier to exit.
However, cloud providers are smart. As contractual moats dissolve, they are doubling down on technical moats. They are incentivizing your engineering teams to use proprietary APIs—like specialized AI inference endpoints (Bedrock, Vertex AI) or proprietary database features—that make leaving technically impossible, even if it is legally free.
The AI "Double Lock"
The rise of Generative AI has exacerbated this risk. A SaaS company building on OpenAI’s API is effectively locking itself into Azure’s infrastructure. A company building on Google’s Vertex AI cannot easily port that logic to AWS. In 2026 due diligence, we are finding that 40% of "AI features" in portfolio companies are hard-wired to a specific vendor's model, creating a "double lock" of both infrastructure and intelligence.
The 5-Day Portability Diagnostic
You do not need a 6-week code audit to assess lock-in risk. You can gauge the severity of the problem during the 5-day exclusivity window by asking the right technical questions.
1. The "Import" Test
Scan the codebase for vendor-specific SDK imports. If `boto3` (AWS SDK) appears in 80% of the backend files, the business logic is coupled with the infrastructure. A healthy "portable" architecture abstracts these calls behind an interface.
2. The Data Gravity Check
Ask for the monthly bill breakdown. If >30% of the spend is on "Egress" or proprietary data warehousing (e.g., Snowflake, BigQuery), the data gravity is likely too high to move economically. Moving 5PB of data out of a cloud provider often costs more than the first year of hosting elsewhere.
3. The "Serverless" Ratio
Calculate the percentage of compute spend on serverless functions (Lambda/Azure Functions) versus containers. If >50% of compute is serverless, the application is likely 100% non-portable. While efficient, this architecture requires a 30% engineering tax to refactor for a strategic exit.
Investors must stop treating cloud spend as a commodity and start auditing it as a liability. If your target cannot move, your exit options are cut in half.
