It happens more often than anyone admits. A development vendor stops answering. A technical co-founder moves on. An acquisition closes and the due diligence turns out to have been optimistic. However it happened, the result is the same: you are responsible for a live system that nobody on your team fully understands — and it is processing your orders, your claims, or your customers' data right now.
The instinct is to do one of two things: freeze everything, or rewrite everything. Both are usually wrong. Here is what actually works.
First: stabilize your access, not the code
Before judging a single line, secure the operational basics. Teams routinely discover mid-crisis that they can't even deploy what they already have.
- Repository access — every repo, every branch, and confirmation nothing lives only on someone's laptop
- Credentials and secrets — production, staging, third-party services, domains, certificates
- Deployment — can anyone on your side actually ship? What happens if the server dies tonight?
- Backups — do they exist, has a restore ever been tested, who can run one
- Third-party dependencies — the payment provider, the email service, the API keys that expire quietly
Second: learn what it does before judging how it's built
The most common mistake with inherited code is evaluating craftsmanship before understanding behaviour. Code quality matters — but the system's real value is the business behaviour it encodes: pricing rules, edge-case handling, integration quirks, the accumulated fixes for problems you don't remember having. That knowledge often exists nowhere else.
Map the critical workflows first: what does the business actually depend on this system doing, every day? Which of those paths touch money, customers or compliance? Only then does code review earn its place — focused on the workflows that matter, not on style.
Third: resist the rewrite reflex
A codebase that looks alien is not necessarily a codebase that is broken. Unfamiliarity feels like disorder. Before any large decision, you need to know three things: what must be preserved, what is creating material risk, and whether boundaries can be drawn for incremental replacement. A rewrite decided in week one is a decision made at the point of maximum ignorance — which is exactly when the biggest commitments should not be made.
What the first 30 days should produce
- An access and continuity baseline — you can deploy, restore and revoke
- A critical-workflow map — what the business depends on, ranked
- A risk shortlist — the handful of things most likely to hurt you, with business impact attached
- A knowledge inventory — what is documented, what lives only in code, what left with the previous team
- A decision recommendation — stabilize, investigate deeper, or in rare clear-cut cases, begin a bounded replacement
Notice what is not on the list: a full audit of everything, a re-architecture proposal, or a framework migration. Those may come later — with evidence. The first month is about converting unknown risk into known risk.
When to bring in outside help
An external senior review earns its fee in this situation for one reason: independence. Your remaining team may be too close, too busy keeping the lights on, or — awkwardly — partial authors of the current state. A bounded external review names the risks without the politics, and gives leadership a defensible basis for the next decision. The key word is bounded: fixed scope, fixed duration, findings you own either way.
This is exactly the situation our Architecture Risk Triage was designed for: five days, senior engineers, a straight answer about what you inherited and what to do about it.
Inherited a system and need a straight answer? Book a Modernization Triage