No client logos, no testimonials, no trophies. Evincia does not publish the companies it works with -- it publishes how the work is done.
Most consulting sites establish credibility with a wall of client logos, testimonials, and success metrics. Evincia does not. The systems we assess are sensitive, business-critical, and not improved by public storytelling, so there is no logo wall here.
That leaves the buyer's quiet, fair question: has this been done for real, and is the work good enough to trust? The honest answer is evidence of method -- the SocialGoal sample deliverable, the scoring logic, representative findings, a worked example on real code, and an explicit account of what the diagnostic cannot know. This page is the map to all of it.
The systems we assess are usually not the sort of thing a company wants turned into a cheerful public case study. Fair enough -- the database with the month-end job nobody fully understands does not need a press release. Public naming can expose operational risk, and on a small set of systems, anonymization is not always enough to prevent it.
So Evincia treats client confidentiality as the default and does not use logos as decoration. The substitute is stronger than a logo anyway: the actual artifacts, the scoring, and the limits. A logo tells you someone paid. The work tells you whether it was any good.
What we show instead
The SocialGoal LMRR is an inspectable sample deliverable that demonstrates the Modernization Shield methodology against a publicly available codebase.
The published methodology and scoring model are methodology proof. The SocialGoal Legacy Modernization Risk Report is deliverable proof: report structure, evidence model, risk register format, scoring approach, executive summary, modernization sequencing, and the boundary between automated diagnostics and senior review. It is not market validation or proof of commercial outcomes.
Six kinds of evidence, each something you can inspect directly today:
The deliverable itself. The SocialGoal Legacy Modernization Risk Report is downloadable and ungated -- a sample deliverable built from a public codebase. What each part does:
Executive summary -- the headline finding and the score, for a decision-maker, before any detail.
Modernization Readiness Score and radar -- where the system stands, across the four dimensions.
Risk register -- every finding on one schema, so a non-technical reader can sort by priority.
Evidence appendix -- each finding traced back to the raw signal it came from.
Sequencing guidance -- what to do, in what order, and the score earned back per phase.
Transparent scoring. The methodology documents all twelve risk categories, how they roll up into the four Modernization Readiness dimensions and a single 0-to-100 score, and the Red, Yellow, and Green zones -- with an interactive explorer so you can move the inputs and watch the score move. Nothing about the number is hidden.
A worked example on real code. The SocialGoal sample Modernization Risk Report and the SocialGoal engineering teardown show the deliverable built from a public codebase, scored 44/100 Red, with supporting evidence checkable against the source.
The limits. We are explicit about what the engine detects from code, what the senior architect has to evaluate by hand, what needs a stakeholder conversation or direct database access, and what gets marked uncertain rather than guessed. The engine also declares what it could not analyze -- coverage is reported, not assumed. More on that below.
Field experience. The framing across every guide is field-observed -- drawn from decades of working inside legacy .NET and SQL Server systems. Where a claim comes from Microsoft's documentation it is linked; where it comes from the field, it says so.
Generalized examples -- not customer findings
Example Findings: What Evincia Looks For
These examples describe recurring risk patterns in legacy .NET and SQL Server estates. They are generalized illustrations, not claims about a specific client or engagement.
Hidden Business Logic in Stored Procedures
Finding: Pricing, tax, allocation, or inventory rules live in SQL Server stored procedures rather than the application layer.
Why it matters: The database is acting as a second application, but the modernization plan may only account for the visible .NET code.
Risk if ignored: Modernized and legacy paths can produce different business behavior, while unplanned database work pushes the timeline and budget.
Typical next step: Inventory and classify stored procedures before application refactoring begins.
Finding: Critical workflows rely on BinaryFormatter, AppDomain behavior, Windows-only APIs, COM interop, or other patterns that do not carry cleanly into modern .NET.
Why it matters: Target-framework compatibility is determined by runtime behavior, not only by whether the code compiles.
Risk if ignored: Important workflows fail after platform migration or force late redesign work.
Typical next step: Identify incompatible runtime patterns and replace them before the target-platform migration.
This is R-003 from the SocialGoal sample Modernization Risk Report, traced from raw signal to dated resolution. It is the most useful finding in the register to walk through, because it is the one where the senior architect overruled the engine -- and the report's v1.1 code read then proved the call right.
The UI project carries a direct project reference to the persistence layer. Deterministic: the same scan finds it every time. Scores show the v1.1 resolved state; stage two narrates the original engine rating.
Probability2 / 5
Impact3 / 5
Priority6
Confidence9 / 10
Automation6 / 10
Raw signal — what was observed
The engine's Signal 2.3 watches layer boundaries. During the SocialGoal teardown it detected that SocialGoal.Web, the UI project, carries a direct project reference to SocialGoal.Data, the persistence layer. Detection is deterministic: the reference exists in the project file, and the same scan finds it every time.
Risk interpretation
The engine rated the finding Critical: probability 4, impact 5, priority 20. A UI layer reaching past the service layer into data access is the classic coupling defect, and the rule scores it accordingly. Automation level 9 out of 10: this one came almost entirely from the machine.
Business impact
Then the architect read the context. The Critical rating assumes the reference is actively bypassing the service layer, and the engine cannot confirm that: static analysis logged 26 workspace load failures on cross-project type resolution, which weakens exactly this class of finding, and a project reference alone does not say why it exists. So the severity was contested, confidence was de-rated to 4 out of 10, and the reason was written into the register. The detection stands. The interpretation waits for a code read.
Resolution — what the code read found
The v1.0 action shipped investigation-gated: do not anchor the register on the Critical rating until a code read confirms or refutes it. Version 1.1 delivers the read: no bypass. Every controller is service-mediated, and the reference exists for the composition root -- dependency-injection registration, the database seed initializer, the Identity store's DbContext -- plus one dead controller using and one paging type leaked through service signatures. R-003 is re-rated Low (priority 6, confidence 9/10) with the dispute retained on the page. The finding shipped with its dispute visible, and the dispute closed with a dated ruling. That is the difference between a generated report and a signed one.
Part of the proof is being clear about the limits. The engine reads the .NET solution with the Roslyn SDK -- Microsoft's own toolkit for reading .NET code -- and produces deterministic signal: the same code in, the same findings out, every time. SQL Server and T-SQL are assessed through expert review today, with automated ScriptDom-based analysis planned. That covers a great deal -- but source code does not reveal everything.
And the evidence is captured before any AI touches the work. The diagnostic engine uses no AI to scan source code or generate the initial evidence set -- the Roslyn engine and the deterministic rules produce that set -- so a finding is never something a model invented. If the client permits AI-assisted synthesis, it begins only after those outputs exist, can be turned off entirely, and follows the client's rules (Security & Data Handling); when it runs, it helps correlate findings and draft the write-up the architect signs off on. That order is the whole point: evidence first, AI second.
Whether a WCF service (an older Microsoft way of connecting applications) still has live consumers, whether a nightly job is load-bearing, which database is the real system of record -- those need a stakeholder conversation or direct review. Until they are answered, they are marked uncertain, not assumed away, and an unknown is treated as risk rather than as low risk. That discipline is what keeps the score honest: it is the difference between a number an auditor or an acquirer can rely on and one that quietly papers over the thing nobody checked. A diagnostic that claims to know everything from source code is either magical or wrong, and we do not offer the magical one. A fuller calibration-and-limits note is being added here.
Review the work, then decide
The SocialGoal sample Modernization Risk Report is ungated, and client-specific material is never published. Read it, move the sliders on the methodology explorer, and look at the example findings above; that is enough to judge whether the method is worth a conversation.
This page is the trust anchor for the Evincia site: proof by method rather than by client logos. More real-code evidence lives in the public teardowns: three named open-source codebases, scored and published. Technical facts in the linked guides are sourced from Microsoft Learn; the field framing reflects decades of work with legacy .NET and SQL Server systems. For a confidential walkthrough or any question, email info@evincia.co.
