No model lasts forever: LLM Lifecycle Management

Last updated: 14.10.2026 12:00

Whether it’s a chatbot, AI agent, or voicebot: The application runs smoothly, customers are satisfied, and the costs are right. Then comes an email from the model provider stating that the language model behind it will be shut down in 60 days. Why do providers discontinue their models? What does a forced switch mean? And most importantly: How can you become independent of this?

With traditional software, we’re used to a version running for years as long as we don’t make any changes to it. With Large Language Models (LLMs), it’s different. Here, the provider determines a model’s lifecycle—and that’s often shorter than that of a customer service project.

Why Models Are Discontinued

The most important reason for this is computing capacity. Every LLM that a provider continues to operate ties up GPUs (Graphics Processing Units) that are then unavailable for new models. Anthropic states this openly: Old models are phased out to free up capacity for new releases. Added to this is the pace of development: New generations of models now appear every few months. They are usually faster, cheaper to operate, and more powerful. From the provider’s perspective, there is therefore little reason to keep customers on an older generation indefinitely.
Less common, but still possible, are security or compliance reasons. Microsoft, for example, reserves the right to shut down a model on short notice in the event of security issues. Depending on the provider, there are two to six months between the announcement and the shutdown. The total lifespan of a model is therefore often only 12 to 18 months.

Forced model changes and the difficult search for successors

But regardless of the reasons, the result for users is always the same: a model has an expiration date, and after that date, requests simply fail. A recent example: Anthropic announced the end of support for “Claude Sonnet 4.5” on September 30, 2026, and will shut it down on November 30, 2026. That leaves exactly two months for testing, adaptation, and rollout. Important to note: If you obtain a model through a hyperscaler rather than directly from the manufacturer, the hyperscaler’s timeline applies. The same model can therefore have completely different shutdown dates depending on the provider.
The real headache for companies is this: Everything worked fine right up until the discontinuation announcement, so there’s no technical reason to switch. Nevertheless, it creates extra work in several areas: A productive AI agent is roughly optimized for three key metrics: intelligence, price, and latency. The successor model recommended by the provider rarely meets all three criteria. Often, it is more powerful but slower or more expensive—or both. This is particularly critical for voicebots, as the caller perceives every additional millisecond until the first response as a pause. Added to this is the question of where the successor model will be hosted. New models from hyperscalers usually launch first as a global deployment. Processing exclusively within the EU often follows months later—or sometimes not at all.

Customized Prompts and New Testing

Prompts are tailored to a specific model. A new model interprets the same instruction differently, responds with longer or shorter answers, adopts a different tone, or invokes functions differently. As a result, every change requires a complete testing cycle: typical conversation flows, edge cases, interfaces to backend systems, and approval by the business unit. If the provider or region changes, data protection reviews and contractual issues must also be addressed. While doing nothing doesn’t always result in being shut down outright, Azure, for example, automatically migrates certain deployments to the successor model on the shutdown date. The application then continues to run, but with a different model that no one has tested.

Transparency: Varies by Provider, but Mandatory for Customers

The quality of providers’ communication regarding end-of-life notices varies greatly. Some publish decommissioning dates at the time of release and even make them available via API. Others provide only tentative dates using phrasing like “no earlier than” or do not name the successor model until just a few months before the shutdown. On top of that, there are pitfalls in the details: notifications often go only to the owner of the respective cloud account. With Azure, the API status “Deprecated” means that a model has already been discontinued—but according to the documentation, it’s still running. So anyone using multiple providers must keep a constant eye on each one.

Good customer communication is part of the product

For companies that use AI in customer service, it is therefore especially important to know in advance what’s coming. Good communication answers questions like these early on:

• Which model is affected, and when?

• Which successor is planned, and how did it perform in testing?

• What will change in terms of costs, latency, and data processing?

• What steps are next, and who is responsible for what?

The Solution: Open-Weight Models

The problem of discontinuation and its consequences arises because decisions about an LLM’s lifecycle are made without user input. The situation is different with so-called open-weight models. Since these models are run on the user’s own or rented infrastructure, they remain operational for as long as they are needed.
This ties into a key issue: digital sovereignty is at the top of the agenda. That’s why VIER classifies AI services within its own sovereignty model. At Level 3, “EU-sovereign,” models run on European infrastructure, either operated by VIER itself or by a European provider. The data does not leave the EU and remains under European control.

In addition to complete control over the data, Level 3 has a pleasant side effect: switching models is no longer mandatory. A model that is tested and approved today will still run reliably in two years if the customer so desires. And even if a European hosting partner stops offering a model at some point, the exact same model can still be used with another provider because the weights are freely available. Of course, even a self-hosted LLM requires maintenance, such as security updates for the runtime environment and sufficient GPU capacity. However, the timing of a model change is then no longer determined by the provider, but by the customer!

Conclusion: Switch when it’s worth it, not because you have to

As a general rule, switching models isn’t inherently a bad thing. If a new model responds significantly faster, is noticeably cheaper, or solves tasks that the old model has previously failed to handle, the switch can clearly be worthwhile. Conversely, if a model reliably does its job, the “new” argument isn’t a real argument. In such cases, you must weigh whether the benefits justify the effort and risk of a switch. That is precisely what good LLM lifecycle management entails: maintaining an overview of which models are in use and how long they will continue to run; communicating with customers as early and honestly as possible; and implementing an architecture in which the customer decides for themselves when a switch makes sense.