Map Legacy Banking Systems
Reconstruct how a legacy estate actually works, connect the findings to evidence, and keep that understanding current with resident agents.
Every bank runs systems nobody fully understands any more: a core that has outlived three vendors, batch chains that run at 02:00 because they always have, integration code whose author retired, and a schema with four hundred tables and a spreadsheet that explains sixty of them.
The knowledge is scattered across people, documents and the systems themselves. A discovery programme needs to bring those sources together into something the next team can use.
Read the systems that are actually running
Lightspeed agents can inspect approved hosts through the environment daemon and use selected tools to query other systems. That lets an investigation connect repository code with deployed configuration, scheduler definitions and database structure.
An agent might follow a JDBC URL from an application’s properties file, identify the batch job writing a table, and find the downstream process that reads it. COBOL, PL/I and Java can be examined as parts of the same data flow rather than as unrelated repositories.
The discovery team controls the tools, machines and credentials available to this work. Read-only access is a useful starting point.
Build the map in parallel
A coordinator splits the estate into manageable areas: host groups, repository families or schema domains. Specialist agents inspect their area and return findings. The coordinator combines them and flags interfaces where the two sides disagree.
Profiles give each specialist a consistent setup, while delegation limits keep the programme within the capacity agreed by the infrastructure team.
The map lives in a persistent virtual workspace. Architecture notes, diagrams and source extracts stay together, available for people to review and for later agents to extend.
Make the findings reviewable
A useful map should explain where its claims came from. The agent’s session history records tool calls and returned results; saved extracts and reports connect a description to the material it used.
A reviewer can follow a dependency back to a configuration file or query result, correct an interpretation, and retain the version accepted by the team. That makes the discovery work useful for audit preparation as well as engineering.
It also gives a migration a stronger starting point: a shared account of the source system with evidence behind it.
Keep the understanding current
After discovery, resident bots can revisit selected systems on a schedule. They compare the current deployment with the map, update the notes and report changes that need attention.
For an estate of forty hosts and three hundred repositories, the initial programme might use a dozen specialists working in parallel. The follow-up can be much narrower: inspect changed services and check important interfaces regularly.
The team keeps the map as an ongoing asset, with agents available to maintain it and people responsible for accepting the findings.
Read next: Accelerate and Automate Migrations. For connecting existing systems, see bring your own compute.