The situation
A critical application with no instruction manual
Our client had relied on a custom C# desktop application for more than 25 years. Its original database was Microsoft SQL Server. There was no functional documentation, and no functional experts were available to explain how every form and workflow should behave.
Several functions and forms in the old application were also broken or buggy. Replacing the system meant first understanding its behavior, identifying its defects, and determining what the new application needed to do.
The challenge
The old system could not always serve as the answer key
Undocumented behavior
With no specifications or functional experts, the team had to investigate the application and its workflows directly.
Existing defects
Some forms and functions did not work correctly, complicating comparisons between the original and replacement.
Comparative QA
Differences between the two applications required investigation before they could be classified as new defects or old ones.
Our approach
Investigate, repair, compare
- 01
Study the legacy system
We examined the existing application, its forms and workflows, and its SQL Server database to reconstruct the functionality needed in the web application.
- 02
Build the web application
We developed a browser-based replacement using Next.js and other modern web technologies.
- 03
Test both applications side by side
Our QA team compared forms, functions, and workflows to identify differences and investigate their causes.
- 04
Repair the original where necessary
When broken legacy functionality blocked meaningful comparison, we fixed parts of the C# application. That gave the team a more reliable baseline for QA and comparative analysis.
“To properly test the replacement, we first had to fix parts of the application we were replacing.”
The outcome
A modern application, backed by a clearer understanding of the old one
The project produced a Next.js web application and a more dependable basis for validating its functionality. Investigating and repairing the original system helped the team compare behavior without simply carrying known defects into the replacement.
The experience illustrates a practical lesson for legacy modernization: when an older application is undocumented and unreliable, comparative QA may require engineering work on the original system too.