CASE STUDY · MODERNISATION
How deep reverse engineering helped Claritev build a confident path to modernization.
- 100%System visibility across undocumented modules*
- 0Critical business rules lost during transition*
01 · PROJECT OVERVIEW
When half the system only lives in the code.
Claritev’s existing application had evolved over time. Parts of it were well documented; other parts had no documentation at all their behavior existed only in the code, understood by whoever had last touched it.
That was manageable while the application was running as-is. It became a real risk the moment Claritev decided to rebuild it. A modernization effort can only be as accurate as the team’s understanding of what the old system actually does including the parts nobody wrote down.
Brandsmashers was invited to close that gap: build a complete, unified understanding of the existing system, documented and undocumented alike, that Claritev’s BA team could design the new model against.
- 1Partial documentation covering some modules, silent on others
- 2Business logic and validation rules that existed only inside the code
- 3No single reference the BA team could design the new model against
- 4Risk of the new build missing functionality nobody remembered to specify
02 · THE CHALLENGE
Turning undocumented code into requirements someone could build from.
The hard part wasn’t reading code it was making sure nothing that mattered got lost between "how the old system behaves" and "what the new system should do."
- PROBLEM 01Documentation gaps
Whole modules had no written record of why they worked the way they did
- PROBLEM 02Logic buried in code
Business rules and validations existed only as conditionals, not as requirements
- PROBLEM 03Technical-to-business gap
The BA team couldn’t refine requirements from raw code it needed translation
- PROBLEM 04Single source of truth, missing
No document combined the known and the newly-discovered into one reference
The risk wasn't in what was documented. It was in what everyone had simply stopped writing down.
03 · THE PROCESS
Existing knowledge first, then reverse engineering, then translation into requirements.
- 01Studied all existing documentation
Reviewed every available document to establish the application’s baseline structure, known flows, and major functional areas and to see exactly where the gaps were.
- 02Reverse engineered the undocumented modules
Read through code to uncover embedded business logic, mapped workflows and data movement, identified how modules interacted, and surfaced rules and validations that existed only in code.
- 03Translated technical logic into business language
Converted every technical finding into clear, plain-language explanations for the BA team, so requirement discussions could move without a technical bottleneck.
- 04Aligned old behavior with new expectations
Worked with the BA team to clarify what needed to be carried forward as-is, improved, or redesigned in the new model.
- 05Built structured, usable documentation
Combined existing documented knowledge with reverse-engineered findings into process flow diagrams, module descriptions, simplified logic write-ups, sequence diagrams, and dependency maps.
- 06Delivered a single reference set
Consolidated everything into one complete documentation package to guide the next phase of development, testing, and decision-making.
- 1→Existing documentation review
- 2→Reverse engineering of code
- 3→Business logic discovery
- 4→Workflow & data mapping
- 5→Technical-to-business translation
- 6→BA requirement support
- 7→Process & sequence diagramming
- 8→Dependency mapping
- 9→Unified documentation set
- 10Handover for new model development
04 · RESULTS
What changed.
The system stopped being something only a few engineers understood and became something the whole team could design against.
| BEFORE | AFTER |
|---|---|
| Documentation covering only part of the system | One complete reference spanning documented and undocumented areas |
| Business logic locked inside code | Logic translated into plain-language explanations for the BA team |
| Requirement discussions slowed by technical gaps | Full visibility enabling fast, accurate requirement gathering |
| Risk of missing functionality in the rebuild | Confidence that nothing from the old system got lost |
| Knowledge scattered across code and partial docs | A single, unified source of truth for development and testing |
- Improved requirement accuracy
The BA team worked from real system behavior, not assumptions
- Better business-technology alignment
Everyone designed the new model from the same understanding
- Reduced duplication and confusion
One documentation set, not competing versions of the truth
- Smoother planning for the new model
Development could start from clarity instead of discovery
- A structured, risk-reduced modernization path
Claritev could move forward without hidden unknowns
05 · DELIVERABLES
What we delivered.
- Documentation reviewFull assessment of existing documentation and known system flows
- Reverse-engineered findingsBusiness logic, workflows, and validations extracted directly from code
- Business-friendly translationTechnical logic rewritten in plain language for the BA team
- Process flow diagramsVisual mapping of how the application actually operates
- Sequence diagramsStep-by-step interaction flows across modules
- Dependency mappingHow modules and data depend on one another
- Unified documentation setOne reference combining existing and newly-discovered knowledge
- Discovery
- Reverse engineeringCode analysisLogic extraction
- Documentation
- Process flowsModule descriptionsSequence diagramsDependency maps
- Collaboration
- Direct support to Claritev’s BA team during requirement refinement
- Output
- Complete reference set for the next phase of development
WHY IT WORKED
Clarity before code.
Brandsmashers didn’t start writing the new application it started by making sure everyone actually understood the old one. Combining existing documentation with hands-on reverse engineering meant nothing about the current system’s behavior was left to guesswork, and nothing got missed when Claritev’s BA team sat down to define what came next.
That’s the pattern that works best ahead of any modernization effort: understand completely before you rebuild. The documentation set built here became the foundation Claritev’s teams could plan, build, and test against with a clear picture of the past guiding a confident step into the future.
YOUR TURN
Rebuilding something and not sure what the current system actually does?
Brandsmashers Tech provides system analysis, reverse engineering, and documentation support for teams modernizing legacy applications. Tell us what you’re rebuilding and we’ll tell you how we’d approach it.