Feature
eBook
Designing an AI-Native Contact Center
As AI vendors like OpenAI and Anthropic retire older foundation models, enterprises face a transition that looks familiar on the surface but is far more complex in practice.
Model retirement typically starts with a parallel run, where legacy and newer models operate side by side while users are gradually migrated. Once that process is complete, the underlying hardware and infrastructure supporting the older model can be repurposed.
When a vendor retires a model, they typically offer transitional support tools so that no customer is left high and dry, according to IEEE fellow Karen Panetta. However, enterprises using these models for in-house development must shoulder the migration themselves — often absorbing higher training and inference costs in the process.
Table of Contents
- Retiring an AI Model Is Nothing Like a Software Patch
- The Real Price of Moving to a New Model
- The Costs No One Budgets For
- What It Takes to Survive a Model Transition
- Model Portability Must Be Designed In
Retiring an AI Model Is Nothing Like a Software Patch
Unlike conventional software updates, AI transitions affect far more than code. Teams must revalidate prompt logic, retrain employees and update documentation, runbooks and QA processes. Test and quality assurance teams may also lack familiarity with prompt engineering and AI-specific behaviors, such as nondeterministic outputs or prompt sensitivity, increasing the risk of errors or rollbacks.
The real disruption, according to Ashish Nadkarni, GVP and GM within IDC's worldwide infrastructure research organization, emerges when AI models are deeply embedded in workflows. Tightly integrated prompts, automations and downstream dependencies can make migrations significantly harder than traditional application upgrades.
"People have a hard enough time with application modernization as it is," he said. "Introduce AI into it, it's going to be 10 times harder."
Related Article: Inside the AI Cost Crisis: Why Inference Is Draining Enterprise Budgets
The Real Price of Moving to a New Model
Migration always requires additional effort, Panetta noted. When moving to a newer model, organizations typically face several immediate cost drivers:
- Regression testing legacy prompts and workflows to understand behavioral changes
- Retraining models on proprietary data, which increases both time and compute costs
- Revalidating prompt variations, as newer models may respond differently to the same inputs
Teams must also ensure systems remain resilient to emerging attacks.
One common risk involves prompting models to assume specific personas that can bypass safeguards, expose restricted information or trigger inappropriate responses.
While this may seem daunting, said Panetta, good software engineering practices must always undergo regression and validation testing, even if no AI is involved. "A few of the AI-specific additional overheads are the retraining costs and prompt engineering rework."
The Costs No One Budgets For
Beyond the one-time effort of swapping models, Nadkarni said many of the largest costs emerge later — buried in day-to-day operational work. These expenses often surface across development, testing and quality assurance, where teams must revalidate workflows, integrations and outputs as models change.
These ongoing costs accumulate across routine operational work, often exceeding the initial migration effort:
- Integration updates as downstream systems react differently to new model outputs
- Retraining staff to account for new behaviors, capabilities and failure modes
- Revising processes built around assumptions tied to the retired model
- Running extended test cycles to catch subtle regressions in production workflows
The risk is amplified when vendors retire widely used models on their own timelines and organizations find themselves forced into upgrades — even if internal systems are not fully ready. "You might be stuck with a legacy model or a legacy scenario where you have to upgrade," Nadkarni explained.
As models age out, enterprises must absorb the operational and financial impact of moving forward, whether they planned for it or not.
What It Takes to Survive a Model Transition
Minimizing disruption requires treating model retirement as an enterprise-wide operational change, not a narrow technical upgrade.
Nadkarni pointed to three priorities enterprises should address:
1. Involve All Affected Stakeholders Early
Any team that relies on AI outputs — customer success, operations, analytics or business units — must be engaged. As models change, stakeholders need to watch for hallucinations or degraded outputs, especially when AI feeds downstream decisions.
2. Use AI-Specific Transition Frameworks
Organizations need structured frameworks to compare old and new model behavior, test edge cases and understand how changes affect workflows, beyond standard application modernization practices.
3. Handle New Outputs Deliberately
Newer models often generate more information. Teams must decide what is operationally useful and adjust workflows accordingly, ensuring added context improves outcomes rather than creating confusion.
Related Article: AI Hallucinations Nearly Double — Here’s Why They're Getting Worse, Not Better
Model Portability Must Be Designed In
Newer large language models are learning from new data and are less rigid than older models, according to Panetta. "When using these models as the foundation for in-house workflows, enterprises need an AI lifecycle strategy grounded in strong software engineering practices."
That strategy must also recognize that AI models are not plug-and-play systems and require extensive testing and rigorous standards before they can be trusted in production.
Avoiding AI vendor lock-in is possible, but only if enterprises plan for it from the start, Nadkarni said. Whether organizations can swap models without disruption depends largely on how deeply a model is embedded in workflows and how the application was originally designed.
| Design Approach | Migration Impact |
|---|---|
| Tightly coupled AI logic | High disruption, costly rewrites |
| Modular architecture | Faster model swaps, lower risk |
| Explicit abstraction layers | Reduced vendor lock-in |
| Model-specific workflows | Limited portability |
AI lock-in closely mirrors traditional application lock-in. Systems built with modular architectures and clear abstraction layers can replace models with far less disruption because model interchangeability was an explicit design goal.
Webinar
Jan
29
Cut the Noise: Deploying AI That Actually Moves the Needle
Learn how to turn AI experimentation into concrete revenue operations.
Register
Webinar
Feb
26
Do More with Less: Modernizing the Cloud Contact Center for 2026
Learn how to leverage cloud platforms without adding a single hire to personalize every customer interaction.
Register
Webinar
On demand
Rebrand. Migrate. Optimize. How to Do It All (Without Slowing Down)
Cresta leveled up site speed, design flexibility and marketer sanity (in record time). Find out how.
Watch Now
Webinar
On demand
From Manual to Magical: How AI Transforms CX Teams
Learn how to replace manual support processes with automation that actually delivers.
Watch Now
Webinar
On demand
How to Build a Solid Knowledge Foundation for AI Success
See how leading brands keep their AI honest, compliant and actually helpful.
Watch Now
Webinar
On demand
Fix the Content Bottleneck: Build a Better WebOps Strategy
Content stalled? Dev overloaded? You’re not the only one. Learn how streamlined WebOps bridges the publishing gap.
Watch Now
"Unless the application is 100% homegrown and written in a modular way where the AI model can be swapped out without problems downstream, lock-in is hard to avoid," Nadkarni noted.
AI systems, he cautioned, are repeating the same legacy mistakes enterprises made with earlier software generations. "AI platforms risk becoming tomorrow's legacy systems if portability and long-term flexibility are not built in from day one."