Cloud Modernisation on AWS
Cloud migration and modernisation on AWS
AWS suits organisations that want strong separation between business units, environments or acquired entities, because the account boundary makes that separation the default rather than an afterthought. We assess through AWS Migration Hub, migrate in waves with block-level replication and repeated test cut-overs, then modernise each workload only as far as its business case justifies. The account foundation and guardrails are a prerequisite delivered under landing zone foundations, not rebuilt here.
Why AWS
When this is the right platform.
- The account boundary gives every environment and business unit a hard edge for identity, network and cost, which is valuable where separate entities, acquisitions or client-facing workloads must not share a blast radius.
- The compute range is unusually granular, from Amazon EC2 through Amazon ECS and AWS Fargate to AWS Lambda, so a workload can be moved one step rather than being forced into a full rewrite to see any benefit.
- The rehost service, renamed AWS Transform MGN in June 2026 with its replication engine and APIs unchanged, replicates at block level and supports repeated test cut-overs, so a wave can be rehearsed as many times as the application owners need before the real window.
- Amazon Aurora gives MySQL and PostgreSQL workloads managed storage, backup and failover without changing database engine, which keeps the application change small while removing most of the administration.
- Amazon EVS runs VMware Cloud Foundation inside your own VPC in the Sydney region, so a VMware estate can move without replatforming first. You keep root access to vSphere and NSX, which also means you keep responsibility for patching them.
- Teams already working with Linux, open-source databases and Terraform tend to be productive quickly, which reduces how long the platform depends on external support.
Where it is less suited
We would rather say this now than after a migration.
- Charges for data transfer between availability zones, between regions and out to the internet are easy to under-model. Applications lifted unchanged from a flat on-premises network are the common case, and they need traffic modelling before the business case is signed rather than after the first invoice.
- Amazon EVS is not a managed VMware service in the way Azure VMware Solution is. AWS manages the bare metal, firmware and VPC connectivity while you install, patch, upgrade and configure the VMware Cloud Foundation stack yourself, on a subscription you bring from Broadcom, with a four-node cluster the practical production minimum. It buys you a date, not an operational reduction.
- AWS Fargate removes node management and charges per vCPU and per gigabyte of memory. For a container running near capacity around the clock it can cost more than the instance it replaced, so we check steady-state workloads against Amazon EC2 rather than assuming serverless is cheaper.
- The account boundary is the right default, and every account adds identity, logging, network and cost-allocation work. Where automated account provisioning does not already exist, the account count outgrows the team looking after it, which is why the platform foundation belongs ahead of the migration rather than beside it.
- Windows and commercial database workloads run well on AWS, but licence terms shape instance sizing and dedicated host decisions. That review belongs inside the migration assessment, because discovering it later can change the run cost of an entire wave.
- Service naming has moved faster than the documentation. Application Migration Service became AWS Transform MGN in June 2026, DMS Fleet Advisor reached end of support in May 2026, and VMware Cloud on AWS is now sold by Broadcom rather than AWS. We verify current behaviour against your deployed version and record the date we checked.
Business outcomes
What AWS delivers here.
- Rehearsed cut-overs instead of hopeful ones
- Application owners test their own systems in the target environment before the production window, using replicated data and a rollback position that stays available until the wave is signed off.Agreed measure: Number of successful test cut-overs required per wave before sign-off, agreed with application owners up front.
- Servers replaced by services where it pays
- Engineering teams stop patching instances for workloads that fit managed containers, functions or databases, which returns operational hours to product work. The ones that do not fit are listed with the reason.Agreed measure: Proportion of workloads still requiring instance-level maintenance, with the target set during assessment.
- Recovery matched to what the business will tolerate
- Risk and operations get backup and replication configured per workload against agreed recovery objectives, then exercised with the result documented.Agreed measure: Tested recovery time against the agreed objective per workload, not the existence of a plan.
- Spend that reconciles to the business
- Finance gets cost split by account, business unit and application because the account structure and tagging were designed for that reporting before the first wave landed.Agreed measure: Share of spend attributable to an owning team without manual allocation, with budget variance reviewed monthly.
- Data transfer that behaves as modelled
- Cross-zone chatter and internet egress are modelled from observed traffic before the business case is signed, then placement and endpoint design are set to match, because this is the line that surprises people in month one.Agreed measure: Modelled against actual data transfer charges in the first two invoices, with any variance explained.
- A dated exit from the data centre
- Each wave ends with the source system switched off, the contract line identified and the evidence filed, so the saving is realised rather than absorbed by running both estates.Agreed measure: Switch-off date per source system, tracked per wave against the contract dates found in assessment.
Common client problems
What we usually hear first.
Our data centre contract ends in 10 months and we still have physical servers running.
We assess the estate through AWS Transform, which replaced Migration Hub for new customers, group workloads into waves by dependency, and replicate with the MGN service so each wave can be tested repeatedly before its window. The contract end date becomes the plan's backstop, with modernisation of individual workloads scheduled after the move rather than blocking it. We also work backwards from the contract to find the decommissioning evidence your provider will need, because that step is routinely discovered too late.
We are exiting VMware and cannot rebuild 200 virtual machines by the renewal date.
Amazon EVS runs VMware Cloud Foundation in your own VPC, so the cluster moves largely as it runs today and the guests are untouched. Two constraints to price honestly: you bring the VCF subscription from Broadcom, and AWS manages the hosts and network while you remain responsible for installing, patching and upgrading the VCF stack. It is a way to hit a date, not a way to stop operating VMware, so we plan what leaves EVS for native compute and when.
The first month's AWS bill was much higher than the estimate we built the case on.
Data transfer between availability zones and out to the internet is the usual cause when a flat on-premises network is lifted unchanged. We model the traffic pattern, adjust placement and endpoint design, then set AWS Budgets alerts and a monthly AWS Cost Explorer review so a variance is caught in week one instead of at quarter end.
We run Kubernetes because someone set it up, and now nobody wants to own the upgrades.
We review each workload on the cluster against what it actually needs, and move the ones that only need a container runtime onto Amazon ECS with AWS Fargate. Amazon EKS stays for workloads that genuinely use Kubernetes features, with a documented upgrade cadence and a named owner. Be aware that Fargate is priced per vCPU and per gigabyte of memory, so a container that runs flat out around the clock can cost more than the instance it replaced.
Our SQL Server and Windows workloads are quoted very differently depending on who we ask.
We put licensing into the assessment rather than leaving it to the end, covering instance sizing, dedicated host options and where an engine change to Amazon Aurora PostgreSQL removes the licence entirely. You get the run cost of each option side by side, with the licensing assumption behind it written down. An engine change is a genuine application project, so we scope it as one rather than presenting it as a migration setting.
Every AWS document we read seems to describe a differently named service.
Fair, and it is worse than usual at the moment. Application Migration Service became AWS Transform MGN in June 2026 with the replication engine and APIs unchanged, DMS Fleet Advisor reached end of support in May 2026, and VMware Cloud on AWS is now a Broadcom product while Amazon EVS is the AWS one. We confirm current behaviour against your deployed version and record the date, rather than trusting a blog post or an internal runbook written two years ago.
How we deliver
Our AWS delivery approach.
- 01
Assessment and advisory
The AWS assessment produces two things: a wave plan the delivery team can execute, and a cost model finance can hold us to. Both are built from observed behaviour rather than from the specification of the current hardware.
- Discovery consolidated centrally. Inventory and dependency analysis reconciled with interviews, so undocumented integrations surface before a wave is planned rather than during its cut-over.
- Rightsizing from observed utilisation. Instance family, purchase option and storage class chosen against measured load and priced against the current hosting and support cost.
- Data transfer modelled before sign-off. Cross-zone, inter-region and egress charges estimated for chatty applications so they appear in the business case rather than in the first invoice.
- Licensing reviewed in the assessment. Windows and commercial database terms, dedicated host options, and where a move to Amazon Aurora or Amazon RDS changes the licence position materially.
- VMware exit options priced. Amazon EVS against native rehosting, including the Broadcom VCF subscription, the practical four-node cluster minimum and who patches the VCF stack afterwards.
- Recovery objectives per workload. Business tolerance translated into an AWS Backup policy and, where warranted, AWS Elastic Disaster Recovery replication rather than one estate-wide setting.
- Landing zone readiness confirmed. Whether the account structure, guardrails and central logging are already in place, since a wave landing in an ungoverned account creates rework.
- 02
Architecture and implementation
We migrate in waves that each end in a verifiable state, on top of an account foundation that already exists. Modernisation of individual applications is sequenced after the move unless the business case demands otherwise.
- Network built for the traffic pattern. Amazon VPC design with segmented subnets, controlled egress, interface endpoints for platform services and connectivity through AWS Direct Connect or VPN, tested against the applications that will cross it.
- Rehost waves with test cut-overs. Block-level replication into an isolated subnet so owners validate their systems with real data before the production window, with rollback held until sign-off.
- VMware clusters moved into your VPC. Amazon EVS used where a renewal date rules out per-workload replatforming, with the VCF operating responsibility and the exit plan agreed in writing first.
- Runtime chosen per workload. Amazon ECS with AWS Fargate or AWS Lambda selected on request pattern, runtime support and your team's operating capability, documented per workload.
- Databases onto managed engines. Amazon RDS, Amazon Aurora or Amazon DynamoDB with engine compatibility assessment, performance baselining and a rehearsed cut-over including a data validation step.
- Traffic entry standardised. Elastic Load Balancing and Amazon CloudFront handling certificates, health checks and caching consistently instead of being configured per application.
- Environments deployed from code. Terraform or AWS CloudFormation through your pipeline from the first environment, so a rebuild is repeatable and drift is visible in a diff.
- 03
Security and governance
Guardrails belong in the organisation before workloads arrive, so a migrated account starts compliant instead of being remediated later. Controls are preventive where the risk warrants it and detective everywhere else.
- Preventive controls inherited by account. Organisation-scope policy restricting regions, protecting logging configuration and blocking resource types the organisation has decided not to run, inherited by each migrated account.
- Configuration recorded and evaluated. AWS Config rules evaluating drift and reporting non-compliant resources to a named owner rather than into a shared inbox nobody reads.
- No long-lived keys for people. Federated sign-in with least-privilege roles, permission boundaries on roles teams can create themselves, and access keys for humans removed as part of the wave.
- Encryption with keys you control. Storage, databases and backups encrypted, with customer-managed keys where key control is a requirement and key usage logged.
- Exposure reviewed as each wave closes. Security groups, public subnets, load balancer listeners and object storage access checked at the end of every migration wave, not once at go-live.
- Control mapping, not certification. How the deployed AWS configuration supports the Essential Eight or ISO 27001 controls you are working towards, and which gaps remain process responsibilities.
- 04
Adoption and enablement
The account model only works if your team can operate it, including adding the next workload correctly. Enablement is built around what they will do in the first months after go-live.
- Workload onboarding runbook. Naming, tagging, account placement, budget setup and who approves each step, written for the engineer doing the work.
- Hands-on sessions in the real environment. Restore from AWS Backup, a failover rehearsal, scaling an Amazon ECS service, and interpreting an Amazon CloudWatch alarm back to a cause.
- Cost ownership per team. AWS Cost Explorer views and AWS Budgets scoped per team so each owner sees their own spend and its trend rather than an organisation total.
- Escalation paths written down. What is a platform issue, what is an application issue and what is an AWS support case, with the diagnostic detail required for each.
- First change run by your engineers. A joint dry run of the first post-migration change, executed by your team while we observe, followed by a review of what the runbooks missed.
- Source decommissioning checklist. Data retention, contract termination dates, backup retention and the sign-off required before equipment is released.
- 05
Managed service continuation
After migration we can keep running the AWS platform with you under an agreed service schedule, maintaining the guardrails, resilience testing and cost discipline once the project team has stood down.
- Alarm tuning, not alarm accumulation. Amazon CloudWatch coverage extended as workloads change and noisy alarms retired rather than muted, reported at each review.
- Config compliance and drift reporting. Drift, newly non-compliant resources and guardrail exceptions approaching their agreed expiry, each with a named owner.
- Restore and failover rehearsals. Scheduled restore tests from AWS Backup and periodic AWS Elastic Disaster Recovery failover rehearsals, with the result and any remediation recorded.
- Monthly cost optimisation review. Spend by account and tag, commitment coverage, idle resources, data transfer trend, and specific rightsizing actions with the saving quantified.
- Patch and image currency. Amazon EC2 instances, container base images and managed engine versions kept current against an approved maintenance calendar.
- Modernisation candidates kept visible. A prioritised backlog of resilience gaps, cost actions and workloads still on instances that now have a business case to move.
Reference architecture
Legacy estate to AWS, wave by wave.
How the pieces fit together on AWS. Every engagement adapts this, and we will tell you which layers you already have.
- 01
Discover
Utilisation, dependencies, licence position and the traffic crossing a boundary.
- AWS Transform
- Dependency and disposition register
- Data transfer model
- 02
Prerequisite
Accounts, guardrails, network and central logging already in place before wave one.
- Account structure and guardrails
- Amazon VPC and AWS Transit Gateway
- AWS Direct Connect
- 03
Move
Block-level replication, repeated test cut-overs, rollback held until sign-off.
- AWS Transform MGN replication
- Amazon EVS for VMware clusters
- Isolated test cut-over subnet
- 04
Modernise
One step at a time, each priced against the instance it replaces.
- Amazon ECS on AWS Fargate
- AWS Lambda
- Amazon Aurora or Amazon RDS
- 05
Prove and exit
Tested restore, attributed spend, contracts and hardware actually released.
- AWS Backup restore test
- Cost Explorer and Budgets
- Source decommissioning
Across every layer
- Federated sign-in with no long-lived access keys for people
- Tagging enforced so spend attributes to an owning team
- Every environment deployed from version-controlled code
- A named human approval at each cut-over and each decommissioning
Technology reference
The AWS services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Assessment and migration
AWS Migration HubDiscovery, dependency data and wave progress for existing Migration Hub customers only. It closed to new customers on 7 November 2025 and AWS Transform now carries the equivalent capability, so a new engagement starts there and this entry is for estates already on it.
AWS Application Migration ServiceBlock-level replication and repeatable test cut-overs for rehosted servers, now branded AWS Transform MGN with the replication engine and APIs unchanged.
AWS Database Migration ServiceContinuous replication for database cut-overs, including schema conversion where the target engine differs from the source.
Compute and application runtime
Amazon EC2Target for workloads that must stay at instance level, right-sized from observed utilisation and covered by a patching cadence.
Amazon ECSContainer orchestration for teams that want scheduled containers without operating Kubernetes.
AWS FargateServerless container compute that removes node patching and capacity planning, priced per vCPU and memory so steady heavy load is checked against instances first.
Amazon EKSKubernetes platform for workloads that genuinely use Kubernetes features, with a documented upgrade cadence and a named owner.
AWS LambdaEvent-driven and scheduled processing, replacing cron jobs and small always-on services that no longer justify an instance.
AWS App RunnerSimple container hosting for existing App Runner customers. It closed to new customers on 30 April 2026 and AWS points new work at Amazon ECS Express Mode, so we would not select it as a modernisation target today.
Amazon ECRThe image supply chain behind container workloads, with scanning and lifecycle rules so base images are rebuilt rather than inherited indefinitely.
Data platform
Amazon RDSManaged relational hosting for migrated databases, removing patching, backup and failover administration from application teams.
Amazon AuroraTarget for MySQL and PostgreSQL workloads needing managed storage, faster failover and read scaling without an engine change.
Amazon DynamoDBUsed where the access pattern is key-based at high volume and a relational model adds cost without adding value.
Network and content delivery
Amazon VPCSegmented network design with controlled egress, interface endpoints for platform services and separation between environments.
AWS Direct ConnectPrivate connectivity from the data centre or office where bandwidth, latency or predictability rule out internet VPN.
Elastic Load BalancingConsistent entry point for applications, with health checks, target group routing and certificate management handled centrally.
Amazon CloudFrontEdge delivery and caching for public sites and APIs, reducing origin load and shortening response times for distributed users.
Resilience, observability and cost
AWS BackupPolicy-driven backup across instances, databases and file systems, with protection coverage reported rather than assumed.
AWS Elastic Disaster RecoveryReplication and orchestrated recovery for workloads whose objectives cannot be met by restore alone, rehearsed on a schedule.
Amazon CloudWatchMetrics, logs, dashboards and alarms, with baseline monitoring applied as each workload lands so nothing arrives unobserved.
AWS ConfigConfiguration recording and rule-based drift detection, giving evidence of what changed, when and by whom.
AWS Systems ManagerPatch baselines, inventory and remote administration for the instances that remain, so image currency is managed rather than hoped for.
AWS Cost ExplorerSpend analysis by account, tag and service, used for rightsizing decisions and commitment coverage review.
AWS BudgetsBudget thresholds and alerts per team and environment, so a cost movement is raised in week one rather than at quarter end.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
AWS questions
What people ask about doing this on AWS.
Cost, lock-in and the parts that go wrong, answered before you have to ask twice.
We are exiting VMware. What is the AWS equivalent of Azure VMware Solution?
Amazon EVS, which runs VMware Cloud Foundation inside your own VPC and is available in the Sydney region. The important difference is the operating model: AWS manages the bare metal hosts, firmware and network, while you keep root access to vSphere and NSX and with it responsibility for installing, patching and upgrading the VCF stack. You also bring the subscription from Broadcom. It is a genuine way to hit a renewal or lease date without rebuilding guests, and it is not a way to stop operating VMware.
Why was the first AWS bill higher than the estimate?
Usually data transfer, and usually because a flat on-premises network was lifted unchanged into multiple availability zones. Chatty application and database pairs that used to talk over a switch now cross a charged boundary, and internet egress from reporting or backup traffic is easy to miss entirely. We model the traffic pattern during assessment, keep coupled workloads in the same zone where resilience allows, use interface endpoints instead of routing platform traffic out, then set budget alerts so a variance is a week-one conversation.
Does the multi-account model mean more work for our small team?
Yes, and that cost is real rather than theoretical. Every account adds identity, logging, network attachment and cost-allocation work, and some services still need enabling per account and per region. What makes it sustainable is automated provisioning and a baseline that arrives with the account, which belongs in the platform foundation rather than in the migration. If you do not have that foundation and do not intend to build one, a smaller number of well-separated accounts is a more honest design than a textbook structure nobody maintains.
Is AWS Transform MGN the same thing as Application Migration Service?
Yes. AWS renamed Application Migration Service to AWS Transform MGN in June 2026, and the replication technology, APIs and console behaviour carried over unchanged. The name reflects that the same replication engine now also sits underneath the agentic AWS Transform workflow, which can drive discovery, wave planning and rehosting. We use the console path for anything where cut-over control matters, because a wave plan you cannot explain to an application owner is not a wave plan.
How locked in are we if we containerise on ECS and Fargate?
Moderately, and less than most people fear. The container image and its Dockerfile are portable. What is not portable is the task definition, the load balancer and service discovery wiring, the IAM role model and any Lambda functions around the edges, and those are usually a rewrite rather than a lift. Amazon EKS is more portable because the Kubernetes manifests carry across, at the cost of running a cluster. We name that trade per workload rather than picking a default and calling it strategy.
Can we run SQL Server and Windows on AWS without a licence penalty?
You can run them well, and the licence terms drive the architecture more than the technology does. Bring-your-own-licence scenarios can require dedicated hosts or specific tenancy, which changes sizing and cost, and licence-included instances price the software into the hourly rate. The alternative worth pricing is an engine change to Amazon Aurora PostgreSQL, which removes the licence entirely and is a real application project rather than a migration setting. We put all three options side by side with the assumptions written down.
What happens if a cut-over fails halfway through the night?
You roll back to the source, which is still running because replication does not decommission anything. Every wave has a rehearsed test cut-over first, a defined rollback trigger and a named person allowed to call it without convening a committee. The most common cause of a failed cut-over is an undocumented integration still pointing at the old server, which is exactly what the test cut-overs are for. A clean rollback is a much better night than a partial success nobody can unpick.
Related industries
Where this work has the most leverage.
Logistics and Warehousing
Shipment and document automation, proof-of-delivery processing and exception dashboards that let a small team run a large network.
Manufacturing and Distribution
Demand and inventory intelligence, production analytics and supplier automation built on data your planners already trust.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Free discovery workshop
Start with a cloud modernisation discovery workshop.
Bring one challenge. We will assess whether AWS is the right platform for it before recommending anything.