The data decisions that make AI deliver

Data problems in AI are fundamentally downstream of systems problems, because data reflects the systems it comes from and AI outputs must be written back to those same systems to activate decisions. Ellery Fisher of McKesson Medical Surgical, a company with 200 years of legacy technology, frames this as a two-sided constraint: legacy systems cause data quality issues and are simultaneously the destination for AI-driven actions, making systems modernization inseparable from AI delivery.

Danielle Behringer adds that data quality and systems constraints are equally real inhibitors rather than competing explanations. In practice, eight out of ten applications sharing data gravity get modernized while two are left behind, and those remaining two create gaps in agentic experiences. Legacy COBOL, mainframe code, and SaaS products that block full integration are the typical culprits, though low-code, no-code, and code-assistive tools now offer a credible path to bring those lagging applications into a modernized estate.

The timing mismatch between real-time AI and batch legacy infrastructure is illustrated by a specific McKesson example. The company holds nearly two trillion prices in its price cube, and the pricing system runs a 24-hour batch job that updates overnight. Fisher describes trying to mesh real-time AI with that architecture as like having a phone call with a newspaper. McKesson identified dynamic real-time cost and price determination as a target use case but found it blocked entirely by the batch pricing system. Fisher also notes that five years ago AI was about decision intelligence and insight, whereas the current goal is real-time automation, which adds a time dimension to data quality requirements that did not previously exist.

Supply chain resilience extends the challenge beyond internal systems, requiring collaboration across data engineering and software engineering to pull third-party supply data through organizational boundaries. Organizations built through mergers and acquisitions often carry multiple ERP systems, some upgradeable and some not, and third parties may be unwilling or physically unable to fully integrate due to on-premise infrastructure and multi-cloud complexity. Clients frequently lack full control over architectural decisions because they depend on the readiness of external partners. Ontologies and digital twins of business processes are emerging as tools to help prioritize where modernization effort should go.

Roughly half of AI failures are attributed to not picking the right places to apply AI at the outset, and most organizations are not doing quantitative value scoring to determine which system modernization waves will support AI and generative AI use cases. The recommended approach is a resource allocation framework that explicitly balances keeping lights on, application modernization, and building new capabilities. The majority of data modernization and AI strategy engagements are now originating from the office of the CFO, reflecting an expectation of quantifiable bottom-line value rather than technology-led investment cases. Generative AI and agentic tools are already identifying redundant functionality and consolidating what had been 16 applications doing the same thing.

The agentic modernization approach changes team composition substantially, shifting toward business people building on well-engineered platforms with engineers in a coaching role rather than as hands-on builders, and compressing speed to prototype from long sprint cycles to hours or days. Five capabilities are identified as critical for an agentic code-assistive modernization tool: logic extraction, code conversion with target optionality, human-readable documentation, synthetic test data and test case generation, and continuous testing with a feedback loop. Such a tool should also produce a common data model, schema, API dependency mapping, and data footprint discovery, partly because legacy applications often have only half the organization understanding what they actually do.

Digital transformations fail because people lose faith rather than because of technology failures, making change management and internal activation as important as the technical work. The recommended starting point is a pilot application with a wide impact radius that everyone in the organization recognizes, in order to build trust early. A three-part framework for organizations feeling behind covers finding the most experimental business team already tinkering with tools, identifying a sophisticated and extensible platform that accelerates deployment, and assessing the maturity of supporting engineering capabilities. Measuring continued usage rather than just initial adoption across lines of business is identified as one of the most powerful ways to advance an AI program, and forward-deployed engineers serving as activation leads are currently among the most popular mechanisms for driving that sustained engagement.