10decoders
The Diagram Lists What Someone Remembered
An architecture diagram is a record of what people knew on the day it was drawn. It shows the interfaces that were designed, reviewed, and funded. It does not show the finance analyst who pulls a nightly extract straight from a reporting table, the partner who collects a file from an SFTP folder every morning at six, or the service account created in 2016 that three other systems still use to log in. None of those were mistakes. They are what a system picks up over fifteen years of being useful.
Modernization programmes meet them at the worst moment. A team scopes a wave around the four integrations the application owner confirmed, builds the new service, schedules the cutover, and then discovers on the first night of parallel running that something else reads the old database. The fix is rarely hard once the dependency is known. What costs money is learning about it late, after the wave plan, the vendor contracts, and the business communication have been fixed around the wrong picture.
The discipline that avoids this is dependency discovery from observed behavior. That means reading scheduler exports, database audit logs, network flow records, file transfer logs, and source code, and then asking owners to explain what the data shows, rather than asking owners to recall what exists. In our discovery work, the first scan of a legacy estate nearly always returns more callers than the diagram listed, and the extra ones are seldom the harmless kind.
Nobody forgets a dependency on purpose. The system just outlived the people who knew about it.
Six Dependencies That Diagrams Leave Out
These are the categories we ask teams to look for first. Severity reflects how likely the dependency is to cause a production incident or a missed cutover when it is found late.
| Hidden dependency | How it shows up late | Severity |
|---|---|---|
| Shared database tables | Other applications read or write the legacy schema directly, so moving the data or changing a column breaks systems nobody listed as consumers | Critical |
| Batch jobs and file transfers | A nightly job feeds a partner, a ledger, or a regulator, and the new platform produces the output at a different time or in a different format | Critical |
| Service accounts and credentials | Old accounts are reused across systems, so retiring or rotating them stops a feed that has no documented owner | High |
| Downstream reports and spreadsheets | Finance and compliance teams rely on extracts that change quietly when the source system is replaced | High |
| Hard-coded hostnames and paths | Scripts and configuration point at fixed addresses, and the migration moves the target without updating the caller | Moderate |
| Authentication proxies and gateways | Legacy login or token services are used by applications that were never part of the programme scope | Lower |
Not sure where your dependency gaps are?
10decoders reads scheduler exports, database logs, network flows, and source code across your first migration wave. You get an evidence-based dependency map and a list of unknown callers to resolve before cutover planning starts.
Book a Free AI Assessment →Why Interviews Alone Cannot Find Them
Interviews fail for a simple reason: the people who know about a dependency are often not the people being interviewed. The application owner knows the designed interfaces. The database administrator knows who has accounts. The analyst knows which report breaks if a column moves. Each holds a piece, and no one has a meeting that puts the pieces together until the migration forces one.
Observation closes that gap, with caveats. A scan of network flows shows who connected, but a quarterly or year-end job may not run during the observation window, so a thirty-day capture misses it. Source code search finds hard-coded addresses but not the spreadsheet macro on a shared drive. Database audit logs show which accounts read a table, but not which person or process sits behind a shared login. Good discovery combines several sources, treats each as partial, and records confidence next to every dependency it lists.
Kyndryl's report points to one change in how this work is done. It found that 10% of organizations have deployed agentic AI in production for modernization, applying it to dependency mapping, code conversion, and documentation. Those are the tasks that eat engineering time and need patient reading of old material. An agent can read a million lines of job control language faster than a person can, and it can draft an explanation for each dependency it finds. A person still has to confirm the explanation with the owner, because an agent that reads code cannot know what the business does with the output.
Owners Confirm What They Remember
Wave plans come from architecture diagrams and owner interviews. Surprises are handled during testing or cutover, and the dependency list grows as incidents happen.
Evidence Gathered Before Wave Planning
Scheduler exports, database logs, network flows, and code search produce a candidate dependency list. Owners review it, and unknown callers get a named engineer and a deadline.
Map Kept Current From Live Telemetry
The dependency map refreshes from production signals, carries a confidence rating per edge, and gates every wave. Agents draft explanations and people confirm them with owners.
Checklist: Is Your Dependency Map Good Enough to Plan a Wave?
Take the first application in your next wave and test the map against this list. Anything you cannot show is a risk to price into the plan.
A dependency map is not a document you finish. It is a measurement you keep taking until the old system is switched off.
What to do this week
01 Export the scheduler and list every job
Pull the job schedule for the first application in your next wave from whichever scheduler runs it, whether that is a mainframe scheduler, cron, or an enterprise workload tool. For each job, record what it reads, what it writes, who receives the output, and what happens if it runs late. Send the list to the application owner and the downstream teams and ask for corrections, not approval. Corrections are what you are after.
02 Pull the account list from the legacy database
Ask the database administrator for every account with read or write access to the legacy schema, with last login date and source host. Match each one to a team or system. Accounts with recent activity and no owner go to the top of the unknowns list. Accounts with no activity in twelve months become candidates for a controlled disable test, run in a quiet period with a rollback ready.
03 Capture a full business cycle of traffic
Start network flow and file transfer logging on the application now, and plan to keep it running through at least one month end and, if the application has regulatory returns, one quarter end. A thirty-day capture misses year-end and quarterly jobs, so record the gap in the map and ask owners about those jobs by name. Add the capture dates to the map so everyone can see what it has and has not observed.
04 Assign every unknown a name and a date
Create a short register of unexplained connections, with the source, the evidence, a named engineering lead, and a resolution date two weeks out. At the review, each item ends in one of three states: owner found and dependency documented, no owner and scheduled for a shutdown test, or accepted risk signed off by a business sponsor. An unknown with no state is a cutover incident waiting for a date.
Let 10decoders Map Your Hidden Dependencies
We run dependency discovery on one to three applications in your next migration wave, covering batch schedules, shared database access, service accounts, file transfers, and downstream reports. You leave with an evidence-based map with confidence ratings, a register of unknown callers, and a wave plan sequenced around what we found.