Cloud migration is no longer a lift-and-shift exercise. In 2026, the leading programmes I’ve worked on — spanning healthcare payers, financial services, and telecom BSS platforms — share a common architectural shift: a layer of purpose-built AI agents sitting between the legacy estate and the cloud target, making real-time decisions that previously required weeks of architect involvement. This post unpacks what that layer looks like, how to build it, and the hard lessons from deploying it at scale.
Why Traditional Migration Architecture Breaks at Scale
Most migration frameworks were designed when 20–50 applications was considered a large estate. Today’s enterprises routinely face 150–400 applications, spanning mixed on-premise footprints: AIX workloads from the early 2000s, Java EE monoliths running on WebSphere 8.5, Oracle Forms, legacy COBOL, and a spaghetti of REST-ish APIs stitched together over 15 years of acquisitions.
The classical 7R model (Retire, Retain, Rehost, Replatform, Repurchase, Re-architect, Re-imagine) provides the vocabulary — but not the decision engine. Assigning a disposition to each application typically requires a Technical Architect to perform a multi-day assessment: reviewing source code, dependency maps, runtime metrics, security posture, and regulatory constraints. At 200 applications, that’s 400–800 architect-days before a single workload moves.
The bottleneck
Manual disposition scoring is the single biggest delay in large-scale migrations. In a programme I led for a healthcare payer with 160 applications, the initial assessment phase consumed 14 weeks and cost more than the first year of cloud hosting.
The AI Agent Decision Layer: Architecture Overview
The core insight is that migration decisions are structured data problems dressed in architect clothing. Given a sufficiently rich application profile — source stack, runtime behaviour, dependency graph, data classification, complexity score — the disposition and sequencing decisions can be automated with high fidelity. The architecture I’ve arrived at consists of five specialised agents, each owning a distinct phase of the migration lifecycle.
Building the Discovery Agent
The Discovery Agent’s job is to construct a machine-readable application profile from sources that were never designed to be read by machines: Confluence pages, JIRA epics, runbooks, network topology diagrams exported as PDFs, and — if you’re lucky — a half-maintained CMDB. In practice, it also instruments the running workloads directly using agent-based collectors.
What the profile captures
- Runtime stack fingerprint: OS, JDK version, web container, framework versions, open ports, and native binary dependencies. Critical for identifying AIX-specific binaries that won’t replatform without a rewrite.
- 2Dependency graph: Inbound and outbound service calls, database connections, MQ channels, shared file system mounts, and print/batch endpoints. This is where most migration surprises hide.
- 3Data classification: Whether the application touches PHI (Protected Health Information), PCI-scoped card data, or PII — triggering additional compliance controls in the migration plan.
- 4Change velocity: Deployment frequency, open incident count, and test coverage percentage. Low-change, low-test apps are rehosting candidates. High-change apps with low coverage need re-architecture investment first.
from dataclasses import dataclass, field
from enum import Enum
from typing import list, Optional
import asyncio
class DataClassification(Enum):
GENERAL = "general"
PII = "pii"
PHI = "phi" # HIPAA Protected Health Information
PCI = "pci" # Payment Card Industry scope
@dataclass
class ApplicationProfile:
app_id: str
name: str
os_family: str # "aix", "rhel", "windows"
jdk_version: Optional[str]
web_container: Optional[str] # "websphere", "jboss", "tomcat"
inbound_callers: list[str] = field(default_factory=list)
outbound_targets: list[str] = field(default_factory=list)
db_connections: list[str] = field(default_factory=list)
data_class: DataClassification = DataClassification.GENERAL
deploy_freq_pw: float = 0.0 # deployments per week (trailing 90d)
test_coverage: float = 0.0 # 0.0 – 1.0
open_incidents: int = 0
class DiscoveryAgent:
"""
Collects runtime telemetry and document-sourced metadata
and produces a structured ApplicationProfile.
"""
def __init__(self, cmdb_client, collector_client):
self.cmdb = cmdb_client
self.collector = collector_client
async def profile(self, app_id: str) -> ApplicationProfile:
# Fetch CMDB metadata and live runtime data concurrently
cmdb_data, runtime = await asyncio.gather(
self.cmdb.get_app(app_id),
self.collector.snapshot(app_id),
)
return ApplicationProfile(
app_id = app_id,
name = cmdb_data["name"],
os_family = runtime["os_family"],
jdk_version = runtime.get("jdk_version"),
web_container = runtime.get("web_container"),
inbound_callers = runtime["inbound_callers"],
outbound_targets= runtime["outbound_targets"],
db_connections = runtime["db_connections"],
data_class = DataClassification(cmdb_data.get("data_classification", "general")),
deploy_freq_pw = cmdb_data.get("deploy_freq_per_week", 0.0),
test_coverage = cmdb_data.get("test_coverage", 0.0),
open_incidents = cmdb_data.get("open_incidents", 0),
)
The Complexity Scorer: Turning Profiles into Migration Dispositions
Once every application has a profile, the Complexity Scorer applies a weighted scoring model to assign a migration disposition and T-shirt size. The model I use is calibrated against historical migration data from comparable programmes — with benchmarks from Truist Bank and AT&T serving as the reference corpus for financial and telecom profiles respectively.
| Factor | Weight | Low (0–3) | Medium (4–6) | High (7–10) |
|---|---|---|---|---|
| Dependency count | 25% | <5 services | 5–15 services | >15 services |
| OS portability | 20% | Linux/RHEL | Windows Server | AIX / Solaris |
| Data sensitivity | 20% | General | PII | PHI / PCI |
| Test coverage | 15% | >80% | 40–80% | <40% |
| Change velocity | 10% | <1 deploy/wk | 1–4 deploys/wk | >4 deploys/wk |
| Incident rate | 10% | <2 open | 2–5 open | >5 open |
The score maps to a disposition recommendation and a wave-sequencing priority:
| Score Range | T-Shirt Size | Disposition | Priority |
|---|---|---|---|
| 0–3.0 | Small | Rehost (lift-and-shift) | Wave 1 candidate |
| 3.1–5.5 | Medium | Replatform | Wave 2–3 |
| 5.6–7.5 | Large | Re-architect | Wave 3–4 |
| 7.6–10.0 | X-Large | Re-architect or Retire | Programme-level decision |
from dataclasses import dataclass
@dataclass
class ScoringResult:
app_id: str
raw_score: float # 0–10
tshirt: str # S | M | L | XL
disposition: str
wave_hint: int # suggested wave number
flags: list[str] # human-readable warnings
class ComplexityScorer:
def score(self, p: ApplicationProfile) -> ScoringResult:
flags = []
score = 0.0
# Dependency count (25%)
n_deps = len(p.inbound_callers) + len(p.outbound_targets)
score += 0.25 * (10 if n_deps > 15 else 5 if n_deps > 5 else 2)
# OS portability (20%)
os_score = {"aix": 9, "solaris": 9, "windows": 5}.get(p.os_family, 2)
score += 0.20 * os_score
if p.os_family == "aix":
flags.append("AIX binaries require recompile or containerised emulation")
# Data sensitivity (20%)
sensitivity = {"phi": 9, "pci": 8, "pii": 5, "general": 1}
score += 0.20 * sensitivity.get(p.data_class.value, 1)
if p.data_class.value in ("phi", "pci"):
flags.append("Regulated data: HITRUST / PCI-DSS controls required in landing zone")
# Test coverage (15%): lower coverage → higher risk score
score += 0.15 * (1 - p.test_coverage) * 10
# Change velocity (10%)
score += 0.10 * min(p.deploy_freq_pw / 4 * 10, 10)
# Incident rate (10%)
score += 0.10 * min(p.open_incidents * 2, 10)
if score <= 3.0: tshirt, disposition, wave = "S", "Rehost", 1
elif score <= 5.5: tshirt, disposition, wave = "M", "Replatform", 2
elif score <= 7.5: tshirt, disposition, wave = "L", "Re-architect", 3
else: tshirt, disposition, wave = "XL", "Re-arch/Retire", 4
return ScoringResult(p.app_id, round(score, 2), tshirt, disposition, wave, flags)
Handling Regulated Environments: PHI, HITRUST, and PCI
In regulated industries — healthcare payers like GuideWell, or financial services firms — the migration isn’t just a technical exercise. Every landing zone configuration, every IAM policy, every network egress rule is an audit artefact. The Validation Agent must verify compliance posture before any workload cutover is approved.
Compliance checkpoint
For HIPAA workloads, the Validation Agent enforces: TLS 1.2+ on all endpoints, encryption at rest with customer-managed KMS keys, CloudTrail enabled with integrity validation, GuardDuty and Macie active in the target account, and a signed Business Associate Agreement (BAA) on record for the cloud provider. Any failed check blocks the migration and pages the compliance lead.
The pattern I recommend is a pre-flight checklist framework built as a declarative configuration. Each check is a named assertion; the Validation Agent runs them in dependency order and produces a pass/fail report that can be attached to the change record:
checks: - id: tls-minimum-version description: "All ALB listeners enforce TLS 1.2 or higher" severity: BLOCKER query: | aws elbv2 describe-listeners --region $TARGET_REGION | jq '[.Listeners[] | select(.SslPolicy != null) | {arn: .ListenerArn, policy: .SslPolicy} | select(.policy | test("^ELBSecurityPolicy-(FS-)?TLS13?"))]' - id: encryption-at-rest description: "All RDS instances encrypted with customer-managed KMS key" severity: BLOCKER query: | aws rds describe-db-instances | jq '.DBInstances[] | {id: .DBInstanceIdentifier, encrypted: .StorageEncrypted, kms: .KmsKeyId} | select(.encrypted == false or .kms == null)' - id: guardduty-active description: "GuardDuty enabled in all regions with active detectors" severity: BLOCKER - id: cloudtrail-integrity description: "CloudTrail log file validation enabled" severity: HIGH - id: phi-tag-propagation description: "All resources tagged data-classification=phi" severity: HIGH auto-remediate: true - id: no-public-s3 description: "No S3 buckets with public ACLs or bucket policies" severity: BLOCKER
Wave Sequencing: The Migration Planner Agent
Sequencing is where most migration plans fall apart. The natural instinct is to migrate simple applications first (to get early wins) and save the complex ones for later. But this ignores the dependency graph: if Application A is simple but 14 complex applications depend on it, moving it in Wave 1 creates 14 parallel integration tests you aren’t ready for.
The Migration Planner Agent runs a topological sort on the dependency graph, applies the T-shirt sizing from the Complexity Scorer, and produces an optimised wave plan with three constraints:
- Dependency ordering: No application moves before all its outbound dependencies are stable in the cloud target or confirmed to stay on-prem permanently.
- Capacity constraint: Each wave is capped by the team’s parallel capacity (typically 6–8 active migrations per wave, per delivery squad of 8 engineers + 2 architects).
- Risk banding: No wave should contain more than two XL-complexity applications. Mixing S/M apps with an XL creates schedule drag that bleeds into subsequent waves.
A migration plan without a dependency-aware sequencer is not a plan — it’s a wishlist. The dependency graph is the critical path. Everything else is commentary.
The Rollback Guard: Continuous Safety at Runtime
One of the most underinvested components in migration architecture is the rollback mechanism. Most programmes implement a “break glass” rollback procedure — a manual runbook that an architect executes under stress at 2am when an incident fires. This is too slow and too error-prone for regulated environments where RTO (Recovery Time Objective) targets may be as tight as 15 minutes for clinical systems.
The Rollback Guard agent monitors three signal categories continuously after each cutover:
What the Rollback Guard monitors
SLO burn rate (error rate and latency against the agreed thresholds), upstream caller error rates (are the applications that call this service seeing increased failures?), and infrastructure health signals (CPU saturation, memory pressure, connection pool exhaustion). If two or more signals breach threshold within a 5-minute window, the agent triggers an automated traffic flip back to the legacy environment.
import time
from dataclasses import dataclass, field
from typing import Callable
@dataclass
class Signal:
name: str
value: float
threshold: float
breached: bool = False
class RollbackGuard:
"""
Watches SLO signals in a sliding window.
If breach_count >= min_breaches within the window,
fires the rollback callback and pages on-call.
"""
def __init__(
self,
app_id: str,
min_breaches: int = 2,
window_seconds: int = 300,
rollback_fn: Callable = None,
pagerduty_fn: Callable = None,
):
self.app_id = app_id
self.min_breaches = min_breaches
self.window_seconds = window_seconds
self.rollback_fn = rollback_fn
self.pagerduty_fn = pagerduty_fn
self._breach_times: list[float] = []
def evaluate(self, signals: list[Signal]) -> bool:
"""
Call on each metrics poll (e.g. every 60s).
Returns True if rollback was triggered.
"""
now = time.time()
# Prune breach timestamps outside the sliding window
self._breach_times = [
t for t in self._breach_times
if now - t <= self.window_seconds ] for signal in signals: signal.breached = signal.value > signal.threshold
if signal.breached:
self._breach_times.append(now)
if len(self._breach_times) >= self.min_breaches:
self._trigger_rollback(signals)
return True
return False
def _trigger_rollback(self, signals: list[Signal]) -> None:
breached = [s.name for s in signals if s.breached]
print(ff"[ROLLBACK] {self.app_id}: signals {breached} breached → flipping traffic")
if self.rollback_fn:
self.rollback_fn(self.app_id)
if self.pagerduty_fn:
self.pagerduty_fn(
title = ff"Auto-rollback: {self.app_id}",
details = {"breached_signals": breached}
)
# Reset breach window to prevent repeated triggers
self._breach_times.clear()
Key Lessons from Production Programmes
These patterns were developed and refined across three large programmes over the past two years. Here are the hard lessons that don’t usually make it into vendor whitepapers:
- The CMDB is always wrong. Plan for a 30–40% reconciliation effort between CMDB records and discovered runtime reality. Build the Discovery Agent to treat CMDB as a hint, not a source of truth.
- AIX workloads are the long tail. A typical enterprise with 150 apps has 8–15 AIX workloads. They consume a disproportionate share of assessment and remediation effort. Identify and ring-fence them in Wave 1 planning — don’t discover them in Wave 3.
- Compliance automation pays off in week 2. The compliance check framework feels like overhead until the first audit request arrives. Automated evidence generation (tagged resources, enabled controls, signed-off runbooks) turns a 3-day compliance pack into a 2-hour export.
- Stakeholder dependency is the hidden critical path. Every migration wave has a client dependency register — items the programme cannot control: firewall rule approvals, BAA signatures, vendor API access, network peering provisioning. Track these with the same rigour as technical dependencies. Delays here dwarf technical delays.
- The rollback window is your most expensive asset. Every day you run in a split-traffic dual-run state costs roughly 1.4–1.8× the cloud running cost. The faster your automated validation and rollback mechanism, the shorter your dual-run window, and the lower your programme cost.
What’s Next: The Agentic Migration Factory
The direction I see this heading in 2026 and 2027 is full agentic pipeline orchestration — where the five agents described here are not invoked by an architect but continuously loop, updating the migration plan as applications change, as cloud costs shift, and as new regulatory requirements emerge. The architect’s role shifts from decision-maker to signal designer: defining the right thresholds, the right scoring weights, and the right rollback policies — and letting the agents execute.
This isn’t science fiction. The organisations I’m working with today have 10–20 agents running continuously against their estate, surfacing anomalies and recommendations that a 50-person architecture team couldn’t track manually. The technical challenge has shifted from “how do we automate the decision?” to “how do we build the right governance layer around an automated decision system operating in regulated environments?”
