We point Modernization Shield at well-known open-source .NET codebases -- in the open. The same engine, the same twelve risk categories, check-it-yourself provenance. Including, when it happens, the places our own engine got it wrong.
Evincia does not publish client logos. The substitute is stronger: we run the exact diagnostic a client receives against codebases anyone can read, and we publish the readiness profile -- findings, score, and what would break first -- with the commit you can check it against.
A teardown is not a verdict on the people who built the code. Open-source maintainers ship under constraints a risk report knows nothing about. A teardown reads a codebase the way a modernization team has to: where the platform risk concentrates, what carries the migration, and what an estimate would have to absorb before the budget is set.
How each teardown is built
The real engine, not a demo. The same Roslyn-based diagnostic and the same twelve risk categories that produce a client Legacy Modernization Risk Report (LMRR) -- run against the public repository at a pinned commit.
Check it against the source. Every profile carries the repository, the exact commit SHA, the engine commit, and the file-and-project citation behind each finding -- so you can open the code at that commit and verify the evidence yourself. Re-running the engine end to end is ours to do (the run is deterministic and pinned to the commit shown); what is public is the evidence each finding rests on.
The score is senior architect judgment. The engine emits deterministic signals; the 0-to-100 score and the four dimensions are the senior architect's synthesis, labeled on the published Red / Yellow / Green scale. The engine does not invent a number.
Paraphrase, not republish. Findings cite file and project locations and describe the risk in our own words; no substantial source is reproduced, and license and attribution are preserved.
Honest coverage. Where the engine read everything, it says so; where it could not, that is stated, not hidden.
Calibrated in daylight, not on a slide
Before any of this was published, the engine was run across a broad corpus of public .NET projects -- to prove it is deterministic (same code in, same findings out), to check that the scored profiles built on its findings separate the eras -- the legacy cohort lands in Red at 18 to 44; the modern control application lands at 77, a full band above it and, scored honestly, three points short of Green -- and to find its own blind spots. The breadth is the calibration.
40+public .NET codebases analyzedup to 639projects loaded in one solution13 / 13determinism re-runs, byte-identical18–44 vs 77legacy cohort vs the modern control, same scale
The corpus spans names a .NET engineer will recognize -- ORMs, loggers, schedulers, CMS platforms, e-commerce monoliths, an IDE. Recognizable code.
The part most vendors hide
We publish where our own engine was wrong
Running the diagnostic across dozens of real codebases surfaced real false positives: a version string read as a hardcoded address, a single-project app whose service seam the heuristic missed, a modern library scored on a legacy axis because it multi-targets an old framework for compatibility. We caught them, wrote them down, and fixed the engine. Every profile flags any finding a later corrected run would change.
A diagnostic you can trust is one that tells you where it was wrong before you have to find out. That is the entire point of calibrating in public.
The teardowns
First profile · Microsoft .NET Foundation sample
eShop LegacyWebForms
A single-project ASP.NET Web Forms storefront on .NET Framework 4.7.2 -- the deliberately-legacy reference app from Microsoft's eShopModernizing sample. Platform-bound and certain: the dominant risk is the platform itself, and what breaks first is the web layer the moment System.Web is removed.
A 31-project, multi-tenant .NET Framework content-management platform on net40 -- eight swappable storage backends and three template engines at once. The deepest calibration subject so far: total platform lock-in, an internal WCF file server and Windows COM interop, and no test safety net at all.
A 7-project ASP.NET MVC 5 + EF6 reference app on .NET Framework 4.5 -- a Marlabs DDD teaching sample with a real test project and clean layering. The mildest Red of the legacy cohort: total net45 lock-in and a System.Web rewrite, but a genuinely better starting position than its peers.
Microsoft's clean-architecture ASP.NET Core reference app -- ten projects, all on .NET 8, the modern sibling of the legacy eShop profile above. The control pair for the whole program: zero platform-obsolescence findings, work that is hygiene rather than rewrites -- and a score of 77, three points short of Green, because the judgment layer does not hand out free Greens. A gauge that only ever reads Red is not a gauge; neither is one that reads Green on cue.
Additional teardowns are drafted and in senior architect review -- a 99-project IDE among them, and others across the corpus. Each is held until its confirming engine re-run and naming review are complete. They publish here as they clear.
From code you can read to your code
The public teardowns run the diagnostic on code anyone can inspect. The SocialGoal sample Modernization Risk Report shows how the same kind of evidence is organized into a decision-ready report for leadership.
Public Codebase Teardowns apply the Modernization Shield diagnostic to open-source .NET projects under permissive licenses, paraphrased and attributed, with check-it-yourself provenance. They are illustrative readiness profiles, not engagements, and not a judgment of the projects' maintainers. For a confidential read of your own estate, check fit for Modernization Shield or email info@evincia.co.