Key outcomes
Reverse-engineered the agreed SAP Commerce (Hybris) customization and integration scope across every major commerce domain.
Reduced documentation effort by approximately 80–90% compared with the previous manual analysis approach.
Produced a domain-oriented engineering knowledge base containing more than 1,500 documented capabilities, 300+ endpoints and 800+ diagrams.
Delivered practical outputs for both engineers and AI-assisted development, including a searchable portal, capability catalog, grounded Q&A and MCP interfaces.
The challenge
During an AI-first software delivery assessment, SAP Commerce (Hybris) emerged as the most challenging application in Unieuro's modernization landscape. As with many enterprise commerce platforms, Unieuro's SAP Commerce implementation had evolved over more than a decade. New business capabilities, integrations and customizations had accumulated release after release, while documentation gradually fell behind the software itself, making it difficult to understand how the platform actually behaved.
As a result, answering seemingly straightforward questions, such as “Which systems participate in checkout?”, “Which services determine product availability?” and “Which pricing rules are still active?”, often required reading code, inspecting configuration, consulting multiple specialists and validating assumptions across several teams.
For a modernization program, where teams need to understand the existing system before deciding what to rebuild, replace or retire, this created an immediate problem.
Rather than investing months in manual documentation, Thoughtworks and Huware explored a different question: Could reverse engineering become a repeatable engineering activity instead of a one-off documentation exercise?
The solution
Thoughtworks and Huware approached the problem as an engineering challenge rather than a documentation exercise. Instead of relying primarily on interviews or manual analysis, the team combined a lightweight reverse-engineering accelerator with software engineering practices developed through large-scale modernization programs.
The accelerator automates repetitive analysis tasks, such as extracting business capabilities, mapping APIs, identifying integrations and generating structured documentation—while engineers validate the results, resolve ambiguities and capture business intent. This allows teams to spend their time understanding the system rather than manually collecting information.
The goal was not to document legacy software. It was to create a shared understanding of how the platform actually behaves, which engineering teams can use to plan, build and modernize software with confidence.
The engagement followed a repeatable engineering workflow:
The first step establishes a high-level view of the application before analyzing individual components. Repositories, business domains, integrations, runtime dependencies and key user journeys are identified to define the boundaries of the analysis and create a common reference point for product, architecture and engineering teams.
The accelerator analyzes multiple sources simultaneously, including Java code, Spring configuration, database schemas, APIs, user interfaces, runtime behavior and existing documentation, to reconstruct how each business capability actually behaves.
Looking across multiple evidence sources is essential. No single artifact fully describes a large enterprise application, but together they expose business rules, decision logic and system interactions that would otherwise remain hidden.
The extracted information is transformed into structured business capabilities using predefined documentation schemas rather than free-form AI generation.
AI accelerates extraction, summarization and organization, while engineers and domain experts review every capability, resolve inconsistencies and validate the final result before publication. Every documented capability maintains traceability back to the technical artifacts from which it was derived, allowing teams to verify findings whenever needed.
Instead of producing static documents, the accelerator publishes structured outputs that become part of the engineering workflow.
Before this engagement, documenting a single commerce domain typically required weeks of manual investigation involving multiple specialists. By combining automated extraction with structured engineering review, documentation became a repeatable engineering activity, reducing effort by approximately 80–90% compared with the previous manual approach while significantly reducing dependency on scarce domain experts.
Three design decisions proved particularly important:
Focus on business behavior, not implementation: The accelerator identifies business capabilities, decision logic and functional behavior instead of reproducing classes, methods and configuration. This creates documentation that supports engineering decisions.
Keep every conclusion traceable: Every capability links back to the code, configuration or runtime evidence that supports it. Engineers can verify the source of each conclusion when needed.
Keep engineers in control: Engineers define the documentation structure and remain responsible for validating results and approving the final knowledge base. AI accelerates repetitive analysis and content generation.
Large legacy systems already contain the knowledge needed for modernization, they simply don't expose it in a form engineers can efficiently consume. Our objective wasn't to generate documentation; it was to make that knowledge searchable, traceable and reusable so that both engineering teams and AI assistants could work from the same trusted context.
Engineering outputs
A human- and LLM-friendly context library containing detailed business capabilities, APIs, integrations, diagrams and decision logic. Engineers navigate the platform through business concepts rather than source code alone, while AI assistants consume the same validated context through grounded search and RAG and MCP interfaces.
A fine-grained inventory of business capabilities that supports scoping, dependency analysis, roadmap planning and modernization prioritization.
Rather than asking "Which classes implement this functionality?", teams can ask, "Which business capabilities are involved, what systems do they depend on and what would change if we modernized them?"
A high-level architectural view of domains, integrations and major business flows, providing engineering leaders, architects and product teams with a shared understanding of the application landscape.
The MVP initially focused on product onboarding, product enrichment, pricing, ETL integrations, exports and warranties. Following its success, the same approach was extended across the agreed SAP Commerce customization and integration scope, including availability, tax, cart, promotions, checkout, orders, payments, fulfillment and storefront.
The resulting engineering knowledge base contains more than 1,500 documented capabilities, 300+ endpoints and 800+ diagrams, covering the agreed modernization scope while reducing documentation effort by approximately 80–90% compared with the previous manual approach.
From understanding the system to planning modernization
The reverse engineering work did more than generate documentation. It gave Unieuro's modernization programme a shared understanding of how the platform actually behaves, allowing engineering teams to move from discovery to planning with significantly greater confidence.
Rather than spending weeks reconstructing existing functionality before making decisions, product managers, architects and engineers could work from the same factual view of the platform.
Making hidden complexity visible
One of the most valuable outcomes was exposing business behaviour that had never been formally documented.
Analysis of the order placement journey, for example, revealed multiple parallel process variants involving different external systems, timeout conditions, delivery-specific rules and fulfilment paths. What initially appeared to be a single business flow turned out to be a collection of distinct execution paths with different operational implications.
Instead of discovering this complexity during implementation, engineering teams could identify the dominant business path, separate it from less common variants and plan modernization activities accordingly.
The biggest change was that we stopped debating how the platform worked and started planning modernization from a shared understanding of the system. Product, architecture and engineering teams could finally discuss priorities based on evidence rather than assumptions, significantly reducing our dependency on individual experts.
Faster onboarding for engineering teams
Understanding a large legacy platform often requires extensive SME shadowing and code exploration. The engineering knowledge base shortens that learning curve by giving new team members a business-level view of the platform, with traceable links to implementation details when needed.
The same structured context gives AI coding assistants validated business knowledge to work from, rather than relying on raw source code alone.
The same structured context also provides AI coding assistants with grounded information about the application, enabling them to reason over validated business knowledge rather than interpreting raw source code in isolation.
A repeatable approach for large legacy applications
Although developed on SAP Commerce, the approach is not specific to Hybris.
The same engineering workflow can be applied wherever business-critical knowledge is distributed across source code, configuration, integrations and a small number of specialists. Large Java applications, custom enterprise platforms and long-lived monolithic systems present many of the same challenges.
By combining automated analysis with engineering validation, teams can establish a shared understanding of an application before beginning modernization, reducing delivery risk while accelerating planning and implementation.
Retail is entering a new phase where AI will fundamentally change how software is built, evolved and maintained. The real opportunity isn't simply applying AI to software development, it's combining deep retail expertise with trusted engineering context. Together, Huware and Thoughtworks are helping retailers modernize existing platforms while preserving the business knowledge that makes them unique.
Looking ahead
The Unieuro engagement demonstrated that reverse engineering can become a practical starting point for modernization rather than a lengthy preliminary activity.
The same engineering approach is now being applied to other large enterprise applications where understanding existing business behaviour is the first prerequisite for change.
For retailers in particular, years of customization have created valuable competitive differentiation embedded inside commerce platforms. Preserving that knowledge while modernizing the underlying technology has become one of the industry's biggest engineering challenges.
This engagement complements Unieuro's published data-platform modernization story, same AI-first program, different stream. For more on whether generative AI can help reverse-engineer a system even when its code isn't available, see this related piece.
