Digital transformation
The evolving landscape of the sports industry
Let’s be honest about something that gets glossed over in most platform migration stories. There’s always something hiding beneath the surface waiting to quietly break things after go-live.
Often, it’s the business logic written decades ago by long-retired engineers. They knew what it did, so they never documented it, and vital logic that works just fine in the legacy codebase gets missed — until it surfaces as production bugs after the migration.
To show you how we tackle this challenge during a large-scale migration, we’ll explore an example at a leading sports data and technology company.
The company was modernizing a critical platform, but the build wasn’t progressing fast enough to meet the contractual deadline for retiring the legacy platform. The delays were largely due to the months of effort required to manually extract business logic from the legacy Java codebase for each of the 80+ sports that had to be onboarded.
So, Thoughtworks partnered with AWS ProServe and the company’s teams to accelerate business logic extraction using AI. But we knew we couldn’t simply point AI at the problem and say, “Fix this.” We know how that story ends: confident-sounding documents that contain subtle errors that reveal themselves in production — the same migration problem, just with a different source.
Harnessing AI to accelerate platform modernization
To ensure AI-powered acceleration didn’t come at the expense of accuracy and consistency, we created a framework following similar principles to harness engineering, supporting AI to do its work in a controlled, repeatable way by implementing four key components.
1: Golden Rules keep AI on track
We formalized Golden Rules to prevent AI from inventing things or making assumptions. One was that if the code was ambiguous, the AI had to flag the ambiguity in its output so a human expert could resolve it.
To achieve this, every extracted fact carried a green, amber or red confidence marker. Source traceability is the real anti-hallucination mechanism. Every extracted fact carries a file:line reference back to the legacy code. These were essential for overcoming the most critical blocker to migration speed: limited SME availability. By highlighting exactly where SMEs should direct their expertise, they were freed from manually checking every output.
Our SMEs can’t spend their time investigating every fact extracted by the AI. Now, they can focus on resolving the ambiguities that matter, so we can onboard more sports faster and give our customers the reliable, accurate and consistent data services they need.
2: A phased approach separates what’s expensive from what’s fast
Analyzing a complex Java codebase is a time-consuming and expensive process. Done properly, for one sport and one module, it takes 30–60 minutes of AI processing, with human checkpoints along the way.
But turning structured data into a readable specification document is fast (and therefore relatively cheap). Given the right input containing extracted context, AI can generate a comprehensive spec in five to 15 minutes. And if the format needs changing or a section needs restructuring, it’s easy to just rerun the generation step, with no need to re-analyze the codebase.
This makes it possible to extract business logic from multiple sports in parallel, saving even more time. A new sport can go from zero to implementation-ready specs with around 30 to 45 minutes of setup, four to six hours of parallel extraction and six to eight hours of SME review.
3: A shared context layer keeps AI informed
Lost context is one of the biggest barriers to AI acceleration. Every session starts from scratch, and without any context, AI improvises, leading to inconsistent, unusable results.
The shared steering files played a big role in providing context for every AI session. We also maintained architecture decision records (ADR) that captured every significant structural choice, so the AI followed decisions the team had already made, rather than guessing.
This shared context layer also meant that the benefits of every improvement decision were inherited by each future sport, amplifying investments in quality.
4: Code is generated directly from specs
The purpose of the business logic extraction was to close a loop that most migrations don’t: The legacy codebase goes in, structured specifications come out, and the new platform is built from the specs, rather than guesswork or memory.
Our approach meant that the specs were structured enough to feed directly into code generation. The team building the new platform could build from a reviewed description of the behavior encoded in the legacy system.
Specs from code were also more likely to surface behavior nobody had written down. The behavior was translated into a structured spec that could be reviewed and deliberately carried forward or changed.
Accelerating migration without compromising accuracy
The shift to an AI-assisted reusable framework massively reduced the company's migration timelines. The framework turned undocumented tribal knowledge into structured, reviewable assets that directed SMEs' attention to where it was actually needed.
By applying AI within this framework, a 10-sport migration program that would have taken two to three years was reduced to around three to four weeks of total effort — or as little as one to two days with parallel execution. Onboarding time for a new sport dropped from 10 to 15 weeks to less than a day, because each sport inherits shared templates.
We had a lot of important but undocumented logic hidden in our legacy codebase, which would have taken many months of engineering effort to uncover manually. Now, we have a fast, systematic way to extract business logic and decide what to take with us to the new platform, what needs to change and what we don't need.
The principles behind this framework apply to almost any large-scale modernization program. But for this to work at enterprise scale, several organizational conditions are essential:
Shared context ownership: A single team stewards the reference materials, so output quality stays aligned.
SME review capacity: Within a stable framework, extraction and generation will quickly gather pace, and review must keep up or program timelines will slide.
Aligned success criteria: To prevent costly rework, you need upfront agreement on what constitutes a complete spec, which edge cases must be captured and which inconsistencies should be flagged.
Cross-team visibility: Information silos create the most expensive delays, so keep everyone aligned on extraction sequencing and the specs they'll implement against.
Codebase stability: When source code is in flux, you're trying to analyze a moving target. Brief freezes during analysis windows allow you to build a focused understanding of the codebase.
From experience
Even the best AI can still misread the intent behind dense legacy code. Guardrails reduce this risk, but they don't eliminate it. And SME review can still create a bottleneck. If extraction runs in parallel but SME capacity doesn't, review becomes the pacing function and timelines stretch.
Plus, while a consistent spec structure improves speed, it doesn't guarantee correct behavior. A spec can be complete but still carry forward a legacy bug or outdated rule.
And finally, there's a maintenance cost to keeping the reference materials up to date; if the shared context drifts, the output quality drifts with it.
Overall, the lesson is this: use AI to accelerate disciplined engineering work and expert human review, not to bypass them.
