An end-to-end platform that instruments live datacenters, synthesizes 30 days of telemetry into an in-memory dependency graph, and uses AI simulation to automate wave planning, blast radius analysis, right-sizing, and TCO modeling — transforming migration planning from a multi-month consulting exercise into a data-driven, automated process.
Enterprise datacenter migrations involving hundreds or thousands of servers fail most often not from technical execution errors — but from planning errors: wrong wave groupings, missed dependencies, and surprise blast radii that take down production applications. The root cause is almost always the same: dependency data was never systematically collected, and the migration plan was built on assumptions.
Application owners know their dependencies informally. No authoritative, machine-readable map of which servers talk to which exists at the estate level. Wave plans built without this map cut live connections on migration night.
Migration consultants manually group servers into waves based on interviews, CMDB exports, and educated guesses. A 1,000-server migration might take 3–6 months of planning before a single server moves. The plan is outdated by the time execution starts.
Without a live dependency graph, you can't answer: "if this server goes down during migration, what else breaks?" Discovering that answer during a maintenance window — while production is degraded — is the most common cause of emergency rollbacks.
Lifting and shifting servers at their current spec wastes 40–60% of cloud spend. But right-sizing requires real utilization data over time — not the peak figures stored in CMDB that often reflect provisioned capacity from years ago, not actual load.
Executive-level cloud TCO projections are often built in Excel using list-price estimates against total server counts. They don't reflect the 6R disposition mix, actual core counts, utilization-adjusted sizing, or the cost difference between Rehost, Replatform, and Retire at scale.
Reference implementations built on real client data can't be demonstrated to prospects without a masking layer. Many firms maintain parallel anonymized datasets manually — which drift from the real data and undermine confidence in the demo.
Digital Twin Premium instruments the live estate, builds an in-memory dependency graph, runs five AI-driven simulations against it, and delivers results as an interactive HTML dashboard, multi-tab Excel report, and PDF executive brief — all from a single automated pipeline.
Every server in the estate receives a deterministic 6R classification from an 8-rule priority chain. The first matching rule wins — no ambiguity, no LLM hallucination risk on the classification itself. AI enters downstream, in simulation and narrative generation.
| Priority | Disposition | Condition |
|---|---|---|
| 1 | Retire | environment = "Decommissioned" |
| 2 | Retain (Already in Cloud) | in_azure = "Y" OR azure_status = "Already in Azure" |
| 3 | Repurchase (SaaS) | application_type = "SaaS" |
| 4 | Retain (Appliance) | application_name ∈ KNOWN_APPLIANCES (60 entries) |
| 5 | Refactor (Citrix) | is_citrix = "Y" |
| 6 | Replatform (Database) | database field populated AND ≠ "In Progress" |
| 7 | Rehost (Lift & Shift) | device_type = "virtual" AND no database AND not appliance |
| 8 | Retain (Physical) | device_type = "physical" |
| — | Review Required | No rule matched |
The DigitalTwin class builds a Python dict-based graph from server detail records
with five cross-reference indexes. ~1,000 servers load in milliseconds — no Neptune, no
graph database licensing cost. AI simulations run against this graph to answer the questions
that migration planners could previously only answer by trial and error.
| Disposition | On-Prem Cost | Cloud Cost | Savings/Core/Year |
|---|---|---|---|
| Retire | $150 | $0 | $150 |
| Repurchase (SaaS) | $150 | $60 | $90 |
| Replatform | $200 | $130 | $70 |
| Refactor | $180 | $110 | $70 |
| Rehost (Lift & Shift) | $150 | $95 | $55 |
| Retain (Cloud) | $95 | $95 | $0 |
| Retain (Appliance / Physical) | $200–250 | $200–250 | $0 |
| 8,420 cores at reference estate mix | ~$1.52M | ~$0.91M | ~$610K/year |
The collection pipeline produces ~50 MB per 1,000 hosts over 30 days — a moderate
data volume that doesn't justify managed database cost or operational complexity.
SQLite provides zero-configuration, file-based storage that works identically on EC2,
Lambda (via /tmp or EFS), and local development without any provisioning.
The perf_raw table uses a UNIQUE INDEX ON (hostname, timestamp)
for deduplication — CSV drops from collectors may overlap, and the insert-or-ignore pattern
ensures exactly-once semantics per sample. The perf_summary view computes
per-host aggregates (avg CPU, max RAM, storage totals) used directly by the right-sizing engine.
The DigitalTwin class builds a Python dict-based graph from server
detail records with five cross-reference indexes (servers,
stack_members, server_deps, app_servers,
server_app). ~1,000 servers load in milliseconds.
This avoids Neptune costs (~$0.10/hr + storage), eliminates graph database provisioning and IAM complexity, and keeps the product self-contained with no external runtime dependencies. BFS for co-dependency discovery runs in-process in Python — no network round trips. The design decision trades raw query flexibility (which Neptune provides) for simplicity and zero operational overhead — the right tradeoff for an estate of this size.
The DataMasker class uses sequential ID generation and a curated list
of 160+ Epic ecosystem application names to produce a masked dataset that is
referentially consistent across all outputs. The same input hostname
always maps to the same SRV-NNNN — so the dependency graph, the dashboard,
the Excel report, and the EARE export all reference the same masked identity.
This is deterministic masking, not tokenization. No masking database required. The masked dataset faithfully preserves all structural properties of the real data — stack membership, dependency edges, utilization patterns, disposition mix — while replacing all identifiers with Epic infrastructure zone names that read naturally in the context of enterprise IT (Epic Production Cluster, Epic Clarity Database, Citrix VDI Farm, etc.).
When deployed alongside EARE Standard (the main cloud advisory product), Digital Twin Premium exports four data packages to an S3 prefix accessible via a cross-account bucket policy: disposition CSV, dependencies JSON (stack edges + server-to-server graph), right-sizing CSV, and cost projections JSON.
EARE's Bedrock AI agents consume these structured exports to generate advisory
narratives, answer migration planning questions, and produce deal-specific TCO models.
This creates a clean data pipeline: Digital Twin does the deterministic computation;
AI does the synthesis and communication. Neither product requires the other — the
integration activates via a single CloudFormation parameter (EnableEareIntegration=true).
The interactive dashboard is a single HTML file with embedded Chart.js (bar/pie charts),
D3.js (dependency graph visualization), and Tailwind CSS. It loads
dashboard_data.json from S3 and renders 12 data sections including
disposition summaries, resource-by-disposition, TCO analysis, stack dependency graphs,
and per-server detail tables.
No build step, no API dependency, no authentication surface area for the dashboard layer. The JSON file contains all masked data — the dashboard works fully offline by downloading both files. This makes it trivial to share with client stakeholders or embed in a deal portal without hosting infrastructure.
The matching engine, disposition engine, twin simulator, masking engine, cost projection model, and right-sizing engine are all validated with property-based tests (Hypothesis) in addition to unit tests. Properties include: CSV deduplication preserving unique (hostname, timestamp) pairs; disposition rules being mutually exclusive and exhaustive; masking being referentially consistent across all outputs; right-sizing recommendations always meeting minimum core/RAM floor constraints; and cost projections computing correct per-core savings.
These aren't just "happy path" unit tests — property tests generate hundreds of random inputs per property and verify the invariant holds for all of them. This is especially important for the matching engine, which handles per-DC column variations and edge cases in FQDN normalization.
The primary transformation is replacing assumption-driven migration planning with evidence-driven migration planning. Every wave grouping, every right-sizing recommendation, and every TCO projection is backed by 30 days of actual telemetry and a live dependency graph.
Migration projects don't fail in execution — they fail in planning, because the dependency graph was never built. Digital Twin Premium makes building it an automated, repeatable, data-driven process.
AWS Lambda · Python 3.11 · SQLite · CloudFormation · Ansible · D3.js · Chart.js