Every enterprise modernization project starts with the same question: what do we actually have? The answer is almost never what the asset register says. Legacy estates accumulate undocumented service calls, hidden database dependencies, circular references between systems nobody owns, and integrations that exist only in someone's institutional memory. Before saasups assigns a single 7 R's score, it produces a complete dependency map — not a spreadsheet, not a CMDB export, but a traced, live picture of what each workload is actually doing.
This post walks through how saasups approaches dependency mapping at scale — specifically the engineering decisions that make it tractable for estates of 200 to 800 applications — and how that map becomes the foundation for every scored recommendation and target architecture the platform generates.
Why dependency maps fail at enterprise scale
The standard approach to dependency mapping is interview-driven: architects and engineers document what they believe is true. This produces maps that are accurate on the day they are drawn and increasingly wrong every day after. In a 400-application estate, the interview round alone takes months. By the time it is complete, the systems have changed.
Static analysis of configuration files and infrastructure-as-code is better, but it captures declared intent rather than runtime behavior. An application may declare a dependency on a database endpoint that was decommissioned two years ago. It may omit a dependency on a shared logging service that was added without a config change. Neither error is visible in the IaC.
A third failure mode is scope. Most dependency mapping tools are designed for individual application teams. They require agents installed per service, configured per environment, maintained per team. At 400 applications across a mix of on-premises, co-located, and cloud-resident systems, that coordination overhead exceeds the value of the output.
You cannot score what you cannot see. The dependency map is where every modernization decision is grounded.
saasups addresses all three failure modes with a single instrumentation pass that operates at the network and process boundary rather than requiring per-application configuration. The agent deploys at the host level — physical or virtual — traces all outbound and inbound connections, resolves service identities against a continuously updated asset catalog, and writes a structured dependency graph that is queryable before the scan is complete.
How saasups traces the estate
The instrumentation layer captures connection metadata at the OS network stack: source process, destination IP and port, protocol, connection duration, and byte counts in both directions. It does not require network policy changes, does not insert itself into the application call path, and does not require application restarts. For environments where host-level agents cannot be deployed — air-gapped segments, mainframe-adjacent systems — saasups ingests flow logs from network appliances and cloud VPC flow sources, resolving these into the same dependency graph format.
Circular dependency resolution is handled by the graph engine. In a raw trace, circular references appear as legitimate bidirectional connections — and some are. A service that both calls and is called by an API gateway is a common pattern. saasups distinguishes these from true circular dependencies by tracking call depth and request-response pairing. True circular dependencies — where A calls B which calls C which calls A in the same request chain — are surfaced separately in the estate map as migration blockers that require architectural intervention before any of the three applications can be independently modernized.
- Host-level agent deployment: no per-application configuration required
- VPC flow log ingestion for cloud-resident workloads
- Network appliance flow log ingestion for on-premises and co-located segments
- Circular dependency detection with call-depth analysis
- Continuous asset catalog resolution: IPs mapped to named workloads in real time
- Queryable dependency graph from first scan forward — no waiting for full estate completion
The scan is not a one-time event. saasups runs continuously, capturing dependency state across time. This is important for two reasons. First, traffic patterns vary: a dependency that only activates during month-end batch processing will not appear in a single-day scan. saasups accumulates dependency evidence across a configurable observation window — typically 14 to 30 days — before finalizing the estate map. Second, the estate changes during assessment. Applications are deployed, decommissioned, and modified. The continuous scan means the map reflects the estate as it is at assessment close, not as it was on day one.
From map to scored estate
The dependency map is the input to the scoring engine, not the output. Once the map is complete, saasups scores each workload against all seven modernization strategies: Rehost, Replatform, Refactor, Rearchitect, Rebuild, Replace, and Retire. Each score is a weighted function of dependency density, coupling type, runtime characteristics, estimated effort, and AWS target architecture compatibility.
Dependency density directly affects the Refactor and Rearchitect scores. A workload with 47 downstream dependencies and three circular references scores poorly for Rearchitect — the blast radius of any architectural change is too high without first resolving the circular dependencies. The same workload may score well for Rehost, where the dependency graph is preserved intact and moved to EC2 or ECS without modification. These are not opinions — they are functions of the traced dependency data.
The scored estate map is the artifact that makes a modernization roadmap defensible. When a CTO presents a phased migration plan to the board, the sequence is not arbitrary. Applications scored for Retire exit first, reducing operational footprint. Applications scored for Rehost move next, generating quick AWS cost baseline data. Applications scored for Refactor or Rearchitect move in later phases, after the estate has stabilized. Each phase is ordered by dependency graph — workloads with no dependents in later phases move before workloads that are upstream dependencies of systems yet to be migrated.
The FinOps cost model is generated from the same dependency data. AWS target instance sizing is estimated from observed resource consumption metrics collected during the dependency scan period. Interservice data transfer costs are estimated from the byte-count data in the dependency graph. The before/after cost model is embedded in the roadmap, not appended as a separate analysis.
saasups produces three artifacts from a completed estate assessment: the dependency map itself (queryable, exportable), the scored estate (each workload with its seven strategy scores and the reasoning trace behind each score), and the target architecture (AWS-native service mappings for each workload, with the dependency graph preserved in the target state). These are the inputs to the migration pipeline — not a presentation deck, not a consulting deliverable, but machine-readable artifacts your engineers can implement.