Modernize the Map, Not the Myth

I would not promise to “convert 80 million lines of code.” First we need a trustworthy map: which applications exist, what business jobs they perform, what data they use, what they call, who owns them, and how risky they are.

Every discovered rule or dependency must show its evidence and when that evidence was last checked. Tools can suggest what is true. The responsible owner approves it. We move one business capability at a time and compare behavior, not just code size.

Actors are portfolio executives, domain owners, application owners, architects, security/compliance, modernization teams, agent operators, release managers, and auditors. Version one inventories code/repos, runtime/jobs, databases, interfaces, incidents, cost, usage, controls, and ownership. Builds a versioned dependency/capability graph. Extracts candidate business rules and characterization tests. Scores migration candidates. Creates governed waves/work orders. Tracks parity and cutovers. And reconciles actual retirement benefits.

Mock goals: initial 600-app inventory in 60 days. 95% of critical runtime flows mapped before wave approval. Graph updates within four hours of source change. Portfolio UI p95 under two seconds. No high-criticality cutover without dual-run and rollback. Seven-year decision/audit history. Out of scope: automatic deletion, big-bang rewrite, translating every dead line, and letting an agent deploy without approval.

Raw scan work is 320M line-passes. At 2.4M LOC/minute aggregate, the ideal wall time is 133 minutes, about 2.2 hours. That proves scanning is not the 60-day bottleneck. Building, resolving, and validating cross-system behavior, opaque binaries, data semantics, owners, and controls dominate. We need hundreds of partitions for language isolation and skew, but more workers do not create knowledge.

Thirty teams at four apps/year retire 120 apps/year, so a naive portfolio takes five years. Critical shared dependencies and change traffic reduce that throughput. Reuse of extracted capabilities/contracts may improve it. The portfolio system must expose work-in-progress, blocked dependencies, and actual retirement—not reward teams for declaring a rewrite “done” while the mainframe remains.

An Application has one permanent company ID even if its repository name changes. A DependencyAssertion says that one system may depend on another. It stores the direction, environment, exact evidence, when we observed it, how confident we are, and whether an owner approved it. Conflicting findings can both remain visible until a person resolves them.

Capabilities, owners, controls, costs, incidents, interfaces, data sets, rules, tests, and migration waves also have stable IDs. Each portfolio decision points to one saved graph version, so we can explain what information the team had at the time. APIs receive discoveries, show impact, approve connections, create migration waves, track behavior comparisons, and shift traffic safely.

I would draw four parts. Read-only collectors gather evidence from code repositories, configuration databases, job schedulers, database catalogs, network traffic, monitoring, tickets, and cost systems. Analysis workers inspect that evidence inside locked-down sandboxes. A dependency graph stores the findings and their sources. A portfolio service helps owners choose and run migration waves.

For one application, the collectors find its code, nightly jobs, database tables, and consumers. The owner reviews uncertain links. The portfolio service scores options using visible factors such as risk, cost, test coverage, and owner readiness. An approved wave creates plans, work, and tests. Agents help inside limited environments; people approve architecture and writes. We then compare old and new behavior, move a small traffic group, and keep a quick route back.

I model provenance and observation conditions rather than force consensus. Static analysis may show a possible call. Runtime trace shows an observed call for a time/environment. A contract or owner approval adds authority. Edges carry confidence and last-seen time. We preserve negative evidence carefully—absence in sampled telemetry is not proof of no dependency.

Portfolio ranking is multi-criteria with hard constraints. A hub’s centrality and size of the impact may make it a prerequisite, a platform extraction candidate, or something to stabilize rather than migrate first. I build dependency-respecting waves with capacity, blackout windows, shared data ownership, and rollback constraints. Executives can run scenarios with weights, but every recommendation includes sensitivity: if a small weight change flips the rank, it is not a robust decision.

We extract candidate rules from code, docs, tickets, production traces, and subject-matter interviews, each cited to evidence. We separate technical plumbing from policy and create Given/When/Then rules plus characterization fixtures from representative and edge-case production inputs. A golden-master harness compares outputs, side effects, latency, and accounting main rules using masked or synthetic data.

The stable front door that gradually moves work to the new system gives one stable contract. We begin shadow reads, then mirror traffic without effects, compare normalized outcomes, and investigate mismatches by value/risk slice. Where dual writes are necessary, one system remains source of truth and a database-backed event queue plus cross-checking detects divergence. We avoid uncontrolled bidirectional writes. Canary traffic increases by capability/cohort. Rollback shifts the route pointer and reconciles in-flight state. Retirement requires zero approved consumers, archived evidence, data retention disposition, credentials revoked, jobs stopped, and cost verified.

The wave readiness gate fails because critical-flow coverage is incomplete. I add scheduler and file-catalog evidence, quarantine the cutover, and use the file’s producer job, naming patterns, access audit, and downstream control totals to resolve consumers. The new assertion version triggers reverse-impact notifications and re-plans dependent waves.

Architecturally, discovery becomes continuous: code/CMDB alone was insufficient. I add batch scheduler, managed-file-transfer, filesystem audit, data history, and operator interview collectors. Graph completeness is measured per evidence family and critical capability, not one percentage. We may first wrap the file contract or extract a shared service instead of migrating the intended app. The schedule changes. The truth does not.

I block cutover. Count-weighted parity is the wrong objective. Value-, regulatory-, and risk-weighted slices are hard gates. The mismatch set becomes a first-class error bucket linked to rules, source lines, and fixtures. We determine whether the legacy behavior is required, a known bug, or undocumented policy. Only an authorized decision can intentionally diverge.

The agent’s summary is not evidence. We rerun the same tested build in the golden harness, add the high-value cases to a protected holdout, and require SME/legal approval for changed behavior. If business explicitly chooses a correction, we version the policy, migration rule, communication, and effective date. Otherwise the old route stays source of truth for that cohort while safe cohorts can canary separately.

Graph publication, approvals, wave membership, leases, and route changes use a database transaction that rejects stale updates. Analysis delivery is at least once and retry-safe on saved item digest plus analyzer version. Work orders have dependency graphs and exclusive leases for conflicting assets. Optimistic merge and code ownership handle parallel changes. Per-language queues, customer/domain quotas, retry budgets, poison-repo quarantine, and backfill pools prevent one COBOL monolith from starving change-driven analysis.

Connectors are read-only by default. Code and secrets stay in customer/VPC boundaries. Extracted data inherits source ACLs. Agent tools have task-scoped credentials, egress policy, signed outputs, and human approval for writes. Observe discovery freshness/completeness, conflicting/stale edges, analysis lag/cost, work-in-progress/block age, parity by value/risk slice, cutover error/latency/cross-checking, rollback time, retired cost, access anomalies, and audit gaps. Write-once evidence and event logs rebuild graph views. Cutover configs are replicated and restore/rollback is rehearsed.

Start with read-only discovery in one domain. Validate identity and graph edges with owners. Publish portfolio scenarios without committing funds. Select a low-coupling pilot and one representative hard system. Build characterization harnesses before replacement. Shadow, dual-run, canary, and retire with explicit gates. Then scale reusable analyzers/contracts across waves. Compare forecast with actual cost, risk, lead time, and decommission completion quarterly.

The trade-off is local migration speed versus portfolio coherence. A team can ship a new app quickly while duplicating a shared capability and leaving dependencies behind. I accept slower wave approval to make interfaces, ownership, evidence, and retirement measurable—then use the factory to accelerate repeated, well-understood patterns.

I’ll summarize continuous discovery, evidence-backed decisions, parallel work controls, and reversible cutover.