When a SaaS vendor reports high “net revenue retention,” the market assumes it’s because the software is indispensable. After 16 years as a HubSpot partner, we know the harder truth: retention is often just engineered captivity.
Having built the integrations and watched hundreds of companies try to untangle them, we’ve seen how platforms systematically raise the cost of leaving. Vendor lock-in isn’t a mistake — it’s a deliberate architectural strategy. Whether you use HubSpot, Salesforce, or Adobe, the trap relies on the same five mechanisms. We call them The Five Locks.
Why does vendor lock-in exist?
Lock-in exists because the SaaS revenue model depends on retention, not satisfaction. A customer who is happy but free to leave is less valuable than a customer who is frustrated but unable to leave. The economics are explicit: platforms inflate their retention metrics by making churn mechanically difficult, regardless of whether the product is earning the renewal.
This isn’t a conspiracy theory. It’s a business model. Watching platforms evolve from genuinely useful marketing tools into sprawling, increasingly expensive suites that make departure harder with every feature added, we’ve identified exactly how the architecture works.
The Five Locks framework names the five mechanisms. Once you see them, you can’t unsee them. And more importantly, you can start planning around them.
Lock 1: The Code Lock
What it is: Your website and marketing assets are built in a proprietary language that only works inside one platform.
HubSpot uses HubL. Salesforce uses Apex and Lightning. Adobe Experience Manager uses Sling/OSGi. Shopify uses Liquid. Every template, every module, every dynamic element on your site is written in a language that has zero portability.
When you leave, none of your code comes with you. Every page, every template, every custom module starts from zero. The years of development work your team invested? They’re not assets you own — they’re deposits in a vault you can’t access without the vendor’s key.
How deep does the Code Lock go?
The Code Lock isn’t just about templates. It extends to:
A company that runs a custom HubSpot website for five years typically has $150,000 to $350,000 of accumulated development embedded in proprietary HubL templates. That investment has a market value of exactly zero outside of HubSpot.
- Custom modules and components built in the vendor’s proprietary framework
- Theme architecture that encodes business logic into platform-specific patterns
- JavaScript integrations that depend on vendor-injected global objects and APIs
- CSS that references vendor-specific breakpoints, container elements, and layout systems
A company that runs a custom HubSpot website for five years typically has $150,000 to $350,000 of accumulated development embedded in proprietary HubL templates — spanning the initial build, custom modules, and years of iteration. That investment has a market value of exactly zero outside of HubSpot.
What breaks the Code Lock?
Building on open standards. When your infrastructure uses standard web technologies rather than proprietary templating languages, your code runs anywhere. You aren’t forced to hire from a small, expensive pool of vendor-certified specialists; you hire from the largest developer talent pool in the world. The code you write becomes an appreciating asset you own, not a sunk cost trapped in a vendor’s ecosystem.
Lock 2: The Data Lock
What it is: When you walk away from a SaaS platform, you often walk away from your own business history. Vast amounts of contextual data are deliberately excluded from exports and entirely unsupported by the vendor’s API.
Every SaaS CRM stores data in a proprietary schema designed for their application, not for your ownership. You can export a CSV of your contacts or companies. But the contextual data — the complete behavioral timelines, the granular engagement history, the attribution trails that prove which marketing efforts actually generated revenue — is frequently held hostage.
HubSpot’s standard exports give you flat, inconsistent or incomplete files. Even their API, which is supposed to be the escape hatch, has critical blind spots where specific types of historical data simply cannot be extracted. When your own customer data is structurally trapped inside a vendor’s walled garden, the lock-in is nearly absolute.
What does a complete data export actually look like?
Most vendors offer “export” features that provide a fraction of your data:
| What you think you’re exporting | What you actually get |
|---|---|
| Your CRM with all relationships | Flat CSV files — contacts, companies, deals as separate tables with no joins |
| Your email marketing history | Send logs and aggregate metrics, but not per-contact engagement timelines |
| Your website content | Raw HTML or text, stripped of layout, metadata, internal links, and SEO structure |
| Your automation rules | Nothing. Workflow logic doesn’t export. |
| Your audience segments | A static list of current members — not the dynamic criteria that define the segment |
What breaks the Data Lock?
Aggressive API extraction combined with a sobering realization: you will likely have to abandon some historical context. Instead of relying on a vendor’s standard export, a proper migration engineers a custom API extraction to reconstruct every possible relationship, activity, and deal association that the platform allows you to touch.
In a sovereign stack, your customer data lives in a warehouse you own, in standard formats that any business intelligence tool can read. The data is yours architecturally, not just contractually. You never have to ask a vendor for permission, or pay API overage fees just to access your own customer data.
Lock 3: The Logic Lock
What it is: Years of accumulated automation rules, lead scoring models, deal-stage triggers, and notification workflows, often undocumented and running without oversight.
This is the lock companies underestimate most. A company that’s been on HubSpot for 5+ years typically has hundreds of active workflows. Many were created by employees who have since left. Nobody has a complete map of what triggers what. The automations work, so nobody touches them. But nobody can explain exactly what they all do.
Why is the Logic Lock so dangerous?
Because it creates fear. The Logic Lock turns migration from a technical project into a psychological one. It introduces massive key-person risk, where your revenue operations depend entirely on employees who may have left years ago. The question isn’t “can we rebuild these workflows?”, it’s “do we even know what all the workflows do?” And the honest answer is usually no.
This fear is the vendor’s best retention tool. It doesn’t require any deliberate action on their part. It’s the natural consequence of making it easy to create automations and hard to document them.
What does undocumented logic actually cost?
We’ve audited hundreds of HubSpot portals. The pattern is consistent:
- 30-40% of active workflows are redundant or conflicting
- 15-20% reference properties, lists, or triggers that no longer exist
- 50%+ were created by someone who no longer works at the company
On top of that, most companies have a parallel set of workflows running in one or two integration platforms, with their own per-task pricing and their own layer of undocumented logic.
The Logic Lock doesn’t just prevent you from leaving, it degrades the quality of your operations while you stay.
What breaks the Logic Lock?
Before any code is touched, an utomation audit can reverse engineer every active workflow into a platform-agnostic specification. Which triggers fire? What conditions are evaluated? What actions result? What depends on what?
This audit typically reveals that a 200-workflow HubSpot portal can be rebuilt with 40-60 well-designed automations in a modern system. Years of accumulated logic drift can finally be cleared up and maintained moving forward on higher standards.
In a sovereign stack, automation logic is written in code or plain-language specifications, versioned in git, and auditable by anyone. Not buried inside a vendor UI where it’s invisible until it breaks.
Lock 4: The Audience Lock
What it is: Your marketing segments and audience lists are built on real-time behavioral criteria that only work inside the vendor’s ecosystem.
Like workflows, a typical HubSpot portal has hundreds or thousands of active lists, segmented by lifecycle stage, engagement score, content consumed, pages visited, emails opened, forms submitted. These segments power a company’s email marketing, ad targeting, personalization, and reporting.
The segments aren’t data, they’re queries. They’re real-time filters running against a vendor’s behavioral database. Export a list today and you’ll get a point-in-time snapshot that is stale by tomorrow.
Why can’t I just export my lists?
Because the value isn’t in who’s on the list right now. The value is in the criteria: “contacts who visited the pricing page in the last 30 days AND opened at least 2 emails AND have a deal in pipeline stage ‘evaluation.’” That logic lives inside the vendor’s system. It references the vendor’s behavioral data. It can’t be exported as a file.
What breaks the Audience Lock?
Document the criteria, not the members. Before migration, every dynamic segment is decomposed into its logical rules. Those rules are then rebuilt in the new system using first-party data that you own and behavioral events that flow into your own analytics infrastructure.
In a sovereign stack, audience segmentation runs against your own data warehouse. The behavioral events (page views, email opens, form submissions) flow into a system you control. The segments are queries you write, not features you rent.
Lock 5: The Dependency Lock
What it is: The vendor has successfully embedded their software across multiple departments, transforming a simple tool subscription into a deep organizational dependency. The perceived cost of migrating feels existential because the “all-in-one” platform has engineered a massive, cross-functional change-management hurdle. Not only is the technology replaceeable, there is far superior technology available outside the walled garden.
Marketing uses the CMS and email. Sales uses the CRM and pipeline. Service uses the ticketing and knowledge base. Operations uses the reporting and dashboards. Leadership uses the analytics for board decks. The IT team manages the integrations.
Every department has built their workflows around the platform. Every team has muscle memory for the interface. Every person has their own shortcuts, saved views, and mental models. At this level of entanglement, migrating away ceases to be an IT project. It becomes a company-wide organizational upheaval.
Why is the Dependency Lock the hardest to break?
The “all-in-one” pitch that looked like it was all about convenience, was actually about manufacturing dependency across the entire organization.
Because it’s not technical. It’s psychological and political. The Code Lock, Data Lock, Logic Lock, and Audience Lock are all solvable engineering problems with known timelines and costs. The Dependency Lock is a change management challenge.
The vendor benefits from this. Every new feature that touches another department deepens the dependency. Every integration that connects the platform to another system creates another reason not to leave. The “all-in-one” pitch that looked like it was all about convenience, was actually about manufacturing dependency across the entire organization.
What breaks the Dependency Lock?
A phased migration plan that moves departments sequentially, not simultaneously. Start with the area that has the weakest lock-in or the strongest pain. Prove the model works. Then expand.
In practice, this usually means starting with the website (Code Lock), because it’s the most visible win and the least politically entangled. CRM migration (Data Lock + Logic Lock) follows once the organization has experienced the alternative.
How to assess your lock-in
The Five Locks framework isn’t just descriptive. It’s diagnostic. For each lock, rate your organization:
| Lock | Low (1) | Medium (3) | High (5) |
|---|---|---|---|
| Code | Standard HTML/CSS, easily portable | Some proprietary templating, moderate rebuild needed | Fully proprietary language, total rebuild required |
| Data | Clean exports with relationships intact | Flat exports, some manual reconstruction needed | No usable export, API extraction required |
| Logic | Documented automations, fewer than 20 workflows | Partially documented, 20–100 workflows | Undocumented, 100+ workflows, tribal knowledge |
| Audience | Standard firmographic filters (industry, job title, company size) | Behavioral triggers mixed with CRM properties (e.g., pricing page views + lifecycle stage) | High-velocity behavioral scoring, custom event tracking, and cross-object dependencies |
| Dependency | Single department uses the platform | 2-3 departments, moderate cross-functional use | Organization-wide, every department has workflows |
A total score of 15-25 indicates significant lock-in. A score above 20 means migration requires a structured extraction plan — not a weekend project.
The escape is an engineering problem, not an existential one
Here’s what 16 years and 2,000+ projects taught us: every lock can be broken. The Code Lock is solved by rebuilding on open standards. The Data Lock is solved by API-level extraction. The Logic Lock is solved by automation auditing. The Audience Lock is solved by documenting criteria. The Dependency Lock is solved by phased migration.
The vendors want you to believe that leaving is impossible. It’s not. It’s an engineering project with a known scope, a known timeline, and a known cost. The Five Locks framework makes that project plannable.
The real question isn’t whether you can leave, it’s whether you can afford to stay. According to Retool (Feb 2026), 35% of enterprises have already started ripping out their legacy SaaS tools. For companies bleeding $50,000 to $200,000 a year in software licensing, the mathematical tipping point has arrived.
The vendors built the locks to make you feel trapped. Once you know how they work, they can all be broken.