Two hundred and forty-seven applications. Three datacenters. Twelve quarters. Before anything moves, Panaptico observes the legacy estate — behavior, dependencies, data — and holds it as the baseline. Each wave is verified against that baseline as it lands, and the modern system stays verified long after go-live.
Legacy · baseline
VMware · 3 datacenters
Verification state
112 / 247 apps verified
Verified
112
In verification
95
Awaiting baseline
40
Modern · under verification
AWS · 2 primary + 1 DR
At target
112 of 247 apps
DC Dallas
verified absent · Q6
Drift findings
3 open · attributed
Unknown
14 · never a pass
The gap
01
What the legacy system actually does — its resources, dependencies, data flows — was never captured anywhere a machine can check. You cannot verify the modern system against a memory.
02
Tickets close, dashboards turn green, the wave is declared done. Nobody compares the modern system field by field against the system it replaced — and unobserved quietly reads as fine.
03
The team moves to the next wave and the finished one starts drifting. Six months in, nobody can say whether the modern estate still matches what the business signed off — or what changed, and where it landed.
Scope map
The 6R map is your declaration of scope — rehost, replatform, refactor, rebuild, retire, retain. Each bucket defines what a verified transition means for the apps in it, and Panaptico verifies every app against that definition, dependencies included.
Verified when baseline behavior holds on new infrastructure
Verified when managed services meet the declared targets
Verified when new internals keep the same observed contract
Verified when the new build meets what the business declared
Verified absent — nothing still depending on it
Verified holding its declared posture on-prem
Waves under verification
Your program sets the waves. Panaptico verifies each one against the pre-change baseline as it lands — verified, gaps open, or awaiting baseline — and a wave only reads done when the evidence says so, not when the slide deck does.
Foundation
Wave 1 · rehost
Wave 2 · replatform
Wave 3 · refactor
Wave 4 · rebuild
Retire · decom
Domain by domain
The team peels the checkout monolith apart domain by domain. Before each split, Panaptico baselines the domain’s behavior, data, and dependencies — then verifies the new service against that baseline as traffic moves, and reports anything it cannot observe as Unknown.
System under modernization
checkout-monolith · 2014 · Java 8 · MSSQL
Catalog
Verified Q3 · matches baseline · RDS Aurora
Pricing
Verified Q5 · same contract, new internals
Inventory
Verified Q6 · data reconciled with baseline
Payment
In verification · Q7 · 2 fields off target · before/after on record
Orders
Queued · Q9 · baseline captured
Fulfillment
Queued · Q10 · dependencies mapped
Observed traffic · monolith vs new services
The target state
The business declared what modern has to mean. Panaptico holds those declarations as targets and verifies live state against them — was, now, target — with evidence and history behind every number, through every wave and long after go-live.
Was
0
Now
112
Target
247
each app compared field by field with the baseline captured before its wave
Was
unmapped
Now
94%
Target
100%
effective paths observed from live provider state — not the architecture diagram
Was
8 hours
Now
22 min
Target
<15 min
recovery paths verified in both regions · off target until the declared target holds
Was
3 DCs
Now
2 DCs
Target
1 DC (Amsterdam · retain)
each exit gated on verified absence — nothing still depending on it, access provably gone
Was
30 days
Now
6 hours
Target
<1 hour
how old the newest observation is when a result is read — stale evidence degrades to Unknown
Was
unmeasured
Now
14
Target
0
resources that could not be observed, reported as Unknown — silence never becomes a pass
Baseline the legacy system. Verify every wave against it as it lands. Keep the modern estate verified long after go-live — with evidence behind every result.