Run a Vendor Exit Fire Drill Before You Need It

An exit plan you have never tested is a guess. Everyone knows they should be able to leave a critical vendor. Almost nobody has actually tried, which means the plan is theory until the day pricing spikes or the vendor goes down and you find out the export is broken, the format is unusable, or the migration takes three weeks you do not have. A vendor exit fire drill fixes that. You rehearse leaving while nothing is on fire, discover what is actually broken about your escape route, and fix it calmly. It is the difference between owning your options and hoping you have them.

What is a vendor exit fire drill?

It is a rehearsal. You pick a critical vendor and you actually go through the motions of leaving, without committing to the move. The point is to surface every gap between your imagined exit and the real one.

A drill answers concrete questions. Can I export my data, and is the export complete and usable, or just a token gesture? How long does it take? What breaks when this vendor is gone? What proprietary features am I relying on that have no equivalent anywhere else? Could I actually stand up the replacement, and how long would it take?

You do not have to complete the migration. You have to get far enough to know it would work. Think of it like a backup restore drill, which is the same reason I insist on testing backups with real restore drills: an untested recovery is not a recovery, and an untested exit is not an exit.

How to run the drill

Pick the vendor that would hurt most to lose, and work through five steps.

Export everything. Pull a full export of your data from the vendor and open it. Is it complete? Is it in a format another tool can read, or is it a proprietary dump that only they can load? This is where most exits die, and it is exactly the gap every vendor exit plan is supposed to close.

Map the dependencies. List everything in your stack that talks to this vendor. Every integration, every webhook, every hardcoded assumption. The ones you forgot are the ones that break during a real move.

Stand up the alternative. Actually provision the replacement, even briefly. If you are leaving a managed database, spin up your own database box and load the export into it. If it loads clean and the app can point at it, your exit is real. If it does not, you just learned that in a drill instead of a crisis.

Time it. Note how long each step actually took. That number is your true switching cost, and it is usually higher than the guess. Knowing it changes how you negotiate and how much you trust the vendor.

Write down what broke. The drill's output is a list of gaps. Fix the cheap ones now.

What the drill usually reveals

The first drill almost always finds ugly surprises. That is the point.

The export is incomplete. History is missing, attachments are not included, or the format loses structure you depend on. Now you know to keep your own copy, the same way I keep analytics history on my own infrastructure rather than trusting a vendor to hand it over.

A hidden dependency. Something you forgot was wired to the vendor, and it silently breaks the moment they are gone. Better found in a drill.

Proprietary features with no equivalent. You built on a magic capability that only this vendor has, and there is no clean replacement. That is real lock-in, and now you can decide whether to reduce it before it becomes a trap, the same judgment behind spotting lock-in before you sign.

The migration is longer than the notice period. If leaving takes a month and the vendor's shutdown notice would be two weeks, you have a genuine business risk that a drill exposes while there is still time to close it.

How often to drill, and on what

You do not drill everything. You drill the vendors that are load-bearing: the ones whose disappearance would stop you from serving customers or shipping product. For those, run a drill when you first adopt the vendor and again once a year, because exports change, integrations grow, and last year's working escape route quietly rots.

For replaceable vendors, skip it. If you could swap the tool in an afternoon, the drill is not worth the time.

The habit is what matters. A stack you have actually rehearsed leaving is a stack you control, because you know your real options instead of assuming them. That is the whole spirit of owning your stack: not distrust of every vendor, but proven independence from the ones that matter. When the foundation you would fall back to already lives on hardware you own at HostSSH, the drill goes from anxious to routine, because the escape route is already built.