AI Versus Vendor Lock-in

Every CIO Has a “Vendor Story”.

Every one can tell you a story about the time a vendor tried – and sometimes succeeded – to hold them hostage. I once witnessed a senior VP of sales from an unnamed large database and enterprise software vendor in an “annual review” meeting with a CIO. The SVP theatrically flipped through some papers and remarked, as if he had just noticed, that the annualized value of the vendor’s discount was bigger than the customer’s net profit. Since the discount was set at the SVP’s discretion, as veiled threats go that one was pretty naked.

I’ve also had CIOs, CEOs, and even board members tell me about some SaaS product that doubled or tripled their price in a single contract renewal. Sometimes that discussion started a secret project to replace the vendor. More often it was just venting frustration.

Imagine being that CIO! Your calendar has a day circled in red: contract renewal. You know the price is going to skyrocket. Your team is telling you all the reasons why there’s nothing you can do. (But you suspect that half of them have more of their career tied up with the vendor’s success than your company’s.) Your systems are thoroughly dependent on the vendor. Key data lives there. Business processes and integrations accumulated for the last three years. The estimates to exit are alarmingly large and uncertain. Adoption was quick, but separation takes a multi-year program with require board-level capital investment and years of frustrated stakeholders who aren’t getting other work out of you. Your budget and staff are barely adequate for this year’s planned work, let alone a migration project. You sign the renewal, knowing full well that the next iteration of this game will be even worse… assuming you survive three more annual budget reviews.

You’re a hostage, but only because you’re locked in. Lock in persists while the cost and risk of leaving exceed the pain of staying. AI changes that calculation.

Why We Stay

We stay when staying costs less than switching. Suppose we tally up the costs in two columns:

There’s a big element of uncertainty in the migration needed to switch. How much do we trust our team’s or the consultants’ estimate? Once we start the migration, are there decision points where we would back out of it? And what happens when our vendor finds out that you tried and failed to displace them?

The Old Answer

For decades, we have tried to solve this with architecture. Build an isolation layer between our systems and the vendor. Create adapters that abstract the vendor details away: data formats, protocol adapters, portability layers. “We can swap the implementation later.” In the meantime, we carry the cost of the isolation layer – in architectural effort, development time, and opportunity cost – in the hopes that one day it will pay off. This is an expensive option to buy and one that is rarely exercised. Even changing from one SQL RDBMS to another almost never happens… and when such a migration does happen the isolation layer invariably turns out to be leaky anyway.

Beyond that, SaaS already blew up the isolation layer approach. There’s just no practical way to isolate a SaaS GUI.

What Has Changed

Migrations haven’t suddenly become easy. But AI agents do offer a way to reduce the cost and uncertainty of the work. What used to be an open-ended multi-year task now looks more like a token budget.

It used to be that one of the big risk factors was just rediscovering how the old system worked. Where does this field come from? Who uses this feature? Which of these five APIs is the one the application actually uses? Is this behavior documented, or did somebody write it twelve years ago and then leave?

An AI agent can investigate the code, documentation, schemas, and examples. It can map the calls the application makes, generate conversion code, and help build tests that compare the old behavior with the new one. Where documentation is missing, you can have the agent add it. Where unit tests are missing, you can have the agent write new tests to characterize the old system’s behavior. If anything, you’ll have to set guardrails to keep it from blowing your token budget on comprehensively useless tests!

Instead of anticipating change by building a generic layer that would let us substitute some future vendor, we can create the abstraction layer at the time when the need for it is certain. The “last responsible moment” will be right before we exercise the option.

Any migration tool we need can be created just for this job. It can be specific to this vendor, this data, and this destination. Once it has moved everything and passed reconciliation, we can throw it away. (Please resist the urge to turn it into a product.)

We can also test the idea before we commit to the whole migration. Export a representative slice. Move one data domain. Rebuild one workflow and get the users’ feedback. That gives us evidence about the data mapping, exceptions, functional gaps, and cutover risk. It turns a migration estimate from a work of speculative fiction into something we can inspect.

There is one complication. An exit – even an experiment to see if it’s feasible – is not always a harmless technical spike. If the vendor finds out, they may conclude that you’re leaving. The relationship can deteriorate before you have a working alternative. They can add friction or reduce support. Sometimes you may decide that the information from the spike is worth the risk. Just be careful about how public you want to be with it. And keep in mind which half of your team is vendor-captured.

Example: Photoshop to PhotoCraft

This week a project went viral on X. PhotoCraft is an open-source, clean-room reimplementation of Adobe Photoshop in Rust. It was built from public specifications and observed behavior.

Photoshop is not a small application with three screens and a database table. It has decades of accumulated features, file formats, and user expectations. It’s also a product from a vendor with a reputation for abusive contracts and exit terms.

PhotoCraft won’t be enough for every Photoshop user to switch today, but it shows that a project can take a mature product’s observable behavior as its specification and attempt a substantial replacement.

Of course, we’re also talking about a single-user application rather than an operationally critical shared service, so your milage may vary.

Example: Data product platform

A couple of years ago, one of my teams needed to upgrade versions of a core data platform. Unfortunately, this particular upgrade meant changes that rippled into user notebooks. More than 800,000 notebooks needed to be updated… many of them critical for daily operations. A typical labor-driven consulting project looked like three years of work, with zero value added.

We used one of the early software engineering agents to automate the changes. At the time, it only worked completely on 90% of the notebooks. With two more years of advances in models and harnesses, it might do better today. Even so, taking 90% of the workload off the team made the rest of the work feasible. Many of the remaining notebooks needed human review and approval, while a small fraction required human editing.

(A sad paradox was that most of the notebooks that really needed work were the very old ones, from before we had strong conventions and shared libraries. So they were weird, unfamiliar, and likely to have been written by someone long since gone.)

The SaaS Migration Trap

There’s a trap to be wary of. Don’t inadvertantly sign up to become an undercapitalized internal SaaS vendor. You might think you’re migrating off Salesforce, but accidentally build your own Salesforce clone.

Your company has spent years accumulating workflows, reports, permission rules, integrations, and custom fields. Everybody naturally wants them preserved. At the same time, you want to minimize the investment in getting out from under the vendor. It’ll also be a new system that hasn’t gone through a decade of operational hardening and observability improvements. You probably don’t want to match the SaaS vendor’s cumulative spend. So the new system will probably have a worse UI, lower availability, and a backlog of “must have” features that the old vendor already had. You still need a team to run it, fix it, and respond when it breaks. Yes, you get out from under the Salesforce bill. But you might have traded it for a permanently staffed internal cost center. Congratulations, you’ve become a SaaS vendor for one customer.

(BTW, this is also how every “Splunk is too expensive” migration I’ve seen ends up: a permanently understaffed team and frustrated users with one query tied behind their back.)

The useful question is not just, “How do we get away from this vendor?” It is, “What are we moving to?” Maybe the answer is another SaaS product. Maybe it’s a smaller system that does the five things you actually need, or a constellation of decomposed microservices. You might even realize that the vendor’s product is still the least expensive way to get all the capabilities you rely on. The main lesson is to be deliberate about what you are moving to not just what you are getting away from.

Data Gravity

Software is easier to move than the data that has accumulated around it. Data has gravity. Data stores tend to accumulate management and governance processes. Permissions, audit history, reports, integrations, deletion requests, business rules, etc.

With a SaaS vendor, it’s also possible that you’re not allowed to get direct access to all your data.

So while an agent can help by writing a one-time migration tool for a particular schema, it can’t necessarily break you free of the data gravity well.

AI Can Help You Escape AI

I’ve heard some people express concern about getting locked in to one of the frontier labs. Believe me, the labs wish they could lock you in. So far, they seem fungible. All their features are quickly replicated by the others and switching models has not been difficult.

Even if you somehow get one of them entangled with your internal systems, there’s an amusing jiu-jitsu move here: have the new AI agent migrate you away from the old one.

Summing Up

For a long time, lock-in persisted because leaving was too expensive and too risky. We tried to buy our way out in advance with isolation layers. Those layers were expensive to build, leaked details of the thing they were supposed to hide, and often sat there untested until the day we needed them.

AI changes the cost of doing the migration when we need it. We can build a purpose-made converter, reimplement the behavior we depend on, and use agents to move both code and data. We can try a small exit experiment to learn what the full move would involve. However, that experiment may also change our relationship with the vendor, so we there can be costs beyond the tokens.

Data gravity is still a thing. And “we replaced Salesforce” can mean “we now have our own Salesforce, but worse.” We need to know what we’re moving to, and whether the system we build is actually cheaper to own.

But maybe we don’t need to predict every future vendor switch correctly. We need to be able to leave when the cost of staying gets too high but we don’t necessarily need to prepare for divorce the same day we get engaged.