Yesterday I wrote about rotation: the anchor that leaves the room, and the fact that the clock is set by someone else's commercial decision. Today the same story showed up twice more in different clothes. Kimi shipped K3.1 Pro to the top of Hacker News (701 points), which means a model version just became the old model version. And Google is reportedly preparing to use Gmail and Google Photos content to target ads (258 points), which means the terms of a service people already pay for quietly changed meaning.
Neither of those is a breach. Neither is an outage. Both are the same underlying event: the thing you integrated is not the thing you will be integrating in eighteen months, and nobody signed anything that says otherwise.
That gap — between what you bought and what keeps existing — is the continuity layer.
Continuity is a promise nobody writes down
When you adopt a vendor, you buy a bundle: a capability, a price, an interface, and an implicit promise that tomorrow it will still mean roughly what it meant today. Only three of those four are in the contract.
The fourth is the one your architecture depends on. Your retry logic assumes the API keeps accepting the same payload. Your cost model assumes the price holds for a quarter. Your customer promise assumes the feature you resell stays available at the tier you resell it from. None of that is a commitment anyone made in writing. It's an assumption you made, and then hardened into your product.
The failure doesn't look like a 500. It looks like a changelog entry on a Tuesday.
The four ways continuity breaks
1. Version churn. A model ships, a model retires. Kimi K3.1 Pro at 701 points is good news for anyone building on Kimi — and a calendar event for everyone whose prompts were tuned against the previous version. Model behavior is not an interface; there is no semver for "it got slightly more literal."
2. Terms drift. Google deciding that your inbox is ad inventory is not a new product. It's the same product with a different meaning. Every platform you build on reserves the right to redefine the unit of exchange, and most of them exercise it inside a notice window shorter than your release cycle.
3. Corporate exit. eMudhra leaves the certificate business; Quad9 leaves France. The service doesn't degrade — it just stops being maintained by anyone with an incentive to keep it working.
4. Acquisition. The vendor gets bought, the roadmap gets re-aimed at an enterprise segment, and your tier quietly becomes "legacy." Nobody cancels you. You just stop being the customer the company is optimizing for.
Four different headlines. One question: who owns the date on which this stops working for you?
The date is the deliverable
Here is the uncomfortable part. In almost every team, the answer to "when do we have to move?" is a shrug with a rough quarter attached. Not because people are lazy, but because the date lives in four places at once: the vendor's deprecation policy, your contractual notice period, your customers' compliance calendar, and your own release train. Nobody's job is to reconcile those four calendars. So they drift, and the drift is invisible until it isn't.
The fix is unglamorous: write the date down, and put a name next to it. A continuity register with four columns — what we depend on, what would break, what date forces a decision, who owns it — is worth more than any resilience diagram, because it's the only artifact that produces a reminder before the incident instead of a postmortem after it.
Most teams discover they can fill in the first two columns in an afternoon and cannot fill in the last two at all. That's the finding, not the failure.
"We'll migrate" is a sentence, not a plan
Migration plans fail for a boring reason: they're written at the moment of maximum panic. The vendor announces the exit, everyone gathers, and the team tries to design a cutover in the same week they discover the scope. What comes out is a schedule, not a plan.
A plan has four properties, and all four have to exist before the announcement:
- A rehearsal. You have moved one workload off the primary vendor and back, on a normal Tuesday, with no incident. If you've never done it, you don't have a plan, you have an intention.
- A budget line. Migration costs money in engineering hours you haven't allocated. An unallocated cost is a wish.
- A degraded mode. What you serve while the migration is in flight. If the answer is "nothing," the migration will be done badly and fast.
- A named owner. One person whose performance review contains this. Committees don't get paged.
What you actually owe your customers
If you resell any part of your stack, continuity is not just an engineering concern — it's a disclosure obligation you probably haven't scoped. Customers don't need your vendor list. They need to know three things: what would interrupt the service, how long you could run degraded, and what you'd tell them and when.
The teams that handle exits well are not the ones with better vendors. They're the ones whose customers hear about the risk from them first, in ordinary language, months before it matters. That's a competitive advantage that costs almost nothing and compounds.
Six things to do this week
- Build the continuity register. Four columns: dependency, blast radius, forcing date, owner. Fifteen rows is enough to start.
- Reconcile the four calendars. Vendor deprecation policy, your notice period, customer compliance dates, your release train. The earliest one wins.
- Rehearse one exit. Pick your least critical vendor and actually move off it for a week. Measure the hours. That number is your migration tax.
- Treat vendor solvency as a dated dependency. Renewal date, funding date, acquisition rumors — put them in the same register as the technical dependencies.
- Write the customer-facing sentence now. "If X happened, here's what changes, for how long, and what we'd do." One paragraph. If you can't write it, you don't understand your exposure yet.
- Measure decision latency, not incident latency. The metric that matters is days between "we learned" and "we decided," not hours between "it broke" and "it was fixed."
Continuity is the least glamorous layer in this series, and the only one your customers will ever notice. Nobody praises a service for still working. They just leave when it doesn't.
Next in the series: the succession layer — what happens to the obligations when the company that owed them stops answering, and why "our partner will handle it" is the most expensive sentence in procurement.
Top comments (0)