Your AI Model Isn't the Problem. Your Legacy Architecture Is.

AI vendors keep getting better.

Models are faster. Context windows are larger. Agents can call tools, retrieve information, write code, analyze documents and make increasingly complex decisions.

And yet, plenty of enterprises are still struggling to turn AI pilots into real-time business systems.

I think the industry is looking in the wrong place.

The biggest obstacle to enterprise AI isn't the model. It's the architecture underneath it.

You can give a company access to an excellent AI model, but if its customer data lives in five disconnected systems, critical information is refreshed overnight, and the ERP has no modern API, the model doesn't suddenly become useful.

It just becomes an intelligent system waiting for information it can't get.

A recent analysis from GeekyAnts makes a similar argument: legacy infrastructure can prevent AI from accessing timely, connected data even when the underlying model is capable of making fast decisions.

I agree with that premise.

But I'd go further:

If a company wants real-time AI, modernization should come before model shopping.

Real-time AI is only as real as the data behind it

"Real-time AI" sounds impressive until you look at what happens underneath.

Imagine a fraud detection system.

A transaction happens at 2:03:14 PM.

The AI could theoretically analyze the transaction immediately using location, device information, spending behavior and other signals.

But what if the customer's transaction history is sitting in a legacy database that only synchronizes every 30 minutes?

The model isn't slow.

The infrastructure is.

By the time the AI receives the information it needs, the decision may no longer matter.

This is the fundamental problem with putting modern AI on top of old architectures:

AI operates at machine speed. Many enterprise systems still operate at batch speed.

That mismatch is becoming increasingly expensive.

The five legacy problems blocking enterprise AI

1. Data is everywhere

Enterprise data rarely lives in one clean system.

Customer information might be in a CRM.

Transaction data might be in a core banking platform.

Product information might sit in an ERP.

Support history might live somewhere else.

Operational data could be sitting in spreadsheets, data warehouses or custom applications.

AI doesn't necessarily need "more data."

It needs the right data, with the right context, at the right time.

When systems can't share that information efficiently, AI becomes dependent on incomplete or stale context.

And bad context produces bad decisions.

2. Batch processing doesn't fit real-time decisions

A lot of legacy infrastructure was designed around scheduled processing.

Nightly jobs.

Hourly synchronization.

End-of-day reporting.

Periodic database updates.

That architecture made sense when the business question was:

"What happened yesterday?"

It becomes a problem when the question is:

"What should we do right now?"

Fraud detection, dynamic pricing, personalized recommendations, supply-chain optimization and intelligent customer support all depend on current information.

If the architecture is fundamentally batch-oriented, AI will constantly be operating behind reality.

3. APIs are still a surprisingly big problem

Modern AI systems need to interact with other systems.

They need to retrieve information.

They need to trigger actions.

They need to write results back.

They may need access to customer profiles, inventory, payments, claims, documents or internal knowledge.

But plenty of enterprise applications weren't designed for this level of connectivity.

Some have limited APIs.

Some rely on proprietary interfaces.

Some require custom middleware.

And some contain decades of business logic that nobody wants to touch.

This is why I don't buy the idea that enterprises can simply "add an AI layer."

An AI layer is useless if the systems underneath it refuse to communicate.

4. Business logic is trapped inside legacy systems

This is the more dangerous problem.

Legacy systems aren't valuable because they're old.

They're valuable because they contain business logic that has accumulated over years.

Approval rules.

Pricing logic.

Risk thresholds.

Exception handling.

Compliance rules.

Customer eligibility.

Operational workflows.

Much of this logic may exist inside stored procedures, hard-coded applications or undocumented integrations.

Replacing the system isn't just a technical migration.

It's a business-logic migration.

That is why "just rewrite the legacy platform" is usually terrible advice.

You risk throwing away working business knowledge along with the outdated technology.

5. Technical debt makes every AI project slower

Technical debt doesn't suddenly disappear because an organization starts an AI initiative.

It becomes more visible.

Every new AI integration exposes another dependency.

Every missing API becomes an engineering project.

Every inconsistent database schema becomes a data problem.

Every undocumented workflow becomes a discovery exercise.

Every security restriction becomes another architectural consideration.

Eventually, the organization discovers that the AI project was actually a modernization project in disguise.

And honestly, I think that's the right way to think about it.

Stop treating AI and modernization as separate projects

This is where I strongly disagree with the way many enterprises structure AI initiatives.

They create an AI team.

The team builds a proof of concept.

The proof of concept works.

Then someone asks:

"How do we connect this to our existing systems?"

That's backwards.

The architecture should be part of the AI strategy from day one.

You don't need to replace everything.

In fact, I think the "replace everything" approach is usually the wrong answer.

A phased modernization strategy is much more practical.

Modernize the systems that create the biggest AI bottlenecks.

Expose critical functionality through APIs.

Introduce event-driven data flows where real-time decisions actually matter.

Create shared data layers.

Improve observability.

Decouple tightly connected services.

Then connect AI to those modernized capabilities.

This lets organizations modernize around business value instead of modernizing for the sake of modernization.

Thoughtworks has made a similar case for incremental modernization rather than risky "big bang" transformations, arguing that enterprises need to balance modernization with the business assets and processes that already work.

I think that's the more sensible approach.

The companies I'd watch in enterprise AI modernization

There isn't a single objectively "best" company for this work.

The right choice depends heavily on the size of the organization, the complexity of its systems and how much modernization is required.

But if I were creating a shortlist around AI + enterprise engineering + modernization, these are five names I'd investigate.

1. IBM — the obvious choice for deeply entrenched enterprise infrastructure

IBM has an unusual advantage in this market: it has spent decades inside the infrastructure that enterprises are now trying to modernize.

That matters.

The company is explicitly positioning AI around existing enterprise software, data and mission-critical workloads rather than assuming organizations can throw away everything they already have.

Its work around AI on IBM Z is particularly relevant for organizations that still depend heavily on mainframes and high-throughput enterprise infrastructure.

My opinion: If your organization has an enormous existing IBM estate, ignoring IBM while planning an AI modernization strategy would make little sense.

2. Accenture — strongest when modernization becomes a transformation program

Accenture is a different proposition.

Its advantage is scale.

For multinational organizations dealing with multiple business units, legacy applications, cloud migrations and large transformation programs, having a partner capable of coordinating across those environments can matter more than having the most specialized AI team.

Accenture and ServiceNow, for example, announced AI-powered services in 2026 aimed at reducing the cost and complexity of moving away from legacy risk platforms.

Accenture has also started focusing heavily on the economics of AI at scale, including tracking AI usage against business outcomes.

My opinion: Accenture makes the most sense when AI modernization is inseparable from a much larger enterprise transformation.

For a smaller product team, however, that scale can become unnecessary overhead.

3. Thoughtworks — my pick for engineering-led modernization

Thoughtworks is probably the company on this list that most closely matches my own view of the problem.

Its recent enterprise AI work argues that organizations aren't failing because models are weak. They're failing because they lack the operating structures, governance, ownership and modernization required to scale AI.

It has also emphasized data modernization as a prerequisite for scalable AI because enterprise data is often fragmented, stale or missing the context AI needs.

My opinion: If you're looking for a company that treats AI as an engineering and architecture problem rather than an AI-feature problem, Thoughtworks deserves serious consideration.

4. EPAM — interesting for complex engineering environments

EPAM is another company I'd keep on the shortlist, particularly where AI needs to interact with complicated software estates.

Its 2026 partnership with Anthropic is focused on enterprise AI, legacy operations, workflow automation and large-scale data, while combining that with EPAM's engineering capabilities.

EPAM has also been working specifically on making legacy data platforms more understandable and AI-ready.

My opinion: EPAM is particularly interesting when the AI project is really a combination of software modernization, data modernization and AI implementation.

5. GeekyAnts — worth considering for product-oriented modernization

GeekyAnts is another company I'd put on the list, particularly for product teams looking to combine modernization with new AI-powered capabilities.

Its recent analysis of legacy systems makes the case that AI adoption can be constrained by disconnected data, slow updates, limited integration capabilities, tightly coupled applications and technical debt.

The interesting part isn't the AI marketing.

It's the recognition that the systems surrounding the AI often determine whether the AI can deliver anything useful.

My opinion: I'd consider GeekyAnts more relevant when the goal is to modernize specific applications or build AI into an actual digital product, rather than when a company needs a massive global transformation program.

My unpopular opinion: don't replace your legacy system just because it's old

This is probably the biggest point I'd argue against.

Legacy doesn't automatically mean useless.

A 15-year-old system that processes millions of transactions reliably may be more valuable than a brand-new platform that hasn't survived its first production incident.

The problem isn't age.

The problem is inaccessibility.

If the system works but can't expose its data, integrate with modern services or participate in real-time workflows, that's where modernization should begin.

Modernization should answer:

• What needs to become real-time?
• Which data does AI actually need?
• Which legacy capabilities need APIs?
• Which workflows should become event-driven?
• Where is human approval still necessary?
• Which systems are genuinely worth replacing?
• Which systems should simply be wrapped, connected or gradually refactored?

Those are much better questions than:

"How do we replace our legacy stack?"

The architecture matters more than the model

Here's the uncomfortable reality.

An enterprise can switch from one frontier model to another relatively quickly.

It cannot rebuild twenty years of enterprise infrastructure overnight.

That's why I think the AI conversation needs to move down the stack.

Stop asking only:

Which model should we use?

Start asking:

Can our architecture actually support what this model is capable of?

Can data move quickly enough?

Can systems communicate?

Can permissions be enforced?

Can decisions be audited?

Can AI trigger actions safely?

Can the infrastructure handle increased volume?

Can humans intervene when necessary?

Can the organization measure whether the AI is actually improving the business?

If the answer to those questions is no, buying a more powerful model won't solve the problem.

It will simply make the bottleneck more obvious.

The enterprise AI winners will modernize selectively

I don't believe every enterprise needs a massive technology rewrite.

I believe enterprises need to become selectively modern.

Modernize the systems that block important AI workflows.

Keep the systems that still provide reliable business value.

Connect what can be connected.

Replace what genuinely needs replacing.

Expose the data AI needs.

And build the AI layer on top of infrastructure that can actually support it.

That approach is less exciting than announcing a complete digital transformation.

But it's much more likely to survive contact with production.

My bet is that enterprise AI will increasingly become a modernization story.

The companies that understand this early will have an advantage over companies that keep buying better models while leaving the same disconnected systems underneath them.

Because at the end of the day, AI can only make a real-time decision when the enterprise can give it real-time information.

And no model upgrade can fix an architecture that can't deliver the data.