Your CFO Will Never Fund Technical Debt

By Sameer Khasnis, SVP Enterprise Architecture, Avid

Summary: We retired a 28-year-old SAP core without a big-bang cutover. Here's how we built the business case, how we're governing AI so it doesn't become the next pile of debt, and what those lessons mean for customers facing the same challenge.

I recently joined a panel of CIOs and technology leaders, convened by the San Francisco Chapter of the Society for Information Management (SIM), on how you retire technical debt without stalling the business. I opened with something I feel strongly about: Retiring technical debt is not just an IT project, but is a critical need requiring the entirety of the business. When you treat any business transformation involving technology as an IT problem to solve, you risk losing momentum, buy-in, and funding.

I know this because we lived it: We modernized Avid’s internal processes over the last few years, tearing out decades of legacy tech along the way. However, the hardest part was never the architecture; it was the politics and the question of who pays for massive change. That is the part most modernization efforts never quite solve, which is why so many of them stall. It's also the conversation I now have constantly with the broadcasters we build for, who are staring at the same problem from the other side.

Here's a number that should worry any technology leader: In a survey of large enterprises, nearly 60% of SAP migrations came in delayed, over budget, or both¹. These projects rarely fail loudly. They grind and they overrun. They quietly deliver less than promised, even at companies with budget, talent, and executive attention. The problem usually isn't the technology, it's that the work got framed as only a technology problem in the first place.

No CFO funds a refactoring program

Walk into a budget meeting and ask for two million dollars to retire technical debt, and you'll walk out with nothing. "Technical debt" means nothing to a CFO, and it shouldn't.

When we set out to replace a 28-year-old SAP core that had run our business for three decades, we didn't pitch it as an IT project. We quantified what the old system was actually costing us: Revenue lost to latency and downtime, order conversions and invoicing drag, the compounding cost of every workaround built on top of a platform nobody wanted to touch. Then we modeled the cost of avoiding all of that over several years.

That's what unlocked the funding. Not technical diagrams, but dollars. Technical debt is invisible until you translate it into money; once you do, it stops being an IT line item and becomes a business liability that leadership has a reason to care about.

Retire the monolith one piece at a time

The instinct with a decades-old core is to plan one heroic cutover: build the new thing, flip the switch, hold your breath. That instinct is how you join the 60% that overrun.

We did the opposite. We peeled functions off the old system one at a time and let the legacy platform keep running alongside the new one. We transformed our direct-to-consumer business first, standing up Salesforce Commerce Cloud, Revenue Cloud, and NetSuite ERP in fifteen months, while the old system continued running. When we went live, we started with a single zip code in Hawaii, watched it closely, and expanded to full production over three weeks. Then we moved on to the next objective—reimagining our business-to-business quote-to-cash capabilities.

Engineers call this the strangler fig pattern. Martin Fowler named it two decades ago, after the plant that roots in the canopy of an older tree and works its way down until it has quietly taken the host's place². The discipline it teaches is patience: Modernize in increments small enough that a bad day is a contained incident, not a company-wide outage. But there's a second discipline people forget; the strangler fig has an end state. Part of the job is knowing when you've extracted enough value and further surgery stops paying for itself. Not every piece of the old system is worth replacing.

AI is quietly rewriting the build-versus-buy decision

For years, the default answer to any new capability was buy the SaaS tool. Building in-house was slow and expensive, and rarely worth it. AI has changed that math.

We've used AI agents to stand up capabilities on modern, composable technology in a fraction of the time a custom build used to take, integrating with the SaaS applications and enterprise productivity tools we already run rather than bolting on another standalone tool. I'm not saying build everything—I'm saying the line has moved. Capabilities that clearly said "buy" two years ago now deserve a second look, because building is measured in weeks now, not quarters.

The next wave of debt is already forming

Here's the part that keeps me up at night. Everyone wants to do AI. Every team, every function, spinning up its own tools. Left alone, that becomes sprawl: A dozen overlapping systems doing nearly the same job, none of them governed. It's the same mess we spent years cleaning up, arriving faster and dressed in newer clothes.

MIT's State of AI in Business 2025 study found that roughly 95% of enterprise generative-AI pilots delivered no measurable impact on the bottom line³. The failure point was rarely the model. It was everything around it: No architecture, no governance, no plan for the day you switch it off. Sound familiar? It's the technical-debt story again, wearing an AI badge.

Today's AI apps are cheap to replace. That won't last. The estates we build carelessly in 2026 are the migration nightmares of 2028. Govern early and decommission without sentiment.

The one habit worth changing

If I had to compress all of this into a single change of behavior, it would be this: Stop treating transformation as a technology project. Anchor it to business outcomes and KPIs you can measure and treat it as mandatory rather than a nice-to-have upgrade that the business can defer another year.

None of this work is glamorous; it's framing, sequencing, and the discipline to retire things you've outgrown. But it's the difference between transformation that ships and transformation that becomes a cautionary statistic.

Which brings me back to our own customers. We build the systems that broadcasters and media companies run their newsrooms on, and many of them are staring at the same monolith we were: Mission-critical platforms they can't afford to switch off, and a real need to modernize for a digital-first audience. The industry is mid-transition and knows it. Most newsrooms run some blend of SDI, IP, and cloud side by side, precisely because nobody sensible rips out a working newsroom overnight. The playbook is the same one above: Evolve in increments, keep the proven systems running while new capability layers on top, and never bet the business on a single big-bang cutover. Modernizing without disruption and downtime is the whole point.

Sources 
1. ISG, “The State of SAP Migrations” — survey of 200+ business and IT decision-makers at global enterprises with 1,000+ employees. Reported by The Register, February 2026, and CIO.com, February 2026. Comparable finding in Horváth’s SAP transformation survey (200+ executives), reported by TTC Global, 2025.
2. Martin Fowler, “Strangler Fig Application,” 2004. Pattern documentation also maintained by Thoughtworks, Microsoft Azure Architecture Center, and AWS Prescriptive Guidance.
3. MIT NANDA initiative, “The GenAI Divide: State of AI in Business 2025” — based on 300+ public AI deployments, 150 executive interviews, and 350 employee surveys. Reported by Fortune and Forbes, August 2025.