An estimate is a model with assumptions attached, and the useful question is never just "is the number big or small" -- it is "what is the number built on." Modernization estimates are worth having. Good estimates exist. So do thin ones. The reader's job is to tell the difference before the number becomes a budget.
This is a buyer's guide for legacy .NET and SQL Server modernization estimates -- whether the estimate came from an outside vendor or your own team. It does not tell you what modernization should cost; cost depends on a system we haven't seen. It tells you what a good estimate names, what commonly gets left out, the warning signs, and the questions that surface the assumptions before they surface themselves.
The number may be honest and still be incomplete. The dangerous estimate is rarely the expensive one. It is the one that looks clean because nobody has opened the part of the system where the bodies are buried.
Why estimates look cleaner than the work
Estimates get tidy when the messy parts are outside the frame. It usually isn't bad faith -- it's scope. An estimate built quickly tends to cover the visible system: application code changes, a runtime upgrade, hosting, some testing, project management, deployment. The understatement happens at the edges that don't show up in a quick look:
Scope is drawn around application code, and the database is assumed stable.
Integrations are counted, not understood.
Testing is named ("testing included") but not scoped.
Cutover and rollback are treated as deployment details rather than workstreams.
Stakeholder availability is assumed; unknowns are priced as if they were known.
Unsupported dependencies and undocumented behavior are discovered late, after the number is set.
"Testing included" is the tell. It can mean a full regression plan with reconstructed test data and a UAT cycle (user acceptance testing -- the business confirming the system still does its job). It can also mean someone clicked around on a Thursday. The estimate doesn't say which, and the gap between those two readings is months.
What a good estimate names
A strong estimate is recognizable less by its number than by what it is willing to be explicit about. It identifies:
What systems are in scope -- and, just as important, what is explicitly out of scope.
SQL Server and data-layer dependencies, and integration dependencies.
The testing approach, the deployment/cutover approach, and an actual rollback plan.
Data migration and reconciliation assumptions; environment, security, and compliance assumptions.
Owner responsibilities -- the client-side time the plan depends on.
The unresolved unknowns, stated as unknowns.
A contingency or discovery reserve.
The single most useful signal: a good estimate does not pretend the unknowns are solved. It names them. An estimate with no stated assumptions and no exclusions has only hidden where the risk lives.
The scope that commonly gets missed
These are the areas that most often sit outside the frame. The field guides cover each one; the point here is to give you the one question that surfaces whether the estimate accounted for it.
Discovery itself. An estimate built without discovery is usually estimating the visible system. Ask: what evidence did this estimate use, and what was reviewed directly versus assumed? The triage checklist is the discovery this question is reaching for.
SQL Server and T-SQL. Stored-procedure logic (business rules that live inside the database, not the application), triggers, jobs, linked servers, and reports often carry behavior the application modernization won't touch. Ask: is SQL Server in scope as architecture, or only as storage? (Depth: the SQL Server modernization risk guide.)
Integrations. File feeds, SFTP, SOAP/WCF (older Microsoft technology for connecting applications to each other), queues, vendor APIs, and hard-coded endpoints set the cutover sequence. Ask: who supplies or consumes data to this system, and do they know they're part of the plan?
Testing and regression coverage. Old systems often lack automated tests; rebuilding them is work, not overhead. Ask: what does "testing included" actually include -- test creation, data, UAT, performance, reconciliation?
Data migration and reconciliation. Data the old system tolerated can break the new one. Ask: how will we prove the modernized system produces the same business result?
Cutover and rollback. Deployment is not cutover. Ask: if the cutover fails, what exactly happens next -- and is there a parallel run, a freeze window, and rollback criteria?
Security and compliance. Modernization can change the control environment. Ask: which controls -- authentication, authorization, secrets, audit logging -- change when the system moves?
Operations and support. A modernized system still has to be run. Ask: who owns it the morning after go-live, with what monitoring and runbooks?
Stakeholder time. SME interviews (time with the people who know how the system actually works), business validation, UAT, DBA and release-management time are real cost even when they're not on the vendor invoice. Ask: whose calendar does this estimate assume is open?
Legacy knowledge risk. Undocumented rules and single-person dependencies turn modernization into reverse engineering. Ask: who can explain why the system behaves the way it does?
None of these line items shows up in a demo or a sales conversation. Each is a place where work the estimate didn't price gets discovered after the budget is set -- which is the difference between a number that holds and a number that moves halfway through the project.
Warning signs
None of these means the estimate is wrong. Each means there's a question it hasn't answered yet:
No discovery phase, and no SQL Server or integration workstream.
"Testing included" with no detail; no rollback plan; no data reconciliation; no plan for reports.
"Lift and shift" offered as a risk reducer without explaining what stays coupled.
No named assumptions and no exclusions.
A fixed timeline attached to unknown scope.
No stakeholder time, and no mention of unsupported dependencies.
No architecture decision record (a written trail of why each technical choice was made) -- or any equivalent, however informal.
If an estimate has no assumptions written down, the assumptions are still there. They're just hiding.
The questions worth asking
Leadership -- before approval
What evidence produced this estimate, and what did the estimator review directly?
What is explicitly excluded, and what unknowns remain?
What could change the estimate by 25% or more?
Is the database being modernized, migrated, or ignored? What integrations are in scope?
What is the testing, cutover, and rollback approach? Who owns business validation?
Are we funding modernization work, discovery work, or both? (If both, say so early.)
Engineering -- before the estimate is trusted
These are facts to gather, and they're the same inventory the triage checklist walks through: application types and runtime versions, project and deployable-unit counts, shared libraries, SQL Server dependencies and stored procedures/jobs. If engineering can't answer these yet, the estimate may still be useful -- just label it correctly: early, partial, and waiting on discovery.
Using an estimate safely
Once you can see what an estimate is and isn't built on, the handling is straightforward:
Treat an early estimate as a hypothesis, not a commitment.
Separate the discovery budget from the implementation budget.
Track the assumptions and validate them; use ranges where the evidence is thin.
Add decision gates, and re-estimate after discovery.
Keep the unknowns visible -- don't let them quietly drop out of the plan.
Don't use a thin estimate as the baseline you later blame delivery against.
The estimate should get sharper as the system gets less mysterious. If it doesn't change at all after discovery, either the first estimate was lucky or the discovery was decorative.
What you receive
One fixed-scope deliverable: the Legacy Modernization Risk Report (LMRR), delivered in 7 to 10 business days, written for both leadership and technical teams.
A 0 to 100 Modernization Readiness Score with Red / Yellow / Green zones, traceable to the published methodology -- deterministic findings underneath, judgment labeled as judgment.
A prioritized risk register -- each finding with severity, evidence, and what it blocks.
An evidence appendix that connects findings to supporting artifacts such as .csproj files, stored procedures, jobs, dependencies, and configuration.
Modernization sequencing guidance -- what to address first, what to delay, and why.
An estimate is a claim. This is what evidence looks like. Pages from the SocialGoal sample report: a real public codebase (SocialGoal, an open-source ASP.NET MVC application), scored 44/100 Red. The supporting evidence is checkable against the source.
This work is for teams who need clarity, not reassurance.
Good fit
You have an estimate -- vendor or internal -- you cannot fully trust.
A budget, a deal, or a board decision riding on that number.
A legacy .NET and SQL Server system behind the estimate.
Not a fit
Greenfield, with no real legacy .NET or SQL Server footprint.
You want the migration done, not an independent read of the number.
The estimate is already backed by an evidenced inventory you trust.
Where this connects to Modernization Shield
Modernization Shield exists to produce the evidence that makes an estimate less speculative. It identifies the risk, the blockers, the dependencies, the sequencing, and the change safety of a legacy .NET and SQL Server estate before implementation vendors are selected and before the number is set. It does not replace implementation estimating -- it improves the inputs to it, so the estimate is built on what the system actually contains rather than on what was visible in a first look.
What happens after you check fit
The fit review leads to a short call -- 20 to 30 minutes -- to find out whether Modernization Shield fits your situation. Not a sales pitch.
We confirm the platform and the rough scope: which legacy .NET and SQL Server systems are in play.
We identify the deadline and the pressure behind it -- the estimate on the table and the budget or deal decision riding on it.
We decide together whether Modernization Shield is the right next step. If it is not, we tell you that.
No implementation pitch. Evincia sells no migration or build work, so there is nothing to upsell.
Which assumptions is the estimate carrying?
Modernization Shield tests the assumptions behind the estimate against the application types, SQL Server logic, dependencies, integrations, test coverage, cutover constraints, and rollback paths in the actual estate.
The SocialGoal sample Modernization Risk Report shows what a tested, evidence-backed picture of that scope looks like.
This is a buyer's guide, written to be fair: good estimates exist, and estimates are constrained by the evidence available when they're made. The issue is rarely vendors in general -- it's trusting a number without understanding its assumptions. This page gives no pricing and no cost ranges; cost depends on a system we haven't seen. If a point here doesn't match your experience, email info@evincia.co.
