A few months ago, an agency sold a client on what looked like a straightforward AI project. The pitch was clean, the scope looked tight, and the client signed off on ninety hours for the integration work. Everyone walked out of the room happy.
By the time it shipped, the agency had billed over four hundred hours and absorbed the rest. The AI layer itself had taken almost exactly the time they’d planned for.
What nobody had accounted for was the 2009 Oracle database it needed to read from, the schema that had drifted so far from its original documentation that the documentation was actively misleading, and the three original developers who’d long since moved on without leaving a map behind.
Every week brought a new surprise, and every surprise cost hours that weren’t in the contract.
This is the quiet pattern sitting underneath most legacy AI projects right now. The model layer has become genuinely simple—call an API, pass a prompt, parse a response—and agencies scope that work accurately because they can see it.
The legacy system is invisible at proposal time, so it gets treated as a small dependency when it’s actually where most of the build is going to live.
By the time anyone realizes how deep the rabbit hole goes, the delivery date is locked, and the margin is already gone.
Why Legacy AI Projects Get Underscoped
The AI layer has become a commodity. Call an API, pass a prompt, and parse a response. That part looks simple in a proposal because it actually is.
The legacy system is where the hours go. It’s a 2009-era ERP that nobody has touched since the original developer left. No public API. No current documentation. A database schema that’s half-Hungarian-notation, half-customer-specific, with tables that nobody can confirm are canonical versus deprecated.
Agencies scope the AI work because they can see it. The legacy work is invisible at proposal time, so it gets treated as a small dependency—a few days of plumbing—when it’s actually the majority of the build. That’s how a six-week AI pilot becomes a six-month integration at twice the budget.
The Three Legacy Integration Patterns
Every legacy AI integration falls into one of three patterns, and each has a radically different cost curve. Identifying which pattern you’re dealing with is the single most important step before any scoping call.
- The Modern SaaS Pattern
The source system has a documented REST API, webhooks, OAuth, published rate limits, and a sandbox environment. Most HubSpot, Salesforce, Shopify, and newer CRM or ERP integrations fall here.
Integration cost is predictable. Budget weeks, not months, and the AI layer is usually the largest line item in the project.
- The Middle-Aged System Pattern
Built sometime in the 2010s with partial API coverage, inconsistent documentation, and a handful of endpoints that were originally “temporary” and are now production.
Integration works, but it typically costs double the initial estimate because every endpoint needs some level of reverse engineering. On-premise or single-tenant cloud, often bolted onto older infrastructure underneath.
- The True Legacy Pattern
Pre-2010 system, no API, no active developer contact, direct database access if you’re lucky. The integration is a custom ETL job, a middleware layer, or a full data sync to a modern warehouse before the AI layer ever sees the data.
Six-month minimum for anything non-trivial. This is the pattern that eats margin if it’s scoped as if it were the first.
Data Quality Is The Real AI Prerequisite
AI is only as useful as the data it reads. That’s obvious in principle and consistently ignored in practice. Gartner predicts that at least 30% of generative AI projects will be abandoned after proof of concept by the end of 2025, with poor data quality cited as one of the top drivers.
Legacy systems are where data quality goes to die. Twenty years of field drift. Three different notation standards for the same customer. Fields that used to mean one thing and now mean another. Free-text entries where dropdowns should have been.
When AI is plugged into that, the output isn’t the model’s baseline performance—it’s the model trying to reason across contradictions. The answer sounds authoritative because the language is fluent. The conclusions are wrong because the inputs were.
What A Data Profile Should Cover
Before any AI build, run a data profile. Inventory field completeness, duplication rates, schema consistency, freshness, and historical drift. Flag every field where the business meaning has changed over time without the schema catching up.
McKinsey’s State of AI 2024 survey found that 70% of high performers cite data management—governance, integration, volume—as their biggest AI hurdle. Without this profile, every output downstream is a guess layered on a guess.
API Availability And The Connector Build Cost
Modern AI integrations assume a connector exists. In practice, that’s the exception for anything older than a few years.
When a legacy system has a usable API, the connector cost sits in the tens-of-hours range. When it doesn’t, the work shifts to middleware: iPaaS platforms, custom sync jobs, or a full data replication layer that pulls legacy data into something the AI layer can query.
The difference between those two scenarios is often the difference between a profitable project and an unprofitable one.
In practice, that middleware decision comes down to three build paths, each with a different cost curve and a different long-term maintenance load.
Option one
iPaaS (Workato, Tray, Make, Boomi). Fast to stand up if the source system is already in the platform’s catalog. Breaks down the moment the legacy system isn’t supported, which for true legacy systems is most of the time.
Option two
Custom connector, built in-house or by a delivery partner. Full control over behaviour, error handling, and data shaping. The trade-off is that every change to the legacy system’s behaviour becomes an ongoing maintenance cost somebody has to own.
Option three
Replication to a modern data warehouse or lakehouse, then run AI against that copy. Decouples the AI layer from the legacy system entirely. Highest upfront investment, lowest long-term friction, and the only viable path when the legacy system can’t handle additional load or when security rules forbid direct AI access.
Security And Compliance On Legacy Data
Old systems have old security postures. Plaintext credentials in config files. Shared service accounts. No audit logging. No encryption at rest on fields that now count as PII under GDPR, HIPAA, or state-level US privacy laws that didn’t exist when the system was designed.
The moment AI starts reading from that system—or worse, writing back into it—every weakness becomes an AI risk. A prompt that pulls customer records pulls unredacted ones.
A model that drafts an email based on legacy data reaches into every field it can see, including ones the end user should never have had visibility on.
Compliance teams catch this at implementation, not at scoping. By then, the delivery date is already in the contract, and the retrofit becomes the agency’s problem.
Four checks decide whether a legacy AI project can actually ship, and they need to happen before the scope is signed.
- The first is data classification: knowing exactly which categories live in the source system—PHI, PII, financial records, PCI data—because each one carries its own regulatory weight.
- The second is access control: whether the system supports true role-based permissions or only authenticates users at the door and trusts them once they’re in, which AI will exploit by default.
- The third is auditability: whether AI-initiated queries can be logged and attributed to a specific user or service identity, because “the AI did it” is not a defensible audit trail.
- The fourth is data egress: whether contractual or regulatory restrictions prohibit the data from being sent to a third-party model provider at all. Every “no” in that sequence is either a project blocker or a significant unplanned scope addition, and the earlier it surfaces, the cheaper it is to solve.
The Readiness Assessment Every Proposal Needs
Every legacy AI proposal should be preceded by a short, paid readiness assessment. Not a discovery call. Not a scoping workshop. A structured technical audit of whether the system can support AI at all, and what it would cost to get there if it can’t today.
The assessment should cover six areas:
- Data inventory: which systems, which tables, which fields, which volumes, and which are in scope for the AI use case
- Data quality: completeness, duplication, schema drift, freshness, and the semantic drift of fields over time
- Integration surface: APIs, webhooks, database access, file exports, or the absence of all four
- Security profile: authentication model, encryption at rest and in transit, audit logging, data classification
- Documentation state: what exists, who wrote it, when it was last accurate, and what has changed since
- Ownership and access: who controls credentials, who approves schema changes, who signs off on data leaving the environment
The output is a clear go, no-go, or scoped path-to-readiness before the AI scope is even discussed.
Agencies that sell this as a standalone paid phase protect themselves from the single most common legacy AI failure: a fixed-price build where the legacy surprises eat the margin and the client ends up blaming the agency for not catching something they never had visibility into.
Where This Leaves Agencies Selling AI
The market has trained clients to think of AI as plug-and-play. The job now is to reset that expectation—not with caveats at the end of a proposal, but with a structured readiness step at the front.
The AI model isn’t the hard part. It hasn’t been for two years. The hard part is the system it’s plugged into: the decade-old database, the undocumented integration surface, the compliance footprint that nobody in the building fully owns.
Deloitte’s own analysis of AI adoption barriers points to exactly this—legacy infrastructure is rigid, hard to orchestrate against, and the biggest blocker to the AI outcomes enterprises actually want.
The agencies winning these projects aren’t the ones pricing AI the lowest. They’re the ones scoping the legacy reality honestly, charging for the assessment as its own deliverable, and treating the first phase as billable work rather than pre-sales overhead. Which side of that line is your next proposal on?
Frequently Asked Questions
FAQs
How Long Should A Legacy AI Readiness Assessment Take?
For a mid-sized client with three to five core systems, two to three weeks is typical. Enterprise environments with dozens of interconnected systems and stricter compliance requirements can run six to ten weeks.
The timeline scales with the number of source systems, not with the ambition of the AI use case, which is a useful thing to explain to clients upfront.
What’s The Difference Between An AI Integration And A Data Integration Here?
A data integration moves data between systems. An AI integration adds a model that reads, interprets, or generates new content based on that data, and that changes the failure modes.
AI introduces probabilistic outputs, prompt injection risk, hallucination exposure, and auditability requirements that a pure data pipe never has to account for.
Scoping them identically is how teams end up with an integration that works technically but fails compliance review.
Can We Just Replace The Legacy System Instead Of Integrating With It?
Sometimes, but rarely as a short-term play. Core-system replacements typically run twelve to twenty-four months and often stall because the legacy system holds years of edge-case business logic that nobody has ever written down.
For most clients, integrating first and replacing later is the faster path to AI value, and it keeps the replacement decision in the client’s court rather than making it a prerequisite for any AI work at all.
Should We Use Off-The-Shelf AI Connectors Or Build Custom?
Off-the-shelf works when the source system is already on the iPaaS vendor’s catalog, and the data volumes fit within their pricing tiers.
Custom is the right call when data needs to be transformed or filtered before the AI layer sees it, when the legacy system isn’t supported by any major platform, or when long-term ownership of the connector is strategically important to the client relationship.
Most real projects end up with a hybrid: off-the-shelf where it fits, custom where it doesn’t.
Who Should Own The Legacy AI Integration—The Agency Or Internal IT?
The agency typically owns the scoping, the AI layer, and the readiness assessment itself. The client’s internal IT team should own production access to legacy systems, credential management, and any compliance sign-offs that touch regulated data.
Blurred ownership here is one of the most common reasons these projects overrun.
Agencies that don’t have specialist integration engineers on staff often handle the execution load through white-label partnerships, which keeps the capability available without adding permanent headcount to a function that only fires on specific projects.
