The most expensive platform incident most companies will have this year is not an outage. It is a working system that stops being supported, at a date that was published months or years in advance, in a document nobody read. The API still responds for a while. Then it returns a deprecation header, then it fails, and the team that built on it has already been reassigned.
That is a scheduling failure more than a technical one. Policy changes from large platform providers are among the few risks with a reliable early warning, and almost no engineering organization treats them like capacity planning. The sections below describe where the risk actually sits, what the recent record shows, and how to build so that a notice period is enough time.
A deprecation notice is an outage with a known date
Large providers publish deprecation policies because enterprises demand them. Google Cloud's deprecation policy sets minimum notice periods that vary by the launch stage of a feature, which means a generally available service and a preview service can have very different windows. Microsoft publishes lifecycle dates per product. AWS publishes a maintenance policy for its SDKs and tools with defined support phases and end-of-support dates. The dates exist, and they are per service, per API version, and per SDK major version.
The engineering task is to convert those policies into lead times your planning process understands. A service with a one-year deprecation window is compatible with an annual architecture review. A preview feature that can change with a quarter's notice is not, and should not be load-bearing. Writing the notice period into the architecture decision record is a small habit that prevents most of these incidents, because it forces the question at design time.
The four categories that actually cost money
Not all policy changes are equal. Four categories account for nearly all of the pain. API and SDK deprecations are the most visible: an endpoint version retires, or an SDK major version reaches end of support, and code that has not changed in years must change now.
Licensing changes are the second and the most disruptive, because they can invalidate an architecture rather than an API call. When a widely used open-source component changes its license, the managed services built on it, the client libraries around it, and your own distribution obligations can all shift at once. The 2023 move of Terraform to the Business Source License prompted the OpenTofu fork, and Redis's 2024 shift to a source-available license led to the Valkey project. In both cases, teams that had treated the engine as a stable constant had to re-evaluate procurement, not just code.
AI-training terms are the third, and they are newer. Whether a provider can use your content to improve models, and whether it indemnifies you against copyright claims arising from generated output, are contract terms that change between product tiers and over time. Several major providers now offer indemnification for generative AI services, but the scope differs and the terms evolve. The fourth category is quieter: quota, rate-limit, and pricing structure changes that alter the cost or feasibility of an architecture without deprecating anything.
Where the exposure concentrates
Three patterns predict which systems will break. The first is a wrapper: your service depends on a managed offering that itself wraps an open-source engine or a third-party model, so a change two levels down reaches you with no notice at your own layer. The second is a preview dependency: something built on a beta API that became load-bearing because it worked well. The third is version drift in build tooling, where an SDK reaches end of support and the pinned version in your lockfile is no longer receiving security patches.
Each has a cheap countermeasure. For wrappers, ask during procurement what the provider would do if its underlying engine changed license, and get the answer in writing. For preview dependencies, record the launch stage and require a generally available equivalent before production use. For SDK drift, add dependency end-of-life dates to the same dashboard that tracks certificate expiry, because both are scheduled failures with published dates.
The organizational version of the same problem is ownership. Platform risk tends to fall between teams: architects own the design, platform engineering owns the tooling, procurement owns the contract, and security owns the review. Nobody owns the union of those four. Naming a single owner for third-party dependency risk, with a quarterly review that includes the contract file, is unglamorous and closes most of the gap.
Portability without pretending multi-cloud is free
Every architecture is portable in principle and expensive in practice. Data gravity, egress charges, identity integration, and operational tooling all push toward staying. A credible portability strategy is honest about that and concentrates on the parts that are cheap to keep movable.
Three practices do most of the work. Keep the integration surface thin: put provider-specific code behind an interface you own, and keep the interface small enough that a second implementation is a few weeks of work rather than a quarter. Keep data in open formats, and test the export rather than assuming it works. Keep infrastructure in code that describes intent, so a re-implementation is a rewrite of modules rather than a rediscovery of what exists. What you should not do is build a lowest-common-denominator abstraction that prevents you from using the platform well; that trade usually costs more than the risk it avoids.
AI-training terms deserve a contract review
For AI services specifically, the settings page is not the control. The question is what the contract says about training on your content, how long prompts and outputs are retained, whether human reviewers can read them, and what happens to derived artifacts such as fine-tunes. Providers have published data protection terms that address these questions, but the terms differ by product and change over time, and an application built on top of a platform sets its own terms on top of the platform's.
Two habits reduce exposure. First, treat any change to AI terms as a material contract change and route it through the same review as a price increase. Second, avoid putting regulated or uniquely valuable content into a service whose retention and training terms you cannot pin in writing. Where you cannot avoid it, add a contractual obligation and an audit right.
The resilience checklist
| Control | What good looks like | Failure signal |
|---|---|---|
| Deprecation register | Every dependency has a launch stage, notice period, and end-of-support date | Dates discovered during an incident |
| Licensing watch | Named owner tracks license changes for critical open-source components | First contact with a license change is a legal email |
| AI terms review | Training, retention, and indemnity terms recorded per product tier | Terms summarized from a marketing page |
| Thin integration | Provider-specific code behind interfaces you own | Provider SDK types in domain logic |
| Export tests | Quarterly export of critical data into an open format, verified by loading it elsewhere | Export untested since migration |
| Exit plan | Written plan with owners, cost estimate, and a ninety-day target | Plan exists only as an intention |
The ninety-day exit test
Pick the dependency that would hurt most if its terms changed next quarter. Write a plan that assumes the change is already announced, with a freeze date ninety days out. Identify the integration points, estimate the migration cost, and list what would have to be rebuilt. Then do one concrete step: export the data and load it somewhere else, or stand up a second implementation of one interface.
The value is not in completing the migration. It is in discovering, while you have time, that the export is incomplete or the abstraction leaks. Most teams that run this exercise find at least one dependency with no viable path at all, which is exactly the information a board needs before renewal.
What to do next
- Build a dependency register with launch stage, notice period, end-of-support date, and an owner for every critical platform service.
- Move production off preview and beta APIs, or document an approved exception with a dated exit.
- Add license-change monitoring for the open-source engines behind your managed services, not just your direct dependencies.
- Run the ninety-day exit test on your highest-risk dependency and record what broke.
- Route AI training, retention, and indemnity term changes through contract review rather than product settings.