Cloud Migration Services for a Large Legacy Portfolio on AWS: The 4 Layers Enterprises Must Buy (and the One They Forget)

Key points:

• Cloud migration services for an enterprise legacy application portfolio on AWS split into four separable layers, not one vendor, and the one enterprises forget to buy is the fourth: (1) AWS native programs and tooling (Migration Acceleration Program, Migration Hub, Application Discovery Service, Application Migration Service (MGN), Database Migration Service (DMS), Mainframe Modernization); (2) a systems integrator such as Accenture, Deloitte, Cognizant, PwC, Devoteam or Cloud4C for discovery, wave planning and execution; (3) an accredited compliance assessor such as Coalfire for regulated workloads under governance and compliance rules; (4) the run-time platform that operates the applications after cut-over.
• Choose partners by workload archetype, not by portfolio. Rehosting VM-based and COTS workloads is an AWS MGN plus systems integrator exercise. Replatforming Java and .NET applications onto containers is where an internal developer platform saves the most time. Refactoring should be reserved for the small subset of applications with a written business case, and retire plus repurchase are the two of AWS's 7 Rs enterprises most often skip.
• Governance must be live before wave one: AWS Organizations, Control Tower or Landing Zone Accelerator, Service Control Policies, IAM Identity Center, CloudTrail, plus AWS Config and Security Hub for continuous evidence, and a written shared-responsibility split across AWS, the integrator, the platform layer and your own team. Retrofitting guardrails after 200 applications have landed is the most expensive mistake I see.
• Budget the operating model, not just the move. AWS prices MGN and DMS cheaply relative to people-time, so the dominant costs are dependency untangling, licence renegotiation, dual-running during cut-over, and the platform headcount that remains after the integrator's final wave.
• Qovery is layer 4, not a migration consultancy. It deploys and operates your applications inside your own cloud account - AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster including self-managed and on-prem - with git-push deployments, preview environments per pull request, environment auto-stop, per-environment RBAC and managed cluster upgrades, so the cloud bill, Enterprise Discount Program terms, Savings Plans and data all stay in your name.

---

What cloud migration services does an enterprise actually need to move a large legacy application portfolio to AWS?

An enterprise legacy portfolio migration to AWS needs four separable service layers: (1) AWS native migration tooling and funding through the Migration Acceleration Program, Migration Hub, Application Discovery Service, MGN, DMS, Mainframe Modernization and AWS Professional Services; (2) portfolio discovery, wave planning and execution from a systems integrator such as Accenture, Deloitte, Cognizant, PwC, Devoteam or Cloud4C; (3) compliance and audit assurance from an accredited assessor such as Coalfire; (4) a run-time platform that operates the migrated applications, either DIY on EKS with Terraform, a multi-tenant PaaS, or an internal developer platform such as Qovery in your own account.

I have interviewed more than 200 CTOs, and large AWS migrations fail the same way almost every time. The enterprise buys layers 1 to 3 in three neat lots, the waves land, the integrator's badge comes off the building, and then everyone discovers layer 4 the week after cut-over. The applications are on AWS. No developer can ship to them without a ticket, and nobody signed up to produce governance evidence for every production deploy.

Layer 1 - AWS native. The Migration Acceleration Program (MAP) is the program spine; underneath sit MGN for rehosting servers, DMS for databases, Application Discovery Service and Migration Hub for discovery and tracking, and Mainframe Modernization for the COBOL estate. One live caveat: AWS has closed Migration Hub and Application Discovery Service to new customers as of November 7, 2025 and now points new programs to AWS Transform, its agentic successor launched in May 2025. Confirm the current tooling path with your AWS account team before you write it into an RFP.

Layer 2 - systems integrators. Accenture, Deloitte, Cognizant, PwC, Devoteam and Cloud4C own discovery at scale, dependency mapping, wave planning, the business case, licence renegotiation and change management across hundreds of applications. These firms do real work Qovery does not do. Require the AWS Migration and Modernization Competency and check each partner's current tier on the AWS Partner finder rather than trusting a logo on a slide.

Layer 3 - compliance and assurance. Coalfire is an accredited FedRAMP Third Party Assessment Organization (3PAO), a PCI Qualified Security Assessor and a HITRUST assessor. This layer attests, it does not migrate, and independence rules usually stop the same firm building the environment and auditing it. Its harder deliverable is the continuous evidence pipeline that has to keep producing after the assessor leaves.

Layer 4 - the platform that runs the applications. DIY on EKS or ECS with Terraform and CI/CD, a multi-tenant PaaS such as Heroku or AWS Elastic Beanstalk, a home-built internal platform, or an internal developer platform such as Qovery running inside your own account. Each layer has to produce one clear decision before the next can start, which is exactly how a CIO should cut the RFP: one lot per layer, named interfaces between lots, and an acceptance criterion per lot, including a run-time governance evidence requirement for layer 4.

How do you decide between rehost, replatform, refactor, retire and the rest of AWS's 7 Rs for each legacy application?

AWS Prescriptive Guidance defines seven migration strategies - retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect - and the decision is made per application archetype after discovery, never per portfolio. In a large legacy estate the long tail is rehosted with AWS MGN, applications under active development are replatformed onto containers, refactoring is reserved for the few applications with a written business case, and retire plus repurchase are applied aggressively because discovery routinely surfaces applications nobody uses.

Here is the definition in one quotable paragraph, straight from AWS: retire decommissions applications you no longer need; retain keeps applications in place that you are not ready to move; rehost is lift-and-shift with no code change; relocate moves a hypervisor or platform (VMware-style) without re-architecting; repurchase is drop-and-shop, replacing an app with a SaaS or different product; replatform is lift-tinker-and-shift, moving to the cloud with some optimization such as containers or a managed database; and refactor or re-architect, which AWS calls the most complex and costly, rewrites the application to use cloud-native features.

Discovery comes first, always. AWS Application Discovery Service collects configuration and utilization data, with an agentless collector for VMware inventory and a per-server agent that captures processes and inbound/outbound network connections so you can map dependencies into real applications. AWS Migration Evaluator is a complimentary service that turns that inventory into a directional business case. Again, note the currency point: Application Discovery Service is closed to new customers, and AWS routes new discovery through AWS Transform, so plan your discovery tooling around what your account actually has access to.

The archetype rules I use are simple. VM-based COTS goes rehost with MGN. Monolithic Java and .NET under active development goes replatform onto containers. Oracle and SQL Server-backed apps split into DMS for the data and a rehost or replatform for the app tier. Batch and mainframe-adjacent workloads go to Mainframe Modernization or stay retained until a business case exists. Anything with an active product team and a roadmap is the strongest replatform candidate, because that is where a self-service platform starts paying back immediately rather than at the end of the program.

Replatform-to-containers holds most of the enterprise value, and it is the point where the layer 4 platform choice starts to matter - not at the end of the program. Over-refactoring is the classic budget sink: waves stall while money burns on the small slice of the portfolio that actually justified a rewrite. And the two Rs enterprises forget to evaluate are relocate and repurchase. Both can remove an application from audit scope entirely, which is often cheaper than migrating and then having to govern it.

What governance and compliance controls must be live before the first migration wave lands?

Before application number one lands you need five things in production: a multi-account structure via AWS Organizations with AWS Control Tower or Landing Zone Accelerator on AWS, preventive and detective guardrails via Service Control Policies and Control Tower controls, centralised identity in IAM Identity Center with no standing production access, organisation-wide CloudTrail, and an automated evidence pipeline through AWS Config conformance packs and Security Hub standards. Retrofitting these across a landed portfolio is where enterprise migration programs blow their budget.

Baseline architecture. AWS Organizations gives you the account boundary, and its published quotas comfortably cover a portfolio of hundreds of applications: the default of 10 accounts is a soft limit AWS will raise up to 50,000 accounts, with organizational units nestable five levels deep. On top of that, AWS Control Tower controls come in three behaviors: preventive (implemented as Service Control Policies, resource control policies and declarative policies), detective (implemented as AWS Config rules), and proactive (implemented as CloudFormation hooks). If you prefer code over console, Landing Zone Accelerator on AWS deploys a foundation across more than 35 AWS services, with sample configurations mapped to FedRAMP, CMMC, NIST 800-171, Germany's C5, ISO 27001 and HIPAA. AWS is explicit that the accelerator does not make you compliant by itself; it gives you the foundation you then have to operate.

Identity. Centralise on IAM Identity Center, federate to your existing IdP over SAML 2.0 with SCIM provisioning, and remove standing production access in favour of a break-glass procedure. That central model has to map down to per-environment RBAC for dozens or hundreds of delivery teams, or you will recreate ticket queues you were trying to kill.

Evidence and audit. Turn on an organisation trail in CloudTrail, deploy AWS Config conformance packs for PCI DSS, HIPAA, NIST 800-53 and CIS, and enable the relevant Security Hub standards: AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 and PCI DSS. AWS Audit Manager ships prebuilt frameworks including PCI DSS, HIPAA, SOC 2 and ISO 27001, though AWS has closed it to new customers, so build the durable pipeline on Config and Security Hub and pull AWS-side attestations from AWS Artifact. AWS itself reports 143 security standards and compliance certifications behind the platform, but that is security of the cloud; the evidence for your workloads is yours to produce.

Data residency and sovereignty. Region choice is a control, not a preference. For the strictest cases AWS offers GovCloud (US) for ITAR, DoD and FedRAMP High workloads, and the AWS European Sovereign Cloud, a more than 7.8 billion euro investment with its first Region in Brandenburg, Germany, operated by EU residents with metadata kept in the EU. Decide who holds the KMS keys - customer-managed keys mean you do - before any regulated data moves.

Shared responsibility in writing. Anchor everything to the AWS Shared Responsibility Model: AWS owns security "of" the cloud, you own security "in" the cloud. Then split "in the cloud" further across the systems integrator, the platform layer and your own team. This written split is the artefact auditors ask for first, and the one most programs cannot produce.

Which AWS migration partners and platforms belong on the shortlist, and where does each genuinely fit?

Shortlist by layer: AWS Professional Services and MAP for native tooling, funding and Region-level design; a global systems integrator (Accenture, Deloitte, Cognizant, PwC, Devoteam, Cloud4C) for portfolio-scale discovery, wave execution and change management; an accredited 3PAO or QSA such as Coalfire for regulated audit evidence; a multi-tenant PaaS (Heroku, AWS Elastic Beanstalk) for a narrow slice of stateless applications; and an internal developer platform such as Qovery for the post-migration platform layer inside your own account. These are complements, not substitutes, and no single vendor covers all four layers credibly.

Let me be precise about Qovery, because credibility depends on it. Qovery is not a migration consultancy. It does not run discovery or wave planning, it does not do mainframe or COBOL conversion, and it does not sign your audit report. Pair it with the right integrator and the right assessor for those.

What Qovery does do is layer 4: git-push deployments from GitHub, GitLab or Bitbucket, preview environments per pull request that are torn down automatically, environment auto-stop for non-production, orchestrated managed cluster upgrades, per-environment RBAC scoped per project and environment type, and databases backed by managed cloud services such as RDS - all inside the customer's own cloud account.

The BYOC model is the point for governance. Your data and compute stay in your account, your own SCPs and KMS keys still apply, your CloudTrail remains the audit trail, and the cloud bill plus your Enterprise Discount Program terms and Savings Plans stay in your name because the resources run in your account. That is the structural difference from a multi-tenant PaaS, and it is why Qovery survives a compliance review: nothing leaves your boundary.

Qovery is also Kubernetes-native and multi-cloud, not AWS-only. It runs on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster including self-managed and on-prem, which matters when an enterprise runs a second cloud or a residual on-prem estate mid-migration. Escaping one lock-in only to buy another is not progress.

Heroku deserves a fair hearing. It solved developer self-service before almost anyone, and Heroku Private Spaces plus Shield address HIPAA and PCI for regulated cases. But Heroku runs on Salesforce-controlled infrastructure with no bring-your-own-account model, so the compliance boundary is the vendor's rather than yours. AWS Elastic Beanstalk does deploy into your own account and supports Go, Java, .NET, Node.js, PHP, Python, Ruby and Docker, which keeps it in scope for a narrow slice of apps. Note that AWS App Runner is now closed to new customers, so do not build a new program around it. For most regulated enterprises, multi-tenant PaaS is still ruled out for data residency, VPC peering, audit scope and egress cost reasons.

How long does migrating hundreds of legacy applications to AWS take, and what does it really cost?

Plan in phases, not a single cut-over date. AWS structures the Migration Acceleration Program in three phases - assess, mobilize, and migrate and modernize - and in a portfolio of hundreds of applications the assess plus mobilize work (discovery, business case, landing zone build) consumes the opening months before waves run in parallel. The dominant cost variable is people-time on dependency untangling and replatforming, not AWS compute or the migration tooling itself.

The phases, as AWS publishes them: assess identifies capability gaps across the six dimensions of the Cloud Adoption Framework; mobilize closes those gaps and builds the operational foundation and landing zone; migrate and modernize executes the plan with AWS and partner engineers. AWS does not publish a MAP funding percentage on that page, so treat any specific offset figure as a conversation with AWS and your Migration Competency partner, not a fact.

The migration engines are cheap relative to headcount. AWS MGN gives you a free replication period of 2,160 hours - 90 days of continuous use - per source server, after which you pay per hour, and you still pay for the EC2 and EBS the replication provisions. AWS DMS has a free tier that varies by signup date and a serverless option billed per data capacity unit. By contrast, the run-time baseline is a real recurring line: an EKS control plane costs 0.10 US dollars per cluster per hour on standard support and 0.60 US dollars per cluster per hour once a version enters extended support. Multiply that across dozens of clusters and it adds up, but it is still dwarfed by the people cost of untangling dependencies.

Rank your cost drivers accordingly: discovery quality first, then dependency untangling, then licence renegotiation, then dual-running two environments during cut-over, and finally the DevOps and platform headcount that stays after the integrator leaves. The last one is the line most RFPs leave blank.

Costs quietly overrun after cut-over, not during it. Non-production environments running 24/7, over-provisioned clusters, per-team Terraform sprawl and orphaned resources are the usual suspects. Flexera's 2025 State of the Cloud Report puts self-estimated wasted spend on IaaS and PaaS at 27 percent, and the concrete levers against it are boring: environment auto-stop for non-production and per-environment ownership so someone is accountable for every running resource. The scale of the problem is not hypothetical either - McKinsey found that only 15 percent of companies migrated more than 60 percent of their IT-hosting spend to the cloud within the timeline they set.

Size waves so that wave one is deliberately boring: low-dependency, low-compliance-scope applications whose only job is to prove the landing zone and the deploy path. Prove the machine on apps that cannot hurt you, then accelerate.

Who runs the applications after they land on AWS, and how do you avoid rebuilding a platform team from scratch?

The systems integrator leaves after the final wave and the run cost stays, so the operating model decides whether the migration pays off. You have three realistic choices: staff a platform engineering team to build and maintain EKS plus Terraform plus CI/CD, run AWS-managed services driven by heavy Terraform with a ticket for every environment request, or adopt an internal developer platform such as Qovery that gives developers self-service inside your already-governed accounts. Each has a defensible case, and the deciding factors are time to first deploy, platform headcount, and which governance controls you get without building them.

The upgrade burden alone is worth pricing. AWS gives each Kubernetes minor version 14 months of standard support and then 12 months of extended support, so a DIY team is on a roughly annual upgrade treadmill across every cluster, forever. That is real, recurring headcount, not a one-off.

What developers need on day one is narrow and non-negotiable: deploy without a ticket, an ephemeral environment per pull request for review, and access scoped to the environments they own. What the CISO needs on day one is equally narrow: an audit trail per deploy, no standing production access, and a documented cluster patching cadence. A good operating model delivers both lists at once, or it is not a platform, it is a backlog.

Qovery's role here is one paragraph: self-service on your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, with managed cluster upgrades, per-environment RBAC, preview environments per pull request and environment auto-stop for non-production. Developers get the first list, the CISO gets the second, and it all happens inside accounts you already govern.

Be honest about the trade-off: an internal developer platform is opinionated. Teams with deep Kubernetes expertise and genuinely unusual requirements - exotic networking, custom schedulers, research workloads - may legitimately prefer to build, and for them DIY on EKS is the right call. For everyone else, building a platform team from scratch to reproduce features that already exist is how you spend two years and a lot of headcount rediscovering the same problems.

The payoff for getting self-service right is measurable. DORA's 2025 research reports that internal developer platform adoption has become nearly universal, with 90 percent of organizations using one and 76 percent running dedicated platform teams - while cautioning that platforms improve productivity and organizational performance but can hurt throughput and stability if they are not run well. The tool is not the win. A well-operated layer 4 is.

Frequently asked questions

What cloud migration services does an enterprise need for a large legacy application portfolio on AWS?

Buy four layers together: AWS native programs and tooling (MAP, MGN, DMS, Control Tower or Landing Zone Accelerator), a systems integrator with the AWS Migration and Modernization Competency (Accenture, Deloitte, Cognizant, PwC, Devoteam or Cloud4C), an independent compliance assessor such as Coalfire if you need attestation, and the run-time platform your teams inherit on day 2. The classic mistake is buying the first three and leaving the fourth unowned, which is where governance evidence and developer self-service quietly fall through.

How do I choose between AWS Professional Services, a global systems integrator like Accenture or Deloitte, and a compliance specialist like Coalfire?

They do different jobs and you often need all three. AWS Professional Services is strongest co-building the landing zone and the MAP mobilize phase; a systems integrator like Accenture or Deloitte carries the scale, dependency mapping and organizational change to run dozens of waves; and Coalfire independently assesses and attests, which independence rules usually prevent the builder from doing. Budget them as separate lots with named interfaces between them.

What are the 7 Rs of cloud migration, and how do I apply them across hundreds of legacy applications?

The 7 Rs are retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Apply them per application archetype after discovery, not per portfolio: rehost the low-change long tail with MGN, replatform apps under active development onto containers, reserve refactoring for the few with a written business case, and use retire and repurchase aggressively because discovery always surfaces apps nobody needs.

Which compliance frameworks can we evidence on AWS, and which AWS services produce that evidence?

You can evidence PCI DSS, HIPAA, SOC 2, ISO 27001, NIST 800-53, CIS and FedRAMP-aligned controls on AWS. The producing services are AWS Config conformance packs and Security Hub standards for continuous control evidence, CloudTrail for the audit log, and AWS Artifact for AWS-side attestations. Remember the shared responsibility model: AWS attests to security "of" the cloud, but the evidence for your workloads is yours to produce.

Is Qovery a cloud migration partner, or something else?

No, Qovery is not a migration consultancy and does not replace one. It does not run discovery or wave planning, it does not do mainframe or COBOL conversion, and it does not sign your audit report. Qovery is layer 4: the internal developer platform that runs your applications inside your own cloud account after they land, with git-push deployments, preview environments, auto-stop, managed cluster upgrades and per-environment RBAC.

Can we keep our AWS Enterprise Discount Program pricing and Savings Plans if we run applications through Qovery?

Yes, your Enterprise Discount Program terms and Savings Plans stay in your name because Qovery deploys into your own account, so the resources are billed to you directly. This BYOC model means the cloud bill, VPCs, KMS keys and CloudTrail all stay under your control, which is the structural difference from a multi-tenant PaaS. Qovery is also available on the AWS Marketplace, so its own subscription can count toward your EDP commitment.

How do we give hundreds of developers self-service deployments on AWS without breaking governance?

Put the guardrails in the account first (Organizations, SCPs, IAM Identity Center, CloudTrail, Config), then layer self-service on top so every deploy runs through the same governed path. An internal developer platform like Qovery gives developers preview environments per pull request and git-push deploys while the CISO keeps per-environment RBAC, no standing production access and a consistent audit trail per deploy. The alternative - a ticket per environment - is what kills the velocity you migrated for.

The short version: buy all four layers, choose partners by workload archetype, put governance live before wave one, and treat the run-time platform as a contractual requirement rather than an afterthought. The layer enterprises forget is the one their developers live in every day after the integrator goes home.