Migrate VMware Cloud Foundation
to Amazon EVS

What we deliver

• VMware estate inventory — clusters, hosts, datastores, networks, VMs, snapshots, age
• Application dependency map — which workloads talk to what, with bandwidth and latency profiles
• Portfolio scoring — re-host vs re-platform vs retire vs retain, per-application
• Current-state CMDB — owners, criticality tier, SLA class, license posture
• Target-state EVS landing zone design — VPC layout, IAM, KMS, observability, account structure
• Order-of-magnitude budget estimate for the full migration

How we do it

• Agentless discovery — no software installed on production hosts
• Read-only vCenter credentials, scoped and audited
• Output in your own tooling (Confluence + Jira) so it lives where your team already works
• Single named lead engineer, weekly checkpoint, fixed deliverables

Outputs go straight into

• Confluence — current-state and target-state design pages, living documents
• Jira — risk register, wave plan backlog seeded with epics
• Your CMDB of choice — if you don't have one, we'll start it

What the plan contains

• Wave plan — workloads bucketed by criticality, dependencies, business calendar
• Risk register — top 10 risks with owners, mitigations, monitoring triggers
• RPO / RTO per application class (Tier 0 / 1 / 2 / 3)
• Sign-off matrix — who approves what, what blocks what
• Rollback criteria for every wave — measurable, no judgement calls under stress
• Communication plan — internal stakeholders, customers, regulators where applicable

Outputs

• Confluence runbook bundle — wave plan, sign-off matrix, rollback steps, comms templates
• Jira epics seeded for each wave with acceptance criteria
• Steering-committee presentation deck (we'll deliver it with you the first time)

What we deliver

• AWS Direct Connect or Site-to-Site VPN sized to actual traffic profile
• L2 stretch between on-prem vSphere and EVS — VMs keep IPs across the boundary
• DNS continuity — split-horizon resolution if you need it, single zone if you don't
• Routing policy that survives wave-by-wave cutover (no big-bang re-cabling)
• Traffic observability before, during, and after — so the bridge is a known quantity, not a black box

What it unlocks

• Apps move without reconfiguration — no hardcoded IP rewrites
• Active Directory / LDAP trusts keep working across the wave
• Hybrid mode is permanent if you want it — not a forced full-cutover deadline

What gets deployed

• vSphere — sized to projected workload, room to grow per wave
• vSAN — capacity tier matched to current storage profile, no surprises
• NSX — networking and microsegmentation policies migrated from on-prem where applicable
• vCenter — single pane of glass, federated with on-prem for hybrid period
• AWS integration — IAM Identity Center, KMS for encryption, CloudWatch baseline metrics

How it differs from "just spin up EVS"

• Sized to actual telemetry from discovery — not vendor calculator guess
• VPC layout integrates with existing AWS estate (if you have one) and Route 53 zones
• Day-1 observability — alerts wired before workloads arrive, not after the first incident
• Documented as infrastructure-as-code so the next site is faster

Per-wave procedure

• Pre-move validation — connectivity, replication health, dependency reachability
• Live workload mobility for VMs in the wave, no IP changes
• Post-move smoke tests — automated, with explicit pass criteria
• Performance baseline comparison — SLO compliance before vs after
• Cutover ceremony — final DNS/traffic switch, with named owner and rollback timeline
• Sign-off and lessons-learned, feeding the next wave

Why this matters

• Live mobility removes the "schedule a 6-hour downtime window" conversation
• Validation gates remove the "did it really work?" Slack thread the next morning
• Named ownership removes the "who decides to roll back" hesitation under stress

Common high-ROI replacements

• VM-hosted database → Amazon RDS (managed backups, HA, point-in-time recovery)
• NFS appliance → Amazon EFS (elastic, multi-AZ, pay-per-use)
• SFTP/file gateway → Amazon S3 + Transfer Family (no servers, IAM-controlled)
• Cron VMs → AWS Lambda + EventBridge (no idle compute)
• Analytics VMs → Amazon Athena + Glue (serverless, query-on-demand)
• OCR / chatbot / RAG workloads → Amazon Bedrock

How we decide what to replace

• TCO model per workload — fully-loaded cost (compute + storage + ops effort)
• Risk score — change blast radius, business criticality, regulatory factors
• Effort estimate — re-platform vs. retain-as-VM tradeoff
• Recommendation backed by numbers, not appetite

What we set up

• Backup policy tied to RPO/RTO class — not "everything every 4 hours" by default
• Cross-region replication for Tier 0/1 workloads, immutable copies where needed
• Runbooks per scenario — region loss, AZ loss, data corruption, ransomware
• Named owner for each runbook, named escalation chain
• Quarterly drill schedule with explicit success criteria — and a written post-mortem

What "evidence" means here

• Drill artifact bundle — timeline, decisions, deviations, outcome — saved to Confluence per drill
• Restore-time measurements vs declared RTO, plotted over time
• Audit-ready trail for SOC 2, ISO 27001, regulated industries

What we optimize

• License Mobility — bring existing VCF subscription to EVS, no double-payment
• Reserved Instances / Savings Plans for predictable EVS host capacity
• Right-sizing per actual telemetry, not vendor calculator estimates
• Storage tiering — vSAN classes mapped to actual access patterns
• Idle/orphaned resource cleanup — snapshots, decommissioned VMs, unattached volumes
• Tagging discipline so the bill is attributable to teams, not just "AWS"

How it stays optimized

• Monthly FinOps governance review — anomaly flag, action list, owner per item
• RI/SP commitment ladder reviewed quarterly
• Showback / chargeback model so teams see their own bill

What Day-2 looks like

• Patching schedule — VCF, host OS, AWS services — with maintenance windows agreed up front
• Monitoring stack — CloudWatch + vCenter alerts deduplicated, routed to a single inbox
• Runbook library — incidents, escalation, change requests, on-call shifts
• Named SDM — single point of contact, monthly review, quarterly business review
• Live dashboard — your stakeholders see exactly what we did and when

Self-managed or MSP — your choice

• Self-managed — we hand over runbooks + training, you operate, we stay on standby
• MSP — Triangu Partner-Led Support takes over 24/7 NOC, you keep oversight via dashboard
• Switchable mid-flight — start MSP, move to self-managed as your team grows; or vice versa

Live KPIs (Wave 3 of 5 — week 6 of 14)

Activity timeline (last 24h)

• 03:22 — Wave 3 batch B (18 VMs) live-migrated, validation suite ✓ all green
• 06:40 — Direct Connect bridge — 99.99% uptime, 0 packet loss past 24h
• 09:15 — Patched VCF host 5 of 12 (rolling, no workload impact)
• 11:08 — Wave 3 gate G-12 (cross-region replication ready) ✓ signed off
• 14:50 — Cost anomaly flagged: Wave 4 forecast +8% vs plan, root cause = larger snapshots than discovery
• 17:30 — DR drill on Wave 1 workloads — RTO 14m / RPO 6m, pass

What you don't see today (and will)

• Workloads quietly migrating ahead of schedule — and which ones are slipping
• Gate progress per wave — what's signed off, what's blocked on whose decision
• Cost trajectory — actual vs forecast, anomaly alerts before invoice surprises
• AWS service adoption — which workloads are already using RDS / S3 / Lambda
• DR readiness — last drill, next drill, gaps with named owners

How we approach it

• Wait until EVS is stable and operational — modernization is never a phase-one decision
• Score workloads on re-platform viability — codebase health, scaling needs, ops cost
• Strangler-fig pattern — route traffic gradually, never big-bang
• Container targets (EKS / ECS) with the same observability and IAM as EVS workloads
• Optional re-platform to serverless (Lambda, Fargate) for spiky / scheduled workloads
• Decommission only after sustained successful run on the new substrate

What we explicitly will not do

• "Containerize everything" — that's a rewrite, not a modernization
• Force a modernization roadmap on workloads that are stable, low-touch, and economically fine in EVS
• Lock you to a particular orchestrator — EKS and ECS both stay valid choices