If you own a system built on WebForms, VB6, Classic ASP, Access, or FoxPro and you have started asking what it would take to move off it, you have probably been offered an assessment. It takes three or four weeks and produces a document: an inventory of the code, a maturity score, a target architecture, a phased roadmap, and a cost estimate with a wide range and a confident tone.
We think this document is close to worthless, and we want to explain why carefully, because the people selling it are not dishonest. They are answering the wrong question.
A reading, not a measurement
An assessment estimates the effort to rewrite a system by reading it. Somebody counts screens, forms, stored procedures, and lines of code, applies a productivity factor per unit, and adds contingency. On a well-structured modern codebase this works tolerably. On a 2004 VB6 application it does not, for a reason that becomes obvious the first time you try to migrate anything.
The cost of migrating a legacy module is dominated not by its size but by how much undocumented behavior it contains: the date-rounding rule added in 2009 that three customers' invoices depend on, the global variable that a report reads after a form sets it, the FoxPro index that is silently rebuilt by a nightly batch. None of that is visible from an inventory. It is only visible when you try to make a new implementation match the old one and discover where they disagree.
An assessment cannot see it because an assessment does not try to migrate anything. So the estimate is a guess about the size of the thing that determines the cost, dressed in a spreadsheet.
The roadmap is generic
Read three assessments from three vendors and you will notice the roadmap is the same: stabilize, containerize or lift the database, migrate the "core" modules, then the rest, then decommission. It is the same because it is not derived from your system. It is derived from a template.
A real migration order depends on things like: which slice can be routed separately without a shared session; which tables the slice owns outright versus shares; whether the reporting module reads the transactional tables directly (it often does); and which module has a business owner who will actually test a pilot. You find those out by working in the code, not by scoring it.
The incentives problem
Assessments are usually sold at cost, or below, as a lead-in to the rewrite. That is fine as a business model but it means the document has a purpose beyond informing you: it has to justify the rewrite. Very few assessments conclude "keep this system and put an API in front of it." That is a legitimate conclusion for a lot of mid-market systems and you should be suspicious of any process that cannot reach it.
What to buy instead
The honest way to estimate a migration is to do a small, real part of it under measurement. In two weeks a senior engineer with modern AI tooling can:
- Map the system for real. AI-assisted analysis can produce a first-pass dependency and data-flow map of a few hundred thousand lines in a day. It will be wrong in the interesting places, and a senior engineer walking it with your developer corrects those. The corrected map is the first genuinely useful artifact.
- Put characterization tests on the risky paths. Three to five flows, usually the ones that touch money or a nightly job, recorded end to end so any new implementation can be checked against what the old one actually does. See our note on characterization tests for how.
- Migrate one module. Not a toy. A real module, rebuilt on the target stack, behind a routing shim, passing the tests. This is the measurement: you now know the cost per screen, per report, per stored procedure, in your codebase, with your idiosyncrasies.
- Estimate the next phase with evidence behind it, because there is finally a basis for one.
That is what our codebase assessment is: a short engagement that exists to produce running code and a harness rather than a document. If the migration never happens, you still own a test harness and a map, which are worth having on any system you intend to keep running.
Questions to ask
Whether it is us or anyone else, ask these before you sign:
- Will anything run at the end of this? If not, how will you know the estimate is right?
- Which module will you migrate first, and why that one?
- What happens to the tests you write? Do we keep them, in our CI, in our repository?
- What would make you conclude we should not rewrite this?
- Who, by name, will do the work, and have they shipped on this stack?
If the answers are "no", "we'll decide during the project", "they're internal", "nothing", and "our delivery team", you are buying a document. Sometimes that is what you need for a board. It is not what you need to plan a migration.