Modernization
Undocumented systems: the specification comes from the system itself
When documentation is missing or does not match reality, the schema and the behavior of the system rule. We measure them before quoting.
The problem
Documentation rarely keeps up
In the analysis of a railway system (client not named) the inventory reached 2,009 objects, 159 tables, 1,238 columns and 155 foreign keys, with 54 composite primary keys. The documentation underestimated the real size of the system.
How we do it
From the system to the specification
Schema first
We read the real structure of the database: tables, columns, keys and relationships.
Observed behavior
Screens and rules are documented from how the system responds.
Tests
The specification comes with tests that verify it.
Inventory of differences
What the system does is compared with what the existing documentation says.
What you keep
Documentation that actually describes your system
Even if you do not continue with a migration, you keep the specification, the tests and the inventory of differences.
Frequently asked questions
Do you need my real data?
No. We ask for help pages or screenshots, the table structure and a functional owner.
Does it work for Java and .NET?
Yes. The method starts from the schema and the behavior, not from the language the system is written in.
How long does it take?
The measured sample is delivered in days, not months.
Next step
Start with a measured sample: 5 to 10 screens of your system turned into a verifiable specification, with tests and an inventory of differences.