For teams who inherited a system

You inherited a .NET backend. What do you do first?

The system works. It has worked for years. But the people who built it are gone, the documentation is thin, and the next meaningful change — a feature, a migration, a vendor swap, a cloud move — now feels like it could break something nobody left a note about.

The shape of the moment

This page is for the specific situation where one of these has just happened:

• The original engineering team has left, retired, or moved on, and the people remaining were not close to the design decisions.
• Your company acquired or carved out a product, and the backend came with it. It runs, but the new owners do not yet know what they actually own.
• A long-time founder, contractor, or solo developer handed over a .NET system they built over a decade and is no longer available for questions.
• The team that maintains the system today never wrote it. Each change is a small archaeology project. Velocity is dropping and nobody can say exactly why.

In all four, the technical state of the system is not the urgent problem. The urgent problem is that the organization has lost the mental model of what it owns, and every roadmap decision now sits on top of that uncertainty.

Why hiring more developers does not fix this first

The reflex is to staff the gap — bring in contractors, hire a senior engineer, ask an existing team to absorb the system. That works for ongoing maintenance. It does not produce a map. A new engineer arriving at an inherited system spends weeks forming the same partial picture the previous engineer had, under pressure to ship. The result is a second incomplete mental model layered on top of the first one, with no authoritative reference anyone can consult.

What is missing in this moment is not capacity. It is a written, ranked, evidence-backed account of what the system actually does, where it is fragile, and what is safe to change next.

What a System Report does in this situation

The System Report is a fixed-scope, four-to-five-week, read-only investigation. It is designed for exactly this moment: when the system is still running, the original authors are unavailable, and the business needs to decide whether the next change is safe before it commits to the change.

In an inherited-backend engagement, the report typically maps the following:

• What the system actually does. The real request, job, and admin flows — traced end to end through code, database, and external calls — not the architecture diagram somebody drew once.
• Where the business rules live. Code, database constraints, stored procedures, configuration, admin tools, time-based logic, and the rules that exist only in former colleagues' heads.
• Which tests can be trusted. Which tests touch real state, which only mock, and where the gap matters for the changes you actually want to make.
• Where the operational risk is. Vendor boundaries, retry behaviour, batch jobs, deployment assumptions, rollback paths, hidden coupling.
• What is safe to change next, and in what order. Six to ten ranked findings, each tied to a business outcome, each with an honest read on certainty.

For example: the rule “customers signed up before 2018 are billed monthly in advance, everyone else in arrears” might live partly in code (PricingService), partly in a database table (discount_rules), partly in an admin override screen, and partly in the head of a long-tenured operations lead. The Rules Ledger names each location, which one the system actually uses on the day the question is asked, and who can confirm whether the rule is still correct.

The deliverable is typically a 30+ page written report, plus appendix where useful. It is read-only by design — no changes are made to your system during the investigation — and the recommended first implementation package, if any, is bounded and reversible.

What it does not do

It is not a rewrite proposal. It is not a sales pitch for a tool, framework, or cloud platform. It is not an architecture critique disconnected from what your business is trying to ship. It does not pretend to certainty when access is limited; the report is explicit about which findings are confident, which are provisional, and which require deeper access to resolve.

When this is the wrong fit

If the system is greenfield, fully understood by the current team, or already on a confident modernization path, the report is overkill. The same is true if the urgent problem is capacity rather than uncertainty — in that case you need developers, not a report.

The report fits when the cost of changing the wrong thing first is higher than the cost of a structured investigation.