Legacy Codebase Assessment
Ends with a running module, not a deck
The honest answer to "how long will this take?" cannot come from reading code. It comes from migrating some of it under measurement. The assessment is our usual first engagement: typically about two weeks of senior-engineer time, billed hourly like all of our work, ending with a dependency map, a characterization-test harness, one module migrated and running, and a written plan your team owns.
What we do
- Map the system for real. Read-only access to source, schema and a running environment. AI tooling produces a first-pass map of modules, shared state, database coupling, integrations, scheduled jobs and reports; a senior engineer walks it with your developers and corrects it. The corrections are where the value is: the map the tool produced of your system is wrong in the places that will hurt.
- Characterize the risky paths. We pick the three to five highest-risk flows, usually the ones that touch money, compliance or a nightly job, and build characterization tests that record what the system does today. AI generates them in bulk; engineers curate them, because most generated tests assert incidental behavior and a few assert the contracts your business runs on. Distinguishing those is the work.
- Migrate one real module. Not a toy. One module rebuilt on the target stack behind a routing shim, passing the harness. This is what turns an estimate from a guess into a measurement: the real effort per screen, per report, per stored procedure, in your codebase.
- Write the plan. Slice order, effort ranges per slice, the data-ownership calls, and a recommended first slice, delivered with the map, the harness and the migrated module in a repository you own.
Who this is for
A company with a system it depends on, built on ASP.NET WebForms, Visual Basic 6, Classic ASP, Microsoft Access or Visual FoxPro, that has discovered the automated migration tools either do not support the stack or produce code nobody wants to own. Typically 50 to 500 employees, one to three internal developers who know the system, and a leadership team that wants an estimate it can believe.
How we work with you
A typical assessment runs two weeks: the first days ingesting source and correcting the map with your developers, the middle stretch building the harness on the riskiest paths, the last days migrating the module and writing the plan. What we need from you is modest: source access and a running environment (a VM snapshot is fine; a FoxPro folder on a share is fine), two to four hours of your developers' time across the engagement, and a decision-maker available at the end to hear what we found.
What it is not
- Not a slide deck with a maturity score.
- Not a full rewrite estimate from a reading of the code; it is an evidence-based estimate for the next slice and a range for the rest.
- Not an audit-to-sell-a-rewrite. If the right answer is to keep the system and put an agent access layer in front of it, the plan says so.
- Not a security audit, although we will report anything alarming we see.
Next step
Contact us with the stack, the rough size, and what is forcing the question now. If an assessment is not the right next step, we will say so in the reply.