Case study
qlity
In developmentMoves the business logic in stored procedures into code, with proof
Takes an inventory of SQL Server stored procedures, translates them into readable C#, and proves with real calls that the new code produces what the old procedure did. What it cannot translate, it refuses, and says why.
- 1021 / 1041
- mojoPortal procedures generated and proved equivalent
- 635 / 682
- on DNN Platform, each against its own procedure
- Zero calls
- the tool never sends anything off the customer's machine
Why it started
A decade-old .NET and SQL Server system with thousands of stored procedures is normal; business rules settle there over time. Code that never passes through review, tests or version control becomes the wall in front of a cloud move, a split into services and AI-assisted development: tools cannot touch code they cannot see. The migration tools on the market translate a procedure into another database's procedure, which moves the problem. Nothing translated a procedure into application code and proved it equivalent.
Key decisions
- 01
The product is the proof, not the translation
An enterprise team does not delete a twenty-year-old procedure on a translation that is probably right. So the proof layer was built before translation: the generated code and the old procedure run side by side with the same calls on a disposable copy of the database, and both the result and the change left in the database are compared.
- 02
Refuse rather than approximate
T-SQL's NULL logic has three values, C#'s two. Writing a condition as it reads returned a row the procedure did not, on a call with a NULL parameter — measured. The generated code therefore carries T-SQL's meaning explicitly, and every construct that cannot be written with that meaning is refused with its reason.
- 03
One engine, the customer's shape of code
Every team wants different code: its own repository pattern, its own layers, its own file layout. The engine produces an intermediate representation and templates print it as the team's code. The variable part stays in one layer, so the product is the same at every customer; the customer-specific work is consulting that carries the code into the existing project together with the team.
- 04
The data never leaves the machine
A single-file command-line tool runs on the customer's own machine and makes no outbound calls. The first question from anyone connecting a closed tool to a production database is "what does it send?"; the answer is ready from the start.
Where it is today
The inventory and proof layers are done and code generation is moving forward. The Dapper and EF Core targets are measured on public schemas, and every generated method is proved against its own procedure. Next: more T-SQL constructs, sources beyond T-SQL and targets beyond C#.
The product itself
The feature list, screenshots and documentation live on the product's own site.