Lazarus

I kept inheriting systems where the documentation, the code, the running infrastructure, and people’s memories all described slightly different things.

Sometimes the people who built them were gone. Sometimes they remembered what something used to do, but not why. Sometimes the documentation was perfectly reasonable and simply no longer true. A normal handover could not answer the questions needed for a safe change, so I built something that could investigate the system itself.

A new investigation begins with whatever is available: Markdown, CSVs, wiki exports, runbooks, architecture notes, repository information, old migration plans, and anything else that has accumulated around the system. Lazarus uses that material to seed its initial knowledge store.

None of it is automatically treated as truth. It is the beginning of the investigation.

Given appropriate access, Lazarus checks inherited knowledge against the environment that actually exists. No single source is treated as complete. Agreement and contradiction are both useful.

If the inherited material says a service is unused, that is a claim to investigate, not permission to delete it. Things that exist without documentation matter just as much as things the documentation claims exist but do not. Disagreements stay visible until evidence resolves them.

Everything Lazarus establishes feeds back into the knowledge store. The result is an interrogatable model of the system, not a pile of scan output.

• 01What depends on this machine?
• 02Why does this service exist?
• 03Where is this credential being used?
• 04The documentation says this job is dead. Can you prove it?

An answer that exposes another gap sends Lazarus back out to gather more evidence. Credentials are investigated through the evidence and access provided; it does not magically discover secrets. What is true, what is supported, and what remains unknown all stay distinct.

Once Lazarus understands the current estate, it reports what exists, what is obsolete or risky, known dependencies, security and operational issues, technical debt, and anything that still cannot be proved. It then recommends an upgrade, migration, or rebuild path based on the system it found.

Sometimes the answer is an in-place upgrade. Sometimes it is new infrastructure beneath the existing application. Sometimes preserving the old code is harder than moving the system to something modern.

When a new environment is part of the answer, Lazarus can scope the target platform, including AWS or VMware, generate the infrastructure as code, deploy the replacement, and track systems as they move across.

Discover / verify / understand / design / build / migrate / validate.

The documentation is part of the machinery used to perform the migration. It changes as reality changes, and it is used to validate the running replacement. Lazarus is in active use on real inherited systems and continues to evolve as they expose new cases.