Case Studies

A global technology services firm saw a strategic opportunity to accelerate its digital transformation and legacy modernization work with generative AI. The initial idea was a chat interface layered over an existing internal tool. That would have been useful for navigation and summarization, but it would not produce the deep architectural insight needed to guide transformation decisions on unfamiliar enterprise estates. The harder problem was codebase understanding: extracting business flows, system capabilities, dependencies, and modernization options from legacy systems where documentation was incomplete or out of date. Senior architects were spending weeks per engagement building that understanding manually. The firm needed a more ambitious approach that could support commercial pilots, not just a demo.

A Tier 1 European bank was in the middle of a high-profile post-merger integration. The target state was a single digital platform replacing nine disconnected legacy systems across COBOL, legacy Java, and manual operational processes. Nine months into the programme, backend integration work had not materially progressed. The most difficult part was not the user interface. It was the orchestration behind it: asynchronous risk checks, factoring workflows, state transitions, exceptions, and hand-offs that had accumulated across years of legacy operations. The programme was exposed to delivery pressure, commercial escalation, and loss of client confidence.

Multiple enterprise clients were under pressure to respond to AI and GenAI. Boards and executive teams wanted visible progress, but the organisations did not yet have a clear view of where AI would create business value, which use cases were technically feasible, or whether their data and architecture were ready. The risk was not only moving too slowly. It was investing in expensive, hype-driven experiments where traditional software engineering, analytics, or conventional machine learning would have been simpler and more reliable. The clients needed a pragmatic assessment: where AI was justified, where it was premature, and where it was the wrong tool entirely.

Enterprise AI coding tools are useful at the local code level, but they are often blind to the broader enterprise system. They can suggest changes inside a repository, yet struggle to understand how that repository connects to legacy platforms, integration flows, operational processes, architecture decisions, and undocumented business rules. That creates a context gap. In large organisations, the real system is distributed across code, documentation, tickets, platforms, tribal knowledge, and production behaviour. Without that context, AI-assisted modernization can produce confident local changes that create cross-system risk.

A major European insurance group was dealing with technology fragmentation across international subsidiaries. Regional entities were constrained by rigid COBOL-based core systems that made new product launches slow and expensive. At the same time, group headquarters was carrying a fragmented estate of legacy Java applications with accumulating technical debt. The problem was both local and group-wide. Each country had specific product, regulatory, and operational requirements, but the group needed a platform architecture that could be reused across borders rather than rebuilt from scratch for every entity.

Multiple enterprise clients across fintech, banking, insurance, retail, and adjacent sectors were preparing digital transformation or modernization programmes. The business intent was clear, but the technical path was not. They lacked a defined target architecture, a realistic roadmap, and a delivery model that could survive contact with the existing legacy estate. Before committing budget, leadership needed to know whether the proposed direction was technically feasible, what kind of team would be required, and how much effort was realistically involved.

Private equity buyers were evaluating technology targets across AdTech, telecom, AI, and financial services. The targets often presented strong AI/ML narratives, but the buyers needed to understand what was real: model maturity, MLOps capability, architecture scalability, engineering quality, team depth, and the credibility of the product roadmap. Standard data-room review was not enough. The risk sat in the technical detail: whether the AI claims were defensible, whether the architecture could scale, whether the team could execute the roadmap, and which gaps would become post-acquisition investment requirements.