Lock In Is Boring, Which Is Why It Works
Nobody is ever held to ransom by a cloud provider. There is no clause that stops you leaving and no switch they throw. What actually happens is far duller. Over three or four years you accumulate a few hundred small dependencies, each of them sensible at the time, and together they make leaving a project rather than a decision.
The bill for leaving is mostly engineering time. Rewriting the parts that used a platform specific service. Rebuilding the identity setup somewhere else. Moving data that has grown large enough that the transfer itself is a piece of work. Testing everything again, because you have changed every layer underneath the application at once.
Avoiding lock in altogether is a bad trade. Refusing the managed services that make the platform worth using costs you real money and real reliability today, in exchange for a move you will probably never make.
What is worth doing is knowing what leaving would cost, keeping that figure from growing by accident, and making sure the two or three genuinely painful hooks were chosen deliberately.
Your Data and the Format It Sits In
Start with data, because it is the part you cannot rewrite. Ordinary relational databases are the easy case: the data comes out in a standard form and goes into a comparable product elsewhere with a known amount of work. That amount is rarely zero, because applications use vendor specific features, but it is knowable.
The harder cases are the platform native stores. Document databases, key value stores, queues holding messages, data warehouses, search indexes. Each has an export path, and the question to ask is what the export actually produces. A dump in the platform's own format that only that platform can read is a backup, not a portable copy.
Size matters more than people expect. Data that would take a weekend to move when the system was new might take weeks once it has grown, and the transfer charges for pulling it out are a real cost that appears only once, in the month you least want it. Ask what the volume is now and what it is growing at.
There is also the shape nobody thinks about: the layout of your object storage. Buckets full of files with a naming convention that the application relies on are portable in theory and awkward in practice, because the rules live in code rather than in the store.
Identity Is the Deepest Hook
The identity directory is the hardest thing to leave, and it is usually the last thing anyone lists. Once your staff sign into everything through one directory, that directory holds the accounts, the groups, the sign in rules, the device policies, and the trust relationships with every application you have connected to it.
Applications get registered against it. Sign in flows are configured for it. Access to the platform itself is granted through it. Moving to another directory means touching every application, issuing every registration again, and coordinating a change that affects every member of staff on the same morning.
That does not mean the arrangement is wrong. A single directory is genuinely better than four, and consolidating identity is usually the highest value thing a small business can do for its security. It means you should know that this is your deepest dependency and treat it accordingly.
The practical mitigation is to use standard protocols wherever the choice exists, keep a current record of every application connected to the directory and how it authenticates, and avoid building your own systems against directory features that have no equivalent anywhere else.
Managed Services With No Equivalent Elsewhere
Every platform has services that exist nowhere else in the same shape. A function service with its own event format. A workflow engine that stores the definition in a proprietary form. A managed message queue with particular delivery semantics your code has come to rely on. A hosted model or document processing service you now call from three applications.
These are not traps. They are frequently the best available answer, and refusing all of them on principle means writing and operating the same thing yourself, badly. The mistake is using them without noticing, and then discovering during an exit assessment that they are woven through everything.
Sort them into two piles. In the first go the ones that touch a small, contained part of your system: a scheduled function, a notification service, a storage tier. Replacing those is measured in days. In the second go the ones your architecture is built around: the event backbone, the data warehouse, the identity service. Replacing those is measured in quarters.
Keep the second pile short and deliberate. Every item on it should be there because somebody decided the benefit was worth the coupling, and that decision should be written down where the next architect can read it.
What the Contract Actually Says About Leaving
Read the commercial terms with the exit in mind, because they are written for a customer who is staying. The items worth checking are unglamorous and easy to find.
What does it cost to retrieve your data. Charges for data leaving the platform apply to a bulk export just as they apply to everyday traffic, and a full estate export is not a small transfer. What notice is required to close accounts, and what happens to data after closure and for how long. Whether the account is held directly with the provider or through a reseller, because a reseller adds its own notice period and its own terms on top.
Then look at your commitments. Reserved capacity and spend agreements are how you get a lower price, and they are also a promise to keep spending for a term. Know the end date of every commitment you hold, what happens if you leave before it, and whether any of them renew automatically.
None of this normally prevents an exit. It changes the timing, and timing is what turns a planned migration into a rushed one.
The Exit Note, Written on Day One
For each significant system, write half a page while you are building it and the answers are in your head. Where the data lives and in what form. How to get a complete copy out, using which command or tool. Roughly how large that copy is. Which platform specific services this system depends on. What the equivalent would be elsewhere, even roughly. Who knows how any of this works.
Write it during the build, not during a review. After the fact, this takes an engineer a week per system and produces guesses. During the build it takes twenty minutes and produces facts, because somebody is currently doing the thing being described.
Keep the notes in the same place as the rest of your documentation, and review them when the system changes materially. A note describing an architecture from three years ago is worse than no note, because somebody will trust it.
The side benefit is bigger than the exit itself. That same page answers the auditor asking where personal data lives, the insurer asking about recovery, and the new engineer asking how any of this fits together.
Test the Export the Same Way You Test a Restore
A backup you have never restored is a hypothesis, and an exit plan you have never exercised is the same thing in a longer document. Once a year, pick one system and actually export it.
Do the whole thing. Run the export, move the data somewhere outside the platform, load it into a comparable product, and get somebody who uses the system to look at the result and say whether it is right. Time it from the decision to the confirmation. That elapsed time is your real portability, and it will be longer than the plan says.
You will find the same class of problems every time. An export that omits something. A field that arrives in a format the other product will not accept. Data volumes that make the transfer take days rather than hours. Permissions that only one person has. All of those are cheap to discover on a quiet afternoon and expensive to discover under a deadline.
Pick a different system each year and keep the results. Three of those exercises tell you more about your real position than any assessment somebody sells you.
Being Honest About the Trade
Portability has a price, paid now and every month. Writing to a common standard rather than to the best available service usually means more code to maintain, more infrastructure to run, and a system that is slower to build. For some businesses that is worth it. For most it is not.
The businesses that genuinely need to stay portable know why. A contract with a customer who requires it. A regulator with a view on concentration risk. A credible plan to move within a couple of years. If none of those apply to you, buy the managed service and write down the coupling.
What is never worth it is the middle position, where you pay for portability by avoiding the good services and then still cannot leave because identity and data are tied down anyway. That is the worst of both, and it is common.
Decide once, deliberately, and revisit it when something real changes: a new contract, a new regulation, an acquisition, or a supplier relationship that has gone sour.
