Don't wait for your vendor to move first: a vendor-exit plan for vibe projects

Vendors never warn you before things go wrong

Your vibe project runs on other people's services: payments from one vendor, login from another, SMS from a third, file storage from a fourth, email from a fifth. While they all work, it is easy to believe they will keep working forever. The reality is different: vendors raise prices, change terms, shut down a plan, get acquired and change direction, or suffer an outage lasting hours — and when any of that happens, they will not ask your permission first, nor leave you a comfortable window to migrate. The only thing you can do is rehearse "replacing them" while everything is still fine.

This guide gives you that rehearsal method: a vendor-exit plan. It does not teach you how to choose a vendor, nor how to integrate any specific service. It answers one question only: when you must replace a third-party service, how do you do it with no perceptible impact on users, no data loss, no bill shock, and a rollback path open at all times.

First, the boundaries, because several neighbouring guides on this site are easy to confuse. The tech-stack migration guide is about changing an entire stack — for example moving from one framework to another — across the whole site; this guide is about replacing a single third-party service, such as payments alone or SMS alone, which is far smaller in scope and completely different in rhythm. The dependency-upgrade guide is about raising the version of an open-source library; this guide is about replacing an external service provider — one is a library in your code, the other is a vendor outside your accounts. The dependency supply-chain security guide is about whether a dependency is poisoned or unsafe; this guide does not care whether the vendor is safe, only how to replace it without an outage. The API circuit-breaker, degradation, and timeout guide is about surviving the minutes when a counterpart fails; this guide is about permanently replacing a counterpart that can no longer be relied on. The AI-feature fallback and degradation guide is about keeping AI features alive when they fail; this guide is not about AI features at all, only third-party services. The agent spend hard cap, agent data-access guardrails, agent handover pack, agent permission contract, regression-verification baseline, agent-damage rescue, release-notes writing, last-hour launch runbook, poisoned-dependency containment, and AI-review second-check guides are all about agent tasks, release flows, or security incidents, and none of them overlap the topic of "replacing a vendor." The database backup and disaster-recovery guide is about recovering lost data; this guide uses backups, but its goal is not recovery — it is migration, moving data from the old vendor to the new one completely and reconciling it afterwards.

Step one: grade every vendor now, not when things break

The first step of an exit plan is not code. It is a list: write down every third-party service your project uses, and grade each one by the cost of being unable to replace it. There is only one grading criterion: if this service stopped tomorrow, how long would it take you to restore service.

Grade one is business-critical: if it stops, service stops, or user data cannot be recovered. Typical members are payments, login, core database hosting, and domain and DNS. This grade needs a complete exit plan: the alternative vendor's account already opened, data export already rehearsed, and the switchover steps already written down.

Grade two is replaceable with pain: stopping hurts, but there is a way around it. SMS can temporarily fall back to email notification, object storage can temporarily go read-only, analytics can be paused. This grade needs the name of an alternative and a switch to flip, but not a fully rehearsed migration.

Grade three is cosmetic: stopping only affects experience details, such as a share button or a statistics panel. This grade only needs to be on the list; when it breaks, you simply take it offline.

The grading template is simple, five columns per row: service name, purpose, grade, alternative vendor, export method and last rehearsal date. Review the list at least once a year, because services change: a service that was cosmetic last year may have become business-critical this year as usage grew. The list itself is worth little; the regular review is worth everything.

Step two: three preparations to make while everything works

The most valuable parts of an exit plan all sit in advance preparation, and all three can be done slowly while nothing is on fire.

The first is a thin abstraction layer. Your business code should not call a vendor's proprietary interface directly; it should go through your own thin interface. For example, payments should not be scattered across the project as calls to one payment provider, but concentrated in your own payment module, which internally calls the provider. Keep the layer thin: encapsulate only the three to five operations you actually use, and do not try to abstract the vendor's entire feature set, or the abstraction itself becomes a second vendor. The test is simple: when you switch vendors, the files you change should sit in one directory, not be scattered across the whole project.

The second is a data-export rehearsal. Do it at least once a year: export the core data from the vendor's dashboard and check whether the exported format is usable, whether the fields are complete, and whether key relationships are missing. For example, does the user export include user IDs and registration times, does the order export include payment status and refund records, does the file-storage export include the file list and access URLs. During the rehearsal, actually open the export file, count the rows, and spot-check a few records — do not merely confirm that "there is an export button in the dashboard." A button existing does not mean its exported data is usable.

The third is an alternative account plus a key-rotation list. For business-critical services, open the alternative vendor's account in advance, run a minimal call through it, and confirm its plan and price are acceptable. At the same time, maintain the list of where the old vendor's keys live: which environment variables, configuration files, and scheduled jobs contain them, what needs changing at switchover, and how to verify the change. Maintain this list in normal times; hunting for keys across the project on switchover day guarantees you will miss one.

Step three: the six-step replacement, in order

When the time to switch really comes, follow six steps in order. Skipping steps is the most common source of data loss.

Step one is to lock in the new vendor and run a minimal call. Do not migrate data first. Run the smallest possible closed loop through the new vendor: collect one test payment, send one test SMS, store and retrieve one test file. If the minimal call does not work, everything after it is empty talk.

Step two is data migration and verification. Export the old data, import it into the new vendor, then verify on three levels: totals (row counts, file counts, user counts); sampling (pick 20 records at random and compare field by field); relationships (can orders be matched to users, can files be matched to records). If any level fails, stop and investigate. Do not carry an open question into the next step.

Step three is the dual-write period. Run the old and new services side by side for a while: new data is written to both, reads still come from the old service. For a solo team, 3 to 7 days is usually enough. Dual-write is the most important step in the whole plan, because it gives you the ability to go back at any time: as long as the old service is still receiving writes, rolling back is just flipping a switch.

Step four is a gradual rollout. Move a small slice of traffic to the new service first — your own account, internal test accounts, five percent of new users — watch it for a day, then expand step by step. Gradual rollout is not for show; it turns "everything breaks at once" into "a small scope breaks."

Step five is the observation period. After full switchover, observe at least one complete business cycle: payments must cover one reconciliation cycle, SMS must cover one peak period, email must cover one scheduled-job cycle. During observation, keep the old service read-only. Do not rush to shut it down.

Step six is old-service shutdown and billing close-out. Only after the new service is stable, the old data archived, and the old keys revoked, shut the old service down. Before shutting down, do three things: export a final copy of the old data and archive it; confirm auto-renewal is cancelled; confirm there are no unsettled charges in the billing cycle. Shutdown is not "clicking delete"; it is a close-out checklist, ticked item by item.

Step four: the switchover calendar, from T-7 to T+7

Put the six steps on a calendar and switchover day stops being chaotic. T-7 days: send the internal notice and freeze other changes touching that service (no stacking other releases onto switchover week). T-3 days: finish migration and three-level verification, and rehearse the rollback switch once. T-1 day: confirm dual-write is healthy, the key list is complete, and the on-call person is named. T day: switch over at the gradual-rollout percentage, with the on-call person present throughout. T+1 day: check the first batch of real data, and reconcile billing and logs. T+3 days: expand to one hundred percent. T+7 days: the observation period ends, and the shutdown close-out list runs. The calendar can be compressed to fit your project, but the order and the checkpoints cannot be skipped — above all the rule "freeze other changes during switchover week." The easiest mistake for a solo team is shipping another change on switchover day, after which nobody can tell whose change caused the problem.

Rollback triggers must be written in advance, written as hard lines, and executed — not debated — on switchover day. Five red lines, any one of which triggers an immediate rollback: the new service's error rate exceeds the old service's for 30 consecutive minutes; real user money, order, or account data becomes inconsistent; the new service's billing shows unexpected large charges; success rates for critical functions (payment success, login success, SMS delivery) fall below the number you set in advance; or you find a data-verification problem whose cause is not immediately clear. Rollback is not failure; it is the exit plan working as designed. With rollback lines, you dare to switch; without them, switching is gambling.

Three typical replacements: payments, login and SMS, object storage

For payments, reconciliation and the refund chain matter most. Beyond users and orders, confirm that historical refunds, disputed orders, and subscription states map across. After switchover, reconcile the first billing cycle line by line, and for subscriptions confirm that the next charge goes through the new service, not the old one. Payment rollouts must start small, with internal accounts and small amounts — never full traffic on day one.

For login and SMS, identity continuity matters most. User identifiers, phone numbers, and verification records in the old service must map to the same people in the new service. During switchover, existing users must never be forced to re-register, and when the verification channel switches, a fallback channel must be ready (for example, email codes when SMS fails), or users will be locked out and you will only learn about it from support messages.

For object storage, access URLs and permissions matter most. Moving the files is only step one: do old file URLs stay valid, do the permission rules for public versus private files line up, and have historical references (article images, user avatars, exported files) been replaced in bulk. The easiest files to lose are the ones nobody visits: they are skipped most easily during migration, and hardest to recover when something goes wrong.

Contract and billing checkpoints: where the money leaks

Before switching, read the old service's contract and billing terms, focusing on four items: the notice period (some services require 30 days' written notice, or they auto-renew for another year); the data-retention period (how many days data survives after the account closes, and whether it is then permanently deleted); export limits (some services allow only paged exports, not full exports, so large exports must be queued in advance); and auto-renewal and minimum-spend traps (closing the service does not necessarily close the bill — the billing switch must be confirmed separately). Any one of these four can leave you technically switched over but paying for another year. Write the findings into the switchover checklist and confirm them item by item on switchover day.

Five anti-patterns: five ways to write a plan and still get nothing

First, an alternative vendor that exists only in your bookmarks: an alternative you have never opened an account with or run a call through is no alternative at all.

Second, an abstraction layer built too thick: abstracting a vendor's entire feature set turns the layer itself into a maintenance burden, and switching vendors then requires rewriting the layer first.

Third, skipping dual-write and switching directly: without dual-write there is no rollback footing, and if the switch goes wrong, the only option is to stop service and fix it.

Fourth, stacking other releases onto switchover day: when something breaks, responsibility cannot be assigned, and debugging time doubles.

Fifth, shutting the old service down without close-out: billing keeps charging, keys stay valid, data is never archived, and the old service keeps generating risk as if it were never closed.

A yearly tabletop exercise: insurance that costs nothing

Writing the plan is not the end. Once a year, run a tabletop exercise: without actually switching, gather around a table — even if the team is only you — and pretend a business-critical vendor stops tomorrow. Walk the list: who is the alternative, how is the data exported, how is dual-write opened, where is the rollback switch, how is billing stopped. Every "I don't know" found in the exercise is a follow-up: an unknown alternative-account password, an unknown export format, an unknown rollback switch — each gets fixed after the exercise. The exercise takes under an hour, but it guarantees that on the day things really break, you are executing a plan you have already rehearsed, not searching for answers. Vendors will not warn you before things go wrong, but you can be ready in advance: list in hand, alternative ready, rollback available. That is the cheapest insurance a solo team can buy.

Appendix: the vendor-exit checklist (ready only when every item ticks)

Are all third-party services graded? Do business-critical services each have an alternative vendor and an export-rehearsal date? Does business code reach vendors only through a thin abstraction layer? Has the alternative account run a minimal call? Is the key list complete? Did data migration pass all three verification levels? Is a dual-write period on the calendar? Are the gradual-rollout percentages and the observation period set? Are the rollback triggers written as hard lines? Is the old-service shutdown close-out list (archive, cancel renewal, revoke keys) ready? Only when all ten answers are yes may the plan be called ready; if any answer is no, fix that item first, then talk about switching.