The people who knew what the system does have left the building. The system has not. It still runs on a Tuesday, still holds a queue nobody drains, still fails in a way three engineers recognize and none can explain. Buyers described the trap the same way every time: nobody knows what the legacy applications do, because the people who built them are gone.
Legacy Discovery & IT Operations
How Do You Find Out What Your Legacy Applications Do
and Which Are Still Running?
The estate documents itself in configuration, runbooks, tickets and code. Read that corpus and you recover most of what the people who left took with them.
Built from real buyer questions in our sales meetings
Direct Answer
Treat the estate itself as a corpus. Configuration, runbooks, incident tickets, design documents and code comments already describe what each system does, what it touches and how it breaks. Querying that written record beats interviewing people who have left. This is the least glamorous family of IT problems and among the most tractable, because the knowledge was scattered rather than lost.
The limit: documents are in scope, live system state is not. Iternal is direct about where the shipped software stops. AirgapAI works with files and does not query databases or other systems; the endpoint agent does not analyze a server; there are no integrations with process-automation platforms such as UiPath or Automation Anywhere, and Blockify does not directly integrate with ERP or CRM systems today. What you get is discovery of what was written down — a real answer to “nobody knows what this does”, and not an inventory of what is actually running.
Two things to settle before you start. Which artifacts your teams can export as files, and where the reading happens, since runbooks and configuration are often the most sensitive documents in the building. Iternal positions a local deployment as the answer to that second constraint. Get both on paper; the questions below are the short list.
Intent is written down; state has to be measured. Read the corpus to recover purpose, dependencies and failure modes, then confirm what is live with the monitoring you already own. For more information on getting documents into a pipeline, visit the file types page.
Three Problems That Share One Root
IT leaders raised three complaints repeatedly, and they sound unrelated until you notice what each is missing.
Portfolio blindness. A large telecom carries a mass of legacy software and nobody knows what any of it does. Application teams own infrastructure they did not build, and enterprises hold thousands of repositories nobody understands because the authors left.
Provisioning by hand. One operator manages all production servers, virtualization and storage manually. A Linux server request waits a month while the team works out how to classify it, and imaging means walking a flash drive to each machine.
No view of the cloud estate. Customers do not know what workload runs on their cloud instances, and bills arrive so late that months of the next one accrue before anyone can act.
The root is neither laziness nor budget. In each case the organization already owns the answer in writing — a runbook, a change record, a provider export — and cannot read all of it at once. One buyer summarized it when asked what his estate costs him: that is part of the problem, you do not know.
Brownfield Is the Default Condition, Not the Exception
Buyers reach for one word constantly: brownfield. It carries an assumption worth making explicit. Almost nobody starts from a blank sheet, so the estate you inherit is the design constraint, not the obstacle to it. Three consequences follow: inventory what exists before recommending anything, treat tech debt as a finding, and map how things connect.
Iternal builds the same assumption into its discovery tooling: the AI Blueprint Builder assesses greenfield against brownfield estate, tech debt and which assets can be leveraged. For more information visit the AI Blueprint Builder page.
The Discovery Corpus: What to Ingest, in What Order
Design documents give intent, runbooks give operation, tickets give reality, code gives the truth. Ingest in that sequence and every later layer corrects the earlier one.
| Ingest | Artifact | What it answers |
|---|---|---|
| 1 | Design documents, architecture decks, written specifications | What the system was built to do. Blockify ingests legacy formats including Word documents, slide decks and PDFs. |
| 2 | Runbooks, standard operating procedures, solution documents | How it is operated and how past problems were fixed. A sequence-preserving Blockify variant handles procedures, because step one must stay before step two. |
| 3 | Exported configuration and settings, held as text | What it is wired to. Configuration held as a file is in scope; configuration that lives only inside a running system is not. |
| 4 | Incident tickets and service requests | What breaks and who feels it. An incident reports something broken; a service request asks for access or an enhancement. |
| 5 | Source code and its comments | What the software does now, rather than what the documents claim. Iternal ships AirgapAI Code for repository-scale reasoning over source code, mapping interfaces and dependencies without the repository leaving your environment. |
One trap deserves naming first. An estate this old carries dozens of near-identical runbooks, each edited by a different team on a different date. Load them all and an obsolete procedure re-enters the corpus as a poison pill carrying facts that stopped being true years ago. Blockify is built for that shape, distilling near-duplicates into one governed version. Mark superseded copies as history rather than deleting them: the old procedure is often the only description left of a half-replaced system.
Scope and Placement: Settle Both in Writing
AirgapAI answers locally against a data set loaded on the machine. Turnkey AI is the no-code bulk analysis layer built on Blockify, with workloads Iternal describes as running on large-scale GPU infrastructure rather than on a laptop, so an estate-wide pass is a placement decision. Get these three answers on paper.
Pin it down: questions for your evaluation
-
Which discovery artifacts can we export as files today, and which exist only inside a running system?The true size of the corpus before anyone quotes a timeline, and which gaps need an export script.
-
Where does the analysis run for a full estate-wide pass, and can that placement go into the agreement?Whether your most sensitive documents stay inside the boundary that governs them, in writing rather than by assurance.
-
When five versions of the same procedure exist, how does the pipeline decide which one is current?The rule that stops an obsolete document being answered as live policy.
Cloud Cost Visibility Is a Reporting Problem, Not a New Tool
The reflex when a cloud bill surprises you is to buy something that watches the cloud. What buyers described points elsewhere. They hold provider printouts they cannot interpret, and every one of their complaints concerns a document that already exists and cannot be read at scale.
The data already arrived. That is the same corpus problem as the runbooks, and the same machinery answers it. Turnkey AI is Iternal’s no-code bulk document analysis layer: it structures and summarizes large volumes of documents, ingests emails, PDFs and spreadsheets, and fills a supplied template. Point it at the exports you receive and the printout becomes a report you can read.
The boundary here is instrumentation. Reading exports cannot invent telemetry that was never switched on, and buyers described that gap directly: monitoring never enabled on whole classes of server, so nothing is emitted to read. Turning it on stays an engineering task; the corpus only shows where the blind spots are.
What the Written Record Cannot Tell You
A document records intent; only a live check reports state. Some organizations settle that second half the hard way, recording everything call center staff do over a month to work out what the legacy code behind the applications serves. Reading the corpus shortens that work rather than replacing it, by telling the observers where to look.
Answered elsewhere
- Keeping asset records accurate and reporting on them at scale — see the reporting and back-office page.
- Taking the manual work out of the rest of the business — see the manual document work pillar.
- Producing records when a regulator or an auditor asks — see the records and evidence page.
- Getting something useful back out of the sales system — see the sales admin page.
- Sizing the hardware for an AI deployment of your own — see the sizing page.
FAQ
FAQ: Legacy Discovery and IT Operations
Read what they wrote down. Design documents give intent, runbooks give operation, tickets give failure modes, and the code gives current behavior. In that order, each layer corrects the one before it.
No, and the limit is worth stating plainly. Iternal is clear that AirgapAI works with files and does not query databases or other systems, and that the endpoint agent does not analyze a server. The written record gives a candidate map; your monitoring confirms what is live.
Yes, and procedures get their own treatment. A sequence-preserving Blockify variant handles technical documentation, because a runbook stops being one when step one drifts after step three. Blockify also distills years of near-identical edits into a single governed copy.
Partly, and the useful half is reporting. Turnkey AI structures and summarizes large volumes of documents and fills a supplied template, so provider exports become a readable view. It cannot invent telemetry that was never enabled.
No. Runbooks, configuration and architecture documents are often the most sensitive material an IT organization holds, and Iternal positions a local deployment as the answer to that restriction. Placement still deserves a written answer for an estate-wide pass.
It supplies the input that exercise usually lacks. Rationalization stalls when nobody can describe half the portfolio, so the debate runs on opinion. A corpus pass gives every application a description, its dependencies and a failure history.
Start With One System Nobody Understands
Pick the application that frightens your team most, collect every document it ever generated, and read the whole pile at once. If the corpus returns purpose, dependencies and failure modes for that system, it will do the same across the estate.