What Happens When a Provider Discontinues a Service
Cloud services are retired more often than people expect. The process is usually orderly, and the planning that makes it survivable is cheap.
Platforms retire services. Sometimes a product is withdrawn, sometimes a
version reaches end of support, sometimes a feature is folded into something
else. Google Cloud has a particular reputation here, enough that it is a
recognised consideration when choosing a platform to build on for a decade, but
every provider does it.
This is usually an orderly process rather than a disaster. The risk is being
unprepared for a change that was announced eighteen months earlier to an address
nobody reads.
What deprecation normally looks like
The common sequence:
- Announcement, typically with a long notice period for
anything widely used. - No new customers, while existing ones continue.
- Maintenance only: security fixes, no new features.
- Migration guidance to a successor, sometimes with tooling
and sometimes with credits. - End of support, after which the service may continue
running unsupported or be shut down.
The notice is usually generous for infrastructure-level services, because
providers know customers have long planning cycles. It is shorter for preview
and beta services, which brings us to the main lesson.
Preview services are not commitments
Services labelled preview, beta or experimental carry explicitly reduced
commitments. They may change incompatibly, may not be covered by uptime
guarantees, and may be withdrawn with considerably less notice.
They are genuinely useful for evaluation and for non-critical work. Building
a production dependency on one is accepting a risk the label is telling you
about. If a preview service is the only thing that solves your problem, use it
knowingly, keep the integration isolated, and have a view on what you would do
if it disappeared.
Signs a service is being wound down
Deprecation is often visible before it is announced:
- No meaningful feature releases for a long period while comparable services
advance. - Documentation that stops being updated, or quietly recommends an
alternative. - A successor service launched that overlaps heavily.
- Removal from the provider’s own recommended architectures.
- Support for new runtimes or versions arriving late or not at all.
None is conclusive, but several together are worth noticing before the
announcement arrives.
Version end-of-life is the more frequent event
Most teams encounter version deprecation rather than whole-service
withdrawal. A managed database version reaches end of support, a serverless
runtime is retired, a Kubernetes version falls out of the supported window.
These arrive on a schedule, are announced well ahead, and frequently end with
the provider upgrading you automatically if you have not acted. That automatic
upgrade is the thing to avoid being surprised by, because it happens during a
maintenance window you did not choose.
The defence is simply to know your versions and their support dates, and to
plan upgrades rather than receive them.
Reducing exposure without avoiding managed services
The overcorrection is to use nothing proprietary, which costs more than the
risk it avoids, as discussed in
vendor lock-in: what is real and what is
overstated. Proportionate measures:
- Make sure deprecation notices reach a person. They go to
the registered contact address, which is the same address that receives
suspension warnings and is frequently unmonitored. - Prefer generally available services for anything you depend
on, and treat preview services as experiments. - Prefer services with open equivalents. Managed PostgreSQL
has somewhere to go; a proprietary service with no counterpart does not. - Isolate the integration behind an interface, so replacing
it touches one module. - Record which managed services you depend on, with their
versions. This list is also what a migration plan needs. - Review it annually. Fifteen minutes, once a year, checking
support dates and deprecation notices.
When it does happen
Read the notice properly, including the actual end date and what the provider
offers: migration tooling, credits, or extended support for a fee. Then decide
early whether to move to the successor or to something else entirely, because a
forced migration is also an opportunity to reconsider a choice made years ago
for reasons that may no longer apply.
Start before the deadline rather than near it. Migration tooling and support
attention are both more available at the start of a deprecation window than at
the end, when everyone else has also left it late.