Balfour Beatty’s data team was spending 80% of its time keeping a decade-old Informatica estate alive. The work that mattered, predicting site accidents, protecting project margins, sat on the backlog. The interesting part of this case isn’t the speed numbers, though they’re stark. It’s what a construction firm decided to do with the time it got back.
There’s a version of the enterprise data story that never makes it into the vendor deck: the team isn’t slow, and it isn’t short on ideas. It’s pinned. Every hour goes to keeping yesterday’s pipelines running, which means tomorrow’s work, the analysis that would actually move the business, never starts. Balfour Beatty had reached that state precisely.
The firm builds nuclear power stations, high-speed rail, and major civil infrastructure. Its 40-person data team was spending roughly 80% of its time on routine pipeline maintenance, with about a fifth left for anything strategic. Mark Hume, Head of Data, was blunt about how the rest of the business saw them. The team was viewed as a blocker, he said, because the backlog kept growing and the business had what he called an insatiable desire to consume data.
The Constraint Was the Legacy, Not the Ambition
What pinned the team was a specific piece of inheritance: 1,300 Informatica PowerCenter pipelines, a decade old, supporting 800 active reports across finance and procurement. After PowerCenter reached end of life, that estate stopped being just technical debt and became a live cybersecurity liability. It had to move. The problem was that moving it had been, in any practical sense, impossible.
The logic of each pipeline was buried in opaque XML that a senior engineer had to reverse-engineer by hand. One pipeline took about a week. Multiply that across 1,300 and the migration becomes a multi-year programme that no team running at 80% maintenance can ever actually start. Hume’s team had nearly given up on it, they’d begun rewriting SQL to pull and model the data themselves, case by case, rather than wait on a migration that never came.
That’s the shape worth noticing. The blocker wasn’t complexity the team couldn’t handle. It was volume of manual work the team didn’t have the hours to absorb.
Three Use Cases, Deliberately Chosen
Hume didn’t run a tidy demo. He picked three real problems off the backlog, each testing a different claim, because a proof of concept that only proves one thing isn’t worth much in a regulated environment.
The first was the Informatica migration itself. Maia’s Migration Agent parsed the opaque XML logic that had taken a senior engineer a full week, and did it in six minutes. Context Files carried Balfour Beatty’s own naming conventions and domain standards into every output from the start, so what came out matched their architecture rather than a generic template. The multi-year programme turned into a realistic six-month roadmap, which for the first time made the compliance deadline achievable.
The second was everyday data engineering, the real drain, as it turned out. Not the hard logic, but the sheer volume of routine requests. Ingesting and modeling a standard data source was a full day of senior engineering on paper, but silos and handoffs between teams stretched it to weeks. Project managers were getting site performance data after the window to act on it had already closed. Using natural language prompts, engineers can now have Maia build the end-to-end pipeline, orchestration and documentation included, in hours. As Hume put it, if a build that takes three weeks now takes three hours, that frees the team to do the strategic transformations and accelerate time-to-value for the business.
The third is the one that’s easy to underrate. Even working pipelines were, in Hume’s word, operationally invisible. Data landed in the warehouse labelled by technical source, “schema System A,” “schema System B”, which made sense to IT and nothing to a health-and-safety manager or a finance director. At one point a “tickets-per-customer” report broke simply because IT meant external client by “customer” and the business meant internal colleague. Using Maia’s Context Engine, the team built a vocabulary layer that bridges the two languages, so Maia can tell whether a given data point is a safety metric, a financial record, or a project KPI. The result is what Hume calls the move from a “Black Box” to a “Glass Box”: a tiered environment where a finance director sees group finance data and a project manager sees only their own site’s numbers.
The Quote Worth Sitting With
The line that lands hardest from the Balfour Beatty engagement isn’t about speed. It’s about skepticism. Hume’s summary of the proof of concept was that he’d been skeptical going in, and that Maia had clearly lived up to what it promised.
That’s worth reading slowly, because it’s a senior data leader in a heavily governed industry conceding a point he plainly expected not to have to concede. Skepticism is the default posture for anyone who’s sat through enough AI demos. Hearing it give way on real backlog work, rather than a curated showcase, is the actual signal.
The second thing Hume said reframes the whole exercise. He described Maia as extra staff doing the heavy lifting, not taking away anyone’s role, but enhancing it, giving the team the headspace to think about bigger issues instead of the routine. That’s the point the speed numbers serve. The six minutes matter because of what the week they replaced was costing the team the chance to do.
What the POC Was Really Testing
Read as a story about one contractor, this is a migration anecdote. Read structurally, it tested three separate questions at once, which is why Hume chose three use cases rather than one.
Does agentic AI deliver real speed on work that’s been manual for years? The week-to-six-minutes result on XML reverse-engineering answered that. Can it absorb the high-volume routine work that actually pins a team, not just the showpiece-hard problems? The three-weeks-to-three-hours pipeline delivery answered that. And can it do something the speed framing misses entirely, make data legible to the people who need it, not just faster to produce? The Context Engine work answered that.
Three problems off a real backlog, one architectural pattern, one consistent answer. That’s what a proof of concept is supposed to look like.
What Comes Next
The endgame for Balfour Beatty was never the migration. It was flipping the 80/20 ratio so the team could put its time where the business actually needs it: safety. With a clean, automated data foundation, the team can move from retrospective reporting toward predicting and preventing incidents, flagging dangerous weather patterns or equipment anomalies before they cause harm, and rehearsing complex crane movements and site operations digitally before anyone executes them physically.
For a firm that builds nuclear power stations and high-speed rail, that’s not an efficiency story. It’s the whole point, and the migration was only what stood in the way of it.