From VMware VMs to AWS-Native Application Architecture

Customer Context

A B2B software company operated approximately 120 VMware workloads across customer-facing services, background workers, databases, and internal tools. Its renewal decision created a migration deadline while engineering still needed to ship product changes. Rewriting the whole platform would put migration and roadmap delivery in competition. The customer remains anonymous for confidentiality.

AAIC used selective modernization: preserve stable components, remove confirmed waste, and change application boundaries where the team could test and operate the result.

Define Workload Units Before Counting Applications

The source inventory comprised 120 workload units. Each unit was one VMware-hosted component assigned a single primary destination. It was not necessarily a complete application, a future container, or an AWS resource. One application can span several units, and a modernized unit can produce several services or replicas.

The application count remained separate from source workload counts. A database supporting a containerized service was counted in the database group, not again within the 24 container candidates. Destination resource counts and licensing were separate planning inputs.

Modernize Where the Product Case Is Clear

Discovery mapped service calls, database coupling, file shares, background jobs, identity, tenant isolation, and release ownership. Latency, error rates, processing completion, and tenant journeys informed target-design and acceptance decisions.

EC2 is the conservative path for stable applications that can meet requirements without code changes. Container candidates should have a reproducible build, a supported runtime, explicit configuration, and an agreed state-management approach. Moving mutable application files into an image is not modernization; durable state needs an owned storage and recovery design.

Managed database candidates require checks for engine versions, extensions, stored procedures, collation, scheduled jobs, authentication, and connection behavior. Unsupported features can return a component to EC2 or retention rather than force a redesign into the migration window.

Static assets can use S3 with CloudFront delivery where appropriate. This is a supporting architecture decision, not another group of source workloads: files and deployment replicas do not increase the 120-unit inventory.

Choose ECS or EKS for an Operating Reason

For the selected container units, Amazon ECS is the starting option when the team needs AWS-integrated container scheduling without a Kubernetes requirement. The decision still includes capacity, networking, deployment, and support responsibilities. Fargate versus EC2-backed capacity is a separate workload and cost decision.

Amazon EKS is justified where the product already depends on Kubernetes APIs, operators, or an established Kubernetes platform and support team. Familiarity with containers alone does not justify adopting Kubernetes. Upgrade ownership, policy controls, observability, and incident skills belong in the platform decision before accepting EKS.

The architecture did not require adopting both orchestrators. Platform selection followed application needs and operational ownership, rather than introducing Kubernetes by default. Containers are a deployment choice, not evidence of savings or a requirement to split every application into microservices.

Release Controls and Phased Delivery

A foundation phase prepares accounts, identity, segmented networks, secrets management, encryption, audit logging, backups, and infrastructure-as-code review. Build pipelines produce versioned artifacts with dependency and image scanning. Production promotion requires approval and a traceable change record.

The first application slice provided a controlled way to test routing, data access, identity, deployment, and support. Subsequent slices followed dependency groups and product calendars. EC2 moves could proceed independently where safe; database and container changes were paired only where that pairing reduced risk.

Contract tests, tenant-isolation checks, load tests, and batch reconciliation are acceptance gates. A deployment that passes health checks but breaks invoicing or tenant boundaries does not pass the wave.

Cutover and Rollback Protect Data

Each cutover identifies the system of record, replication lag tolerance, write-freeze window, owner, and rollback deadline. Database moves require schema validation, production-like query tests, record reconciliation, and checks of scheduled processing before traffic changes.

For stateless services, versioned deployments and controlled traffic shifts support rollback. For stateful changes, reverting an application image is insufficient: schema changes must remain compatible, and target-side writes require reconciliation or a rehearsed reverse-data path. The source must not reopen for writes while the target remains writable.

Owners approve go/no-go criteria against the baseline. Failed business tests, unacceptable lag, or a missed rollback window trigger a stop and an explicit recovery decision, not an automatic retry into production.

Recovery and Day-2 Acceptance

Recovery objectives are set per application, including the retained VMware dependencies. The design distinguishes service availability from disaster recovery: backups and replication need demonstrated restore, failover, and failback procedures. A recovery exercise includes secrets, identity, database consistency, and dependent services rather than only infrastructure recreation.

AAIC’s operating model connects agreed runbooks, escalation, patching, deployment support, capacity review, and recovery exercises. OpsRabbit assists investigation across authorized metrics, logs, alerts, and deployment evidence. An engineer validates the interpretation, approves remediation, and checks recovery.

Delivery Outcome

The work aligned a 120-unit workload register with application dependencies, destination decisions, compatibility checks, release controls, and operational acceptance. Stable applications did not need a rewrite simply because their infrastructure was changing. Modernization stayed selective, with the product roadmap and production support treated as part of the migration decision.

Explore a selective modernization plan with AAIC’s VMware team.