What I review before inheriting a system in production

The most common scenario, and the least discussed

Almost all technical content out there assumes you're starting from zero: clean architecture, fresh decisions, zero debt. But most serious software work isn't like that. It's stepping into a system that's been running for years, already has real users, real money moving through it, and can't be shut down while you fix it.

The rules change there. You can't "start right" — you have to understand what's there before touching anything, because every change you make can take down something that had been working for years for reasons nobody documented.

This is the review we do before taking operational control of any platform in production.

First: inventory what's exposed

Before looking at a single line of code, the most urgent question is what parts of this system are reachable from the internet, and who can get to them.

The recent data that makes this priority number one: according to Verizon's 2025 Data Breach Investigations Report, vulnerability exploitation already accounts for 20% of all breaches as an initial access vector — a 34% increase from the previous year. And within that category, edge devices (VPNs, firewalls, remote access gateways) went from 3% to 22% of targets — nearly eightfold growth in a single year.

The most revealing finding from the same report: of those edge-device vulnerabilities, only 54% were fully remediated during the year, with a median of 32 days to apply the patch. A month is more than enough time for someone who already knows the door is open.

When you inherit a system, that inventory almost never exists in documented form. You have to reconstruct it.

Second: where secrets live

In systems that have been running for years, credentials tend to accumulate in places nobody remembers: environment variables on servers that survived three migrations, configuration files with plaintext passwords, API keys in a repository history even if they've been removed from the current code.

The questions you need to answer: what credentials exist? Who knows them? Which ones are still active from people who no longer work there? Is any of it in a repository, even in an old commit?

Third: the dependency map nobody has

The system's own code is usually the easiest part to understand. The hard part is dependencies: third-party libraries frozen on versions from years ago, external services someone connected and nobody documented, integrations that fail silently and that the team learned to "fix by restarting".

The classic case — and still the best teaching example years later — is Equifax in 2017: a known vulnerability in Apache Struts that had gone unpatched for months ended up exposing data on nearly 147 million people. It wasn't a sophisticated attack or a zero-day. It was an outdated dependency nobody had on their radar.

Fourth: who actually knows how this works

This point isn't technical, and it's the one most people underestimate. In inherited systems there are usually one or two people who "know how it works" — not because it's documented, but because they've been operating it for years. If that person leaves before you understand the system, the knowledge leaves with them.

Part of inheriting well is documenting what only lives in someone's head, before it becomes urgent.

Fifth: what you can touch without fear, and what you can't

At the end of the review, what you should have isn't a list of everything that's wrong — it's a risk map: which parts of the system you can modify with confidence, which require a rollback plan before touching, and which you shouldn't touch yet until you better understand why they work the way they do.

That map is what makes it possible to modernize without stopping operations — which is the only way to modernize something already in production.

When we recommend not taking the project

There are cases where the right answer is not to accept the work, at least not yet:

• When there's no access to the real inventory. If you can't see what's exposed, you can't take responsibility for securing it.
• When modernization is expected with zero risk window. Every change in production has a margin of error; if the expectation is zero, the conversation has to start there, not with the code.
• When the person who knows the system is already gone and nothing is documented. It can be done, but the real cost is much higher than usually estimated — and it's better to say so upfront, not halfway through.

How we handle this at Devson Labs

At Devson Labs we take on systems that are already in production and can't fail — we find what's broken before it breaks, harden what's exposed, and modernize without stopping operations.

If you have a system in production that's no longer holding up — for security, scale, or because it's scary to touch — tell us about the bottleneck and we'll tell you whether it's worth tackling and what it would involve.