Every modernization program starts the same way: someone points a discovery tool at a datacenter, waits, and gets back a portfolio map. The tool has done its job. A picture now exists where one didn't before.
Most of these pictures are useless.
They tell you an inventory exists. They don't tell you what matters. They list every host, every app, every VM, sorted alphabetically, colored by category, decorated with tooltips no one will read. Teams stare at the output, zoom in and out a few times, and go back to the spreadsheet they were going to use anyway.
Here are the three questions a portfolio map should answer before anyone writes a single line of a migration plan.
1. What's the blast radius?
Every application touches other things. What most maps fail to capture is how much it touches, and how bad it would be if it went down.
Blast radius is the combined measurement of three signals: how many other services depend on this one, how critical those downstream services are, and whether any of them sit in the revenue path. A nightly batch job nobody would notice missing for two weeks has a blast radius near zero. A seven-replica messaging bus that backs every customer-facing API has a blast radius that can take a company down.
A good discovery pass annotates every node with a blast-radius score, not just a count of dependencies. Otherwise those two look the same on the map. In our schema, each node carries something like this:
{
"app": "payments-core",
"dependencies_in": 47,
"revenue_path": true,
"criticality": "tier-0",
"blast_radius": 94,
"notes": "7-replica messaging bus; every checkout transits this"
}
When we built CHAI Universe, the default sort wasn't alphabetical. It was by blast radius, descending. That one design choice reshaped how every follow-up conversation went. Teams stopped opening the map by looking for "their" app and started at the top of the list, asking the question that matters:
"What happens if this one goes down?"
2. Where does the evenness break?
The first thing you learn reading any real enterprise portfolio map is that nothing is uniform.
Every org starts its migration assuming the estate is 90% standard and 10% weird. By the time discovery finishes, the percentages are reversed.
The useful number isn't "how many apps run on JBoss?" It's "how many JBoss deployments share the same version, patch level, JVM flags, and tuning config?" The answer, almost always, is none of them.
Evenness breaks in three places:
- Runtime: same language, different versions, different package managers, different Node or JDK minors.
- Deployment: same container, different base image, different orchestrator, different health-check semantics.
- Ops: same alerting stack, different thresholds, different escalation paths, different on-call rotations.
The goal of a portfolio map isn't to show you the estate. It's to show you where the estate fractures. Those fractures are where every modernization plan grows tendrils it didn't forecast. The lift-and-shift budget dies in the fractures.
3. What moves together?
The unit of modernization is never a single app. It's a cluster.
Some apps share data. Some share a load balancer. Some share a release cadence enforced by a team lead who will veto anything that touches both at the same time. Some share a scheduled job that runs at 2 AM on a bastion host and isn't in any config repo.
A portfolio map that doesn't surface these affinity groups produces a false sense of progress. You containerize app A, deploy it to its own cluster, congratulate yourself, and six weeks later discover A isn't usable without B because nobody modeled the dependency. It wasn't in code. It was in a cron job.
Affinity detection is where AI assistance actually earns its seat. Parsing logs, tracing cross-service calls, reading IaC configs, correlating with change requests: the sheer surface area of signals is too much for a team to aggregate by hand. This is where the agentic part of agentic modernization stops being marketing and starts being mechanical. It's an agent that keeps reading until it stops finding new edges.
The map isn't the answer. It's the argument.
A portfolio map is a starting position, not a conclusion. Every good modernization conversation after discovery starts with someone pointing at part of the map and saying "wait, that's not right." Those conversations are the point. The tool's job is to make them happen faster, and to make sure everyone is arguing over the same picture.
Most maps fail because they're too flat. They list everything and rank nothing. They show boxes and hide behavior. They treat the estate as uniform when it's not.
If your discovery tool answers "what exists?" and nothing more, it has done roughly 20% of the work. The other 80%, what matters, where it fractures, what moves together, is the part that decides whether the modernization plan you write next is realistic or fiction.
Start with the three questions. If the map can't answer them, don't start the migration yet. Start over with the map.