Exit Strategy (Lock-in as a Design Input)

The idea

Every dependency on a vendor, cloud or platform has a switching cost, and that cost grows with use: more data, more integrations, more custom configuration, more people who only know that product. The cheapest moment to plan your exit is before you sign.

An exit strategy answers, in advance: what would make us leave, what we would move, where to, how long it would take and what it would cost. It does not mean avoiding lock-in. Gregor Hohpe argues that lock-in comes in many forms, vendor, product, version, architecture, platform, skills, legal and even mental, and that avoiding one often creates another. His point is to weigh the switching cost against the unique utility the dependency gives you. High lock-in for high value can be a good deal; high lock-in for little value is the case to worry about.

For regulated EU financial entities this is not optional. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies from 17 January 2025. Its Article 28(8) requires exit strategies for ICT services supporting critical or important functions, with exit plans that are documented, sufficiently tested and reviewed periodically, and transition plans to move the services and data to another provider or back in-house.

Why it works

Switching cost is set early and paid late. Choices made in the first month, proprietary data formats, platform-specific APIs, contracts without exit assistance, decide what leaving costs years later.

Naming the exit exposes hidden lock-in. Writing the plan forces you to list data, integrations, skills and contract terms, which surfaces dependencies nobody chose deliberately.

Reducing lock-in has a price. Hohpe compares it to an option's strike price: abstraction layers, multi-cloud and avoiding native features all cost money and complexity. Planning the exit lets you buy only as much portability as the risk justifies.

Where it applies

• Vendor and cloud selection, where the exit plan belongs in the evaluation, not after the contract.
• Sourcing strategy and contract negotiation, covering data return, exit assistance and transition periods.
• Regulatory compliance, notably DORA's third-party risk requirements for critical or important functions.
• Portfolio and roadmap reviews, to spot dependencies whose switching cost has grown beyond their value.

How to apply

1. Classify the dependency. Is it supporting a critical function? How likely is a switch, and how costly would it be?
2. Weigh utility against switching cost. Accept lock-in where the value is unique and high; be wary where it is not.
3. Write a short exit plan. List triggers, target alternatives, data and integration moves, contract terms, and a rough time and cost.
4. Buy cheap insurance. Prefer low-cost measures, open data formats, contractual exit assistance, clean interfaces, over expensive full abstraction.
5. Test and revisit. Rehearse the riskiest step, such as a full data export, and review the plan as usage grows.

Example scenario

A payments firm chose a SaaS fraud-detection service for its card business, a critical function. The original business case covered features and price but said nothing about leaving.

Preparing for DORA, the enterprise architects wrote the exit plan: monthly full exports of rules and case history in an open format, an internal API facade so channels never called the vendor directly, and a contract clause for twelve months of exit assistance. They rehearsed the export once a year. The lock-in remained, because the vendor's models were the reason to buy, but leaving became a known project rather than an emergency.

Questions to ask

When not to use it

• Disposable, low-value dependencies that are cheap to replace; a detailed exit plan costs more than the switch.
• Deep commitments made deliberately for strategic value, where the plan should be proportionate, not an excuse to avoid using the platform properly.

How it misleads you