The IVR Is a Legacy System. Modernize It Like One.

Press 1 if you’ve heard this before.

“Please listen carefully, as our menu options have changed.” They have not changed. You know it, I know it, and somewhere in a data center a recording that has survived three generations of infrastructure strategy knows it too. Greetings have been reassuring callers about imaginary change since before the iPhone existed, which makes it one of the longest-running works of corporate fiction still in production. Just like, “We are currently experiencing unusually high call volumes”. Sure, you are.

Everyone knows the ritual that follows. Press zero. Press zero again, harder, as if the telephone can sense commitment. Say “representative” with the slow, dangerous calm of someone negotiating a hostage release. Eventually, after entering the same account number several times and hearing assurances that your call is very important, you reach another human being who asks for the account number again. We treat this as a mildly infuriating fact of modern life, like airport security or expense reports.

I hear something different because I have spent twenty-five years modernizing legacy systems, walking into enterprises to migrate VB6, Delphi, PowerBuilder, Informix 4GL, and other technology estates that everyone depended on and nobody particularly wanted to touch. After enough of those projects, you develop an ear for a particular kind of software: old, critical, poorly understood, quietly running the business while everyone pretends it is somebody else’s problem. The corporate phone tree is that software. It is a legacy application you interact with by ear, and after surviving nearly every modernization wave that killed its cousins, it is finally, genuinely, about to be replaced. Which is exactly when things get exciting and dangerous.

You know it when you hear it

A legacy system is not defined by age. Plenty of old software is well-tested, well-documented, and calmly boring. Nobody wakes up excited about it, which is often a sign that it is doing its job. Legacy is a condition, not a birthday, and the symptoms are familiar.

• Nobody fully understands the system, including the people responsible for it.
• There are no tests, so nobody changes it, so there are still no tests.
• The documentation is oral tradition, usually held by two veterans and a binder last updated during the Obama administration.
• Users hate the interface but have stopped mentioning it, the way you eventually stop noticing a smell.
• Everyone agrees that it is “too critical to touch,” which gets repeated often enough to sound like a maintenance strategy.

Now score the traditional IVR (Interactive Voice Response) system against that list. It runs branching logic accumulated over decades, often expressed in vendor-specific configuration that amounts to spaghetti code navigated one audio prompt at a time. “Press 1” is a GOTO statement, the nested menus are unstructured control flow, the mysterious dead end after “billing inquiries” is an unhandled exception, and the hold music is the error message.

Nobody at your company can draw the whole tree from memory, and there probably is no comprehensive regression suite. Instead, there is a quarterly complaint in the customer-experience survey, which is the enterprise equivalent of discovering outages on social media. The interface is so widely despised that “phone tree” works as a joke without explanation, a level of cultural penetration few enterprise applications achieve. Five for five: the IVR is not adjacent to your legacy portfolio.

It is the portfolio’s senior member, and it answers your front door.

Quarantined, not cured

There is a puzzle here. The green screens got modernized. The VB6 applications got migrated. On-premises email went to the cloud, mainframe reports became dashboards, and client-server applications became web applications, which later became cloud applications and are now being enthusiastically discussed as candidates for agents. The phone tree watched all of this happen and barely moved.

It survived for three reasons, none particularly flattering. First, telephony lived in a silo. It developed in a different organizational country from mainstream IT, complete with its own vendors, budgets, acronyms, specialists, and procurement cycles. Modernization programs swept through the application estate and stopped at the border because the phone system belonged to someone else. Frequently, it belonged to a contract.

Second, it guards the front door. Replacing an internal expense application carries bounded risk. If it breaks, employees grumble and finance sends increasingly urgent emails. The phone system answers customers when they are confused, angry, vulnerable, ready to buy, ready to cancel, or wondering why several thousand dollars have disappeared from an account. That creates a powerful incentive to leave it alone.

Third, and most corrosive, is the phrase that has preserved more bad enterprise software than any vendor maintenance agreement ever could: “It works.” The IVR works the way a drawbridge works. Traffic technically gets through. The fact that callers finally reach a human already furious, after reciting their account number three times to a machine that then asks for it a fourth, does not appear in the uptime report. The IVR was never cured, - it was quarantined, and for forty years the quarantine held.

The demo finally got good

What broke the quarantine was not a sudden corporate appetite for telephony modernization. The technology changed. Conversational AI crossed an important line: latency dropped, systems became capable of maintaining context across multi-turn conversations, and voice synthesis stopped sounding quite so much like a GPS suffering from seasonal allergies. Modern systems can handle interruption, ambiguity, corrections, accents, incomplete sentences, and the messy conversational signals humans produce without realizing we are producing them.

Recent real-time voice systems are explicitly being designed around continuous, responsive interaction rather than the old request-response pattern. The experience has shifted from “That is impressive for a computer” toward something much more consequential: “Wait. Was that the computer?” The market has noticed as well. Gartner predicts that by 2029, agentic AI will autonomously resolve 80 percent of common customer-service issues without human intervention, with a corresponding 30 percent reduction in operational costs.

The platform layer is moving quickly too. Twilio’s August 2026 earnings discussion included production examples such as an AI assistant that had already handled nearly 300,000 customer conversations, as well as seven-figure deals involving agentic AI and voice infrastructure. Amazon, Google, Microsoft, Genesys, Five9, NICE, Twilio, OpenAI, Anthropic, and a growing ecosystem of voice-AI companies are converging on the same opportunity from different directions.

The board presentation practically writes itself. Take one of the most hated interfaces in the enterprise, replace it with one of the most impressive technologies of the decade, improve customer experience, reduce labor cost, and add a tasteful upward-pointing arrow. What could possibly go wrong? Quite a lot, because the shiny demonstration has one important property that your existing phone tree does not: the demo has no history.

The tree is the documentation

This is the point where the project changes. Your phone tree is not simply an interface; it is a system of record for business policy that may exist nowhere else. Every branch represents a decision somebody once made for a reason. There is a fraud threshold that routes certain callers to a special queue, a seasonal rule added during a product recall in 2014 that may still be sitting there, and an after-hours path that exists because of an incident nobody remembers.

An escalation shortcut may have appeared after an executive’s neighbor complained at a barbecue. Some rules reflect regulation, some reflect risk, some are obsolete, and some are ridiculous. The dangerous part is that, from the outside, they look exactly alike. Veteran agents carry another layer of the system in their heads. That is, - what customers actually mean when they use certain phrases, which policies bend, which ones absolutely do not, and which five words suggest that a customer is about thirty seconds away from leaving.

Most of that knowledge never made it into a requirements document. The tree is the requirements document. The prompts, routing rules, queue logic, agent scripts, exceptions, and accumulated muscle memory together form the most complete specification of how the organization actually handles customers, and much of it was written by people who no longer work there.

This is familiar territory in legacy modernization. On many migration projects, the running system is the only reliable specification you will ever receive. Requirements documents describe what somebody thought the application did in 2007. The production system tells you what survived contact with reality. The first job is software archaeology: excavate the behavior, separate the load-bearing rules from the sediment, and find out which strange branch is a defect and which strange branch is quietly preventing a regulatory violation every Tuesday afternoon.

Replacing an IVR with a voice agent is therefore not primarily a conversational-design project. It is an excavation with a mission and deadline. If you treat it as a greenfield AI feature and you risk producing an articulate amnesiac: a system with a beautiful voice and absolutely no idea why the old rules existed. The old phone tree at least remembered the recall. It just could not pronounce it.

Old systems fail on repeat. New ones fail creatively.

There is another inheritance problem, and this one should interest architects. Legacy systems tend to fail deterministically. When a thirty-year-old billing routine is wrong, it is usually wrong in the same way every time. That is frustrating, but strangely comforting: same input, same incorrect output, write a test, fix it, sleep. Migration teams survive on that determinism by running the old system, running the new system, comparing the results, and investigating the differences.

Language-model systems introduce a different failure mode because they are probabilistic. Ask a well-designed agent the same kind of question many times and it may behave perfectly hundreds of times, phrase something oddly on another attempt, misunderstand an edge case later, and eventually produce an answer nobody anticipated. The failure does not necessarily repeat on command, may never appear in the happy-path demonstration, and may sound completely confident when it happens.

Your phone tree was infuriating, but it could not improvise. A conversational agent improvises for a living. That can be a very good trade, but only if you change the engineering discipline around it.

In the multi-agent systems built for legacy modernization, one rule is non-negotiable: the agent doing the work does not get to be the only agent grading the work. A separate evaluator uses real evidence such as builds, tests, comparisons, expected behavior, and other ground truth to judge whether the output actually succeeded. Broader industry practice points in the same direction.

Agent evaluation works best when automated tests are combined with production monitoring, transcript review, user feedback, and human calibration rather than trusting a single evaluation mechanism.

Voice systems deserve the same discipline. Build evaluation sets from real historical conversations before launch, and have adversarial callers attempt policy exceptions, unauthorized discounts, information disclosure, social engineering, strange interruptions, and ambiguous requests. Replay those scenarios whenever a model, prompt, tool, policy, or orchestration layer changes. Review production conversations against written policy, sample the uncomfortable cases, and treat prompt changes as production changes because that is what they are. A prompt edit is a deployment wearing casual clothes. None of this appears in the demo, but all of it determines whether the demo becomes a system.

Migrate it like you mean it!

The reassuring part is that we already know quite a lot about replacing badly understood critical software. Start with software archaeology. Your call recordings and transcripts are source code, so mine them before writing the new conversation. What do people actually call about? What words do they use? Which intents overlap? Where do callers become confused or abandon the call? Where do agents routinely override the official process, and what emotional state accompanies each request? Pure institutional gold.

Most large organizations have years of this evidence, and many have barely examined it. An intent taxonomy extracted from real calls is worth considerably more than one invented on a workshop whiteboard because callers, inconveniently, do not attend taxonomy workshops.

Then migrate incrementally. Martin Fowler’s Strangler Fig pattern describes gradually building a new system around an existing one instead of betting the company on a single replacement event. The underlying objective is simple: reduce risk by transferring behavior in pieces while the old system remains available. No big bang! That philosophy maps almost embarrassingly well to voice AI.

Do not begin with fraud disputes, insurance denials, bereavement calls, mortgage modifications, and furious customers threatening litigation. Let the agent handle password resets, order status, store hours, and appointment confirmations. Let it listen in shadow mode before it owns the conversation, compare what it would have done with what experienced agents actually did, and expand the surface gradually. Keep the old route available until the new one earns the traffic.

A big-bang cutover here is like rebuilding the bridge while sending rush-hour traffic across it: possible in theory, memorable in practice, and likely to become a cautionary tale afterward.

Escalation is not failure

There is one legacy contact-center assumption worth killing early. Human escalation is not failure. It is a feature. In ordinary software modernization, a rollback mechanism gives the team confidence to move quickly. In conversational systems, the rollback mechanism has a name: the customer.

An AI agent that recognizes uncertainty, transfers the customer quickly, sends the human agent the transcript, preserves context, and clearly explains what has already been attempted has succeeded. The customer should not restart the interaction after escalation: no retelling the story, no fourth account-number recital, and no discovering that the automated system and the human system live in neighboring countries without diplomatic relations.

Sometimes the most intelligent sentence an AI system can produce is, “I’m going to get someone who can help with this.” That sentence may do more for trust than another ten percentage points of autonomous containment, which brings us to the metric that helped create the old IVR in the first place.

Measure resolution, not deflection

Containment rate sounds wonderfully efficient because it measures how many callers did not reach a person. For decades, organizations optimized around variants of this idea. Think about that for a moment: “How successfully did we avoid talking to our customers?” Forty years of pursuing that goal helped produce the interface people now scream at.

If we aim conversational AI at the same metric, we will rebuild the old phone tree with dramatically better pronunciation. It will be fluent, scalable, and may even remember your name, but it will still be optimized around keeping you away from somebody capable of solving your problem. The better question is not whether the machine retained the caller. It is whether the problem resolved fully.

Did the customer get the refund? Was the appointment changed? Was the suspicious charge handled? Did the customer understand the answer? Did escalation happen at the right moment? Did the customer need to call back? These are harder questions than “Was the call contained?” but they are much closer to the actual purpose of the interaction.

That shift changes the economics. Once intelligent voice generation becomes cheaper, verification becomes more important. Once automation handles the ordinary cases, the human cases become less ordinary. Once AI can conduct a conversation, organizational value shifts toward deciding when it should not. The bottleneck moves, as it always does.

Regulation may be an unfair advantage

So who moves first? The instinctive answer is the least regulated companies: businesses that can experiment quickly, accept a little ambiguity, and move before governance catches up. I am not sure that is right.

Some of the deepest IVR debt lives in banks, credit unions, insurers, healthcare systems, utilities, and other highly regulated institutions. They conduct important business by telephone with people who are often under stress, and they also have the highest bar for getting voice AI right. A conversational system mispronouncing a product name is funny. A conversational system revealing an account balance to the wrong person is an incident. A system improvising a coverage decision, financial promise, or legally significant policy explanation can become a much more expensive kind of conversation.

And yet that compliance burden may turn out to be an architectural advantage. Identity verification, explicit consent, audit trails, documented escalation, retention rules, access controls, provable adherence to policy, and independent risk assessment are not merely compliance artifacts. They are ingredients of a trustworthy agent. NIST’s Generative AI Risk Management Profile makes much the same larger point: trustworthiness has to be managed across the AI lifecycle, with governance, measurement, evaluation, and risk controls designed into the system rather than bolted on afterward.

Regulated organizations cannot casually skip the verification layer, treat transcripts as exhaust, or shrug at creative failure. They are forced to do much of the homework up front. That creates an interesting possibility since the organizations everybody assumes will move last may be unusually well positioned to move well. For once, the compliance office may not be the department of no. It may be the “free” QA team.

Every legacy system was once the future

There is one final lesson hiding inside the phone tree. The VB6 applications I spent years migrating were not born as legacy software. Neither were the Delphi systems or the mainframes. Each was somebody’s modernization, each replaced something older and worse, and a team designed it, built it, launched it, and probably felt justifiably proud.

Legacy is not what bad software becomes. Legacy is what successful software can become after enough people, context, documentation, assumptions, and institutional memory disappear while the behavior remains. The voice agent you deploy next year is not exempt.

Its prompts will evolve, policies will accumulate, exceptions will appear, and someone will add a temporary rule on a Friday afternoon. A model upgrade will subtly change behavior. The person who understood why a particular escalation exists will leave. By 2035, somebody may be sitting in a meeting asking why the AI always transfers customers in Nebraska who mention Tuesday, and nobody will know unless we build these systems differently.

Keep business policies outside the prompt where possible. Make evaluation sets first-class assets. Preserve decision logs. Version prompts and policies. Keep the embarrassing decisions too, because those are often the ones future teams most need explained. Record why unusual behavior exists, not merely what the behavior is. Build the system you would want to inherit, because somebody will.

The opportunity is real, and it is larger than labor savings. For forty years, the telephone call, perhaps the oldest and most human channel a company still operates, has been guarded by software designed largely to prevent the conversation from happening. That was containment. We built a machine to hold people at the door and then wondered why they arrived angry.

For the first time since that familiar recording was installed, the menu options really are about to change. The companies that treat this as a legacy modernization effort will excavate the existing behavior, preserve the rules worth preserving, migrate incrementally, test adversarially, design human escalation deliberately, and measure whether customers’ problems actually ended. They may finally retire one of the most hated interfaces in business.

The companies that treat it as an impressive AI demo with a rollout schedule may accomplish something else. They will build the next system everyone screams at, only this time it talks back. The goal was never to automate the conversation. It was to make the conversation worth having.

Press 1 to begin.

---

Further Reading

• Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029 - Gartner, March 2025. The source for the 80 percent autonomous-resolution forecast and projected 30 percent operational-cost reduction.
• Strangler Fig Application - Martin Fowler, updated August 2024. The modernization pattern behind the article’s recommendation to replace the IVR incrementally rather than through a big-bang cutover.
• Demystifying evals for AI agents - Anthropic, January 2026. Practical guidance on agent evaluation, regression testing, production monitoring, transcript review, and human calibration.
• How we built a realtime system for responsive voice AI in six months - Uberti & Malkani, OpenAI, August 2026. An engineering look at the latency, state, and interaction advances making responsive conversational voice systems practical.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile - Autio et al., NIST, July 2024, updated April 2026. A useful framework for the governance, measurement, evaluation, and lifecycle controls required for trustworthy generative AI.

---

Disclaimer: The perspectives shared in this article are our own and do not represent those of our employer or any affiliated organizations. All company names, product names, logos, and brands mentioned are the property of their respective owners and are used for identification and illustrative purposes only. No endorsement, sponsorship, or affiliation is intended or implied. References to specific companies or case studies are based on publicly available information and are used solely for educational and discussion purposes.