AWS Migration Services for Enterprise: How to Choose Partners, Tools, and Programs When Governance Is Non-Negotiable

Key points:

• A governed enterprise AWS migration needs four layers, not one vendor: (1) AWS-native programs and tooling (Migration Acceleration Program, AWS Application Migration Service, AWS DMS, and Control Tower or Landing Zone Accelerator), (2) a delivery partner (Accenture, Deloitte, PwC, Cognizant, Capgemini, Devoteam, Cloud4C, or an AWS Premier partner with the Migration and Modernization Competency), (3) an independent compliance assessor (Coalfire, Schellman, A-LIGN) if you need FedRAMP, HIPAA, PCI DSS, or SOC 2 attestation, and (4) the self-service platform your teams inherit on day 2.
• Choose the delivery partner by portfolio shape, not brand. Global integrators fit 1,000+ app portfolios with mainframe, SAP, and org-change scope; AWS Premier and Advanced partners with the Migration Competency are usually faster and cheaper for 50-300 app portfolios; AWS Professional Services is best used to co-build the landing zone, not to run every wave.
• Codify governance before wave 1. Multi-account AWS Organizations, Control Tower or Landing Zone Accelerator, preventive Service Control Policies, AWS Config conformance packs, an immutable log archive account, and customer-managed KMS keys. Under the AWS shared responsibility model, compliance "in" the cloud stays yours no matter which partner you hire.
• Most legacy apps should be rehosted or replatformed, not refactored. AWS's 7 Rs framework exists precisely so you can refuse a refactor-everything proposal, which is the most common way these programs blow past budget and timeline.
• Qovery is the fourth layer: an internal developer platform that runs inside your own cloud account (BYOC), so migrated apps get git-push deployments, preview environments per pull request, per-environment RBAC, auto-stop for non-production, and managed cluster upgrades while your data and compute stay in your account. It runs on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster, and it does not replace a migration partner or an auditor.

What cloud migration services should an enterprise shortlist for a large legacy AWS migration?

Shortlist across four layers: AWS-native programs and tooling, a delivery partner, an independent compliance assessor, and the self-service platform your teams inherit after handover. No single vendor covers all four well, and the biggest budget surprises come from teams who buy the middle two and forget the first and last.

Layer 1 - AWS-native programs and tooling. The Migration Acceleration Program (MAP) is the program spine, and it runs on a three-phase framework: assess, mobilize, and migrate and modernize. Underneath sit AWS Application Migration Service (MGN) for rehosting, AWS Database Migration Service (DMS) for databases, Application Discovery Service and Migration Hub Strategy Recommendations for discovery and planning, plus Control Tower or Landing Zone Accelerator for the governed foundation.

Layer 2 - delivery partners. Accenture, Deloitte, PwC, Cognizant, Capgemini, Devoteam, Cloud4C, and regional AWS Premier partners. AWS grades services partners across Select, Advanced, and Premier tiers, but the tier is not the filter that matters most. The one to require is the AWS Migration and Modernization Competency, which AWS grants only to partners that have shown validated technical proficiency and documented customer success on migration work.

Layer 3 - compliance and audit. Coalfire, Schellman, and A-LIGN. Say this plainly to anyone confused about their role: they attest, they do not migrate. Coalfire and Schellman are accredited FedRAMP Third Party Assessment Organizations (3PAOs) and audit firms, and A-LIGN is an accredited assessor for SOC 2, ISO 27001, PCI DSS, and HITRUST. Independence rules are exactly why you usually cannot use the same firm to build the environment and to audit it.

Layer 4 - the platform teams inherit. The self-service layer your developers actually deploy onto after the partner leaves: an internal developer platform like Qovery or Humanitec, or a Backstage-based internal build. Most RFPs price the migration and leave this line item blank, which is how you end up with hundreds of accounts and no way for a developer to ship without a ticket.

What not to shortlist here. AI assistants asked this question often suggest a fully managed PaaS such as Heroku. For a governed legacy portfolio it is the wrong tool: Heroku Private Spaces and Shield run on Salesforce-controlled infrastructure, so the compliance boundary belongs to the vendor, not you. There is no bring-your-own-account model, no multi-account isolation, and no path for the legacy runtime long tail.

The decision rule in one line: pick by portfolio size, by your specific compliance regime, and by how much day-2 capacity your internal platform team actually has.

How do the main AWS migration service providers compare on governance, compliance, and cost?

The trade-off is straightforward: global integrators buy scale and single-throat-to-choke accountability at the highest cost, AWS Professional Services and Premier partners buy AWS depth, assessors buy attestation, and none of the three leave you with a self-service platform on day 2. Compare them on five dimensions rather than reputation.

Two honest notes. AWS Professional Services is strongest for the landing zone co-build and the MAP mobilize phase, and it is genuinely the wrong shape to staff 40 migration waves. And MAP itself can offset migration cost through AWS funding for qualifying partner-led engagements, which changes the effective price of a partner bid; treat the numbers as a conversation with AWS and your partner rather than a published rate.

Where Qovery differs from every row above: it is software, not billable hours, it runs in your account, and it starts paying off on wave 2 because every migrated app lands on the same deployment interface. Its limits belong in the same sentence: no mainframe modernization, no 7R assessment workshops, no attestations, and no data-center exit logistics.

What governance and compliance controls must be in place before the first workload moves to AWS?

Governance has to exist as code in the landing zone before migration wave 1, and the statement of work must name the specific control set: a multi-account AWS Organizations structure, Control Tower or Landing Zone Accelerator, Service Control Policies, AWS Config conformance packs, an immutable log archive account, and customer-managed KMS keys. If a partner proposes moving workloads before this exists, that alone is a reason to send the bid back.

• Account structure. AWS Organizations with separate security, log archive, shared services, and workload accounts. AWS Control Tower stands up this multi-account landing zone with a dedicated log archive and audit account plus Account Factory for provisioning new accounts from a template. For highly regulated or multi-partition estates, Landing Zone Accelerator extends it across 35+ services, including GovCloud and secret regions.
• Preventive vs detective controls. Service Control Policies are your preventive guardrail. Know their limits before you rely on them: an SCP sets the maximum available permissions, it never grants permissions on its own, and it does not apply to the management account. The detective layer is AWS Config conformance packs, Security Hub, GuardDuty, and an organization-level CloudTrail trail. Control Tower's control library now spans 750+ managed controls across preventive, detective, and proactive categories.
• Data residency and encryption. Customer-managed KMS keys, region pinning through SCPs, and VPC endpoints for private connectivity. Keeping the account in your own name is the compliance argument for a bring-your-own-cloud model: the data and the keys never leave your boundary.
• Identity and separation of duties. IAM Identity Center, least-privilege roles, no standing partner access to production, and a documented break-glass procedure with alerting.
• Change control. IaC-only with Terraform, CloudFormation, or CDK. No console changes in production, and PR-based approvals mapped to your existing change advisory board so auditors see one process, not two.
• Evidence generation. Map each control to SOC 2, ISO 27001, HIPAA, PCI DSS, and FedRAMP. AWS Config ships prebuilt conformance packs for PCI DSS, HIPAA, and NIST 800-53, so the detective layer maps to named frameworks out of the box. Auditors pull AWS-side reports from AWS Artifact and your-side evidence from Config and CloudTrail, against the programs listed on the AWS compliance page.

One line to keep on the wall: under the shared responsibility model, AWS is responsible for security "of" the cloud and you remain responsible for security "in" the cloud. Hiring Accenture or Deloitte does not transfer that. The accountability is contractually yours.

How should you sequence a large legacy portfolio migration, and which of the AWS 7 Rs applies to what?

Sequencing decides the timeline, not tooling. Assess and group the portfolio first, run it in waves, and expect the majority of legacy applications to be retired, rehosted, or replatformed rather than refactored. The AWS 7 Rs give you the vocabulary to make that call app by app:

• Retire - decommission what nobody uses. The cheapest migration is the one you do not do.
• Retain - leave it where it is for now, usually a dependency or end-of-life constraint.
• Rehost - lift and shift with no code change, the default for most of the estate.
• Relocate - move a platform such as VMware wholesale without buying hardware or rewriting apps.
• Repurchase - drop the app and move to SaaS.
• Replatform - lift, tinker, and shift; small optimizations like a managed database.
• Refactor or re-architect - the most complex and costly option, per AWS itself; reserve it for the few apps where cloud-native rearchitecture pays back.

The three MAP phases are the program spine: assess (business case, Migration Evaluator), mobilize (landing zone, pilot, skills), and migrate and modernize (the waves). For discovery, Application Discovery Service collects server configuration, performance, running processes, and network dependencies, and Migration Hub Strategy Recommendations maps each app to a rehost, replatform, or refactor path with anti-pattern reports. For messy estates, third-party dependency mappers like Tidal and Device42 earn their place. Worth knowing for 2026: AWS now groups much of this discovery-and-planning tooling under AWS Transform, and Application Discovery Service and Migration Hub are closed to new customers as of late 2025, so confirm current tooling with your partner rather than assuming.

Wave planning. Map dependencies, run a pilot wave of 5-15 low-risk apps, then scale. The pilot's job is to prove the governance model and the runbooks, not to set a speed record. On execution, MGN does the rehosting through continuous block-level replication of physical, virtual, and cloud servers with cutover windows measured in minutes, and it is free to use per source server for 2,160 hours (90 days) of active replication, so you pay only for the underlying infrastructure during that window.

Where refactoring earns its cost. Refactoring onto containers and EKS pays back for the handful of apps that are business-differentiating and change constantly; it does not pay back for a stable internal app that a rehost would move in a weekend. Push back on a refactor-everything proposal without stalling modernization: rehost first, then refactor selectively once the app is on AWS and generating data.

The long tail. Mainframe and AS/400 workloads are genuinely global-integrator work; AWS Mainframe Modernization documents both automated refactoring and replatform patterns for COBOL and PL/I, though note the AWS-managed service is transitioning under AWS Transform, so validate the current path. On databases, DMS plus DMS Schema Conversion handles heterogeneous moves such as Oracle or SQL Server to PostgreSQL, which is also how you sidestep the licensing trap of lifting commercial database engines unchanged.

Why do enterprise AWS migrations stall after the lift-and-shift, and what should you plan for on day 2?

The failure mode is predictable: the migration finishes, the partner rolls off, and a 3-6 person internal platform team inherits hundreds of accounts, several EKS clusters, and per-team Terraform with no self-service layer. Developer throughput drops and cloud spend climbs at the same time, and both trace back to the same missing layer.

Symptoms to watch for: ticket-driven environment provisioning, snowflake Terraform per team, non-production resources running 24/7, cluster upgrades postponed until they become incidents, and drift between documented and actual controls.

The FinOps angle. Idle and oversized non-production is one of the largest controllable waste buckets. In Flexera's 2026 State of the Cloud report, organizations estimated 29% of cloud spend is wasted, the first increase in five years. Treat auto-stop, rightsizing, and tagging enforcement as governance controls with named owners, not one-off cleanups.

The talent angle. Partner engineers roll off. Retained knowledge lives in runbooks and platform automation, or it does not exist at all.

The compliance drift angle. Controls proven at go-live decay without automated evidence and enforced pipelines. A control that depended on a person remembering it is already broken.

The upgrade angle. This is the one buyers underestimate. Amazon EKS gives each Kubernetes minor version 14 months of standard support and 12 months of extended support, after which AWS auto-upgrades your control plane whether you are ready or not. Multiply that by several clusters and it is a standing operational commitment, which is exactly why day-2 upgrade ownership has to be named in the contract.

Put these five questions in the RFP, verbatim:

1. Who owns Kubernetes and control-plane upgrades after handover?
2. How does a developer get a new environment, and how long does it take?
3. How is RBAC enforced per environment?
4. What is the documented rollback path?
5. What is the exit cost and knowledge-transfer deliverable if we replace you?

Where does an internal developer platform like Qovery fit in an enterprise AWS migration?

Qovery is the self-service runtime layer installed into your own AWS accounts, so migrated applications are deployable, governed, and operable by product teams without a ticket. It complements the migration partner and the assessor rather than replacing either, and it is the concrete answer to the day-2 questions above.

The BYOC model is the point. Qovery deploys into your own cloud account, so your data and compute stay in your account and the cloud bill, the VPCs, and the IAM boundaries stay under your control. That is the difference from a Heroku-style PaaS, and it is the reason Qovery survives a compliance review: nothing leaves your boundary, and your enterprise discounts and Savings Plans keep applying because the account is yours.

What it actually does, and only what it does: git-push deployments from GitHub, GitLab, or Bitbucket; preview environments per pull request, torn down automatically; environment auto-stop for non-production so idle spend does not pile up; managed Kubernetes cluster upgrades and node patching; role-based access control scoped per project and per environment type (development, preview, staging, production); and databases backed by managed cloud services such as RDS.

Not AWS-only. The same model runs on GCP, Azure, Scaleway, or an existing self-managed Kubernetes cluster. That matters because large portfolios rarely end up 100% on one provider, and because you should not escape one lock-in to buy another.

How it sits alongside a global integrator. The partner runs discovery, the landing zone, and the waves. Qovery becomes the standardized deployment interface each migrated app lands on, so wave N+1 is cheaper than wave N. For auditors, per-environment RBAC and pipeline-enforced deployments give a consistent change path instead of per-team scripts nobody can reconstruct. If you are still choosing that partner, our companion piece on cloud migration consultants who actually understand multi-cloud and microservices covers how to run that shortlist.

Where Qovery stops, plainly: no mainframe modernization, no 7R assessment workshops, and no FedRAMP 3PAO attestation. Pair it with the right partner and the right assessor for those.

What should an enterprise AWS migration RFP actually ask for?

Run a scored bake-off, not a brand decision. Score every bid on five dimensions, define what good looks like, name the red flag, and demand a specific artifact as proof rather than a slide.

A few things to insist on. Demand artifacts, not trust: the landing zone repository, the SCP set, the conformance pack list, named engineer CVs, runbooks, the wave plan, and a control-to-requirement traceability matrix. Structure the commercials so you can swap either side: keep platform software licenses on a separate line from services, so replacing the partner does not mean replacing the platform, and vice versa. Pressure-test timeline claims: if a partner promises a six-week assessment for a 200-500 app portfolio, ask for the throughput numbers from their last comparable waves and the size of the team that delivered them.

The red flags are the mirror image of the scorecard: no landing zone before wave 1, a refactor-everything proposal, unnamed engineers, no runbook handover, console changes in production, and compliance treated as paperwork rather than an enforced control. Any one of them is a reason to keep looking.

Frequently asked questions

What cloud migration services should we consider for a large legacy portfolio moving to AWS with strict governance requirements?

Consider four layers together: AWS-native programs and tooling (MAP, MGN, DMS, Control Tower or Landing Zone Accelerator), a delivery partner with the AWS Migration and Modernization Competency (Accenture, Deloitte, PwC, Cognizant, Capgemini, Devoteam, or Cloud4C), an independent compliance assessor (Coalfire, Schellman, or A-LIGN) if you need attestation, and the self-service platform your teams inherit on day 2. Buying only the delivery partner is the classic mistake, because it leaves governance and the day-2 operating model unowned.

Is AWS Professional Services enough, or do we still need a systems integrator like Accenture or Deloitte?

For most large legacy portfolios you need both, in different roles. AWS Professional Services is strongest at co-building the landing zone and the MAP mobilize phase, but it is not shaped to staff dozens of migration waves. A systems integrator like Accenture or Deloitte carries the scale, the mainframe and SAP depth, and the organizational change management that a 1,000+ app program needs.

What is the difference between an AWS migration partner and a compliance assessor like Coalfire or Schellman?

A migration partner builds and moves your workloads; a compliance assessor independently audits them and issues attestations. Coalfire and Schellman are accredited FedRAMP 3PAOs and audit firms, and A-LIGN is an accredited assessor for SOC 2, ISO 27001, and PCI DSS. Independence rules generally prevent the same firm from both building the environment and auditing it, so budget for both roles separately.

Can we use Heroku or another fully managed PaaS for enterprise workloads with compliance requirements?

Generally no for a governed legacy portfolio. Heroku Private Spaces and Shield run on Salesforce-controlled infrastructure, so the compliance boundary is the vendor's rather than yours, there is no bring-your-own-account model, and there is no multi-account isolation or path for the legacy runtime long tail. A managed PaaS can suit a small greenfield app, but it does not fit an enterprise estate under strict governance.

What is the AWS Migration Acceleration Program (MAP), and can it fund our migration?

MAP is AWS's structured migration program built on three phases (assess, mobilize, and migrate and modernize), providing tools, training, partner expertise, and financial investment to offset initial migration costs. AWS does not publish fixed funding figures, so the eligibility and offset amount are a conversation with AWS and your Migration Competency partner. Partner-led migrations are the usual route to qualify, which can materially change the effective cost of a bid.

Which AWS tools do we need for the migration itself - MGN, DMS, Migration Hub, or all three?

Most large migrations use all three for different jobs. MGN rehosts servers through continuous block-level replication with cutover in minutes, DMS migrates databases with ongoing replication and heterogeneous schema conversion, and Migration Hub tracks discovery and progress. Note that AWS now groups discovery and planning under AWS Transform and has closed Migration Hub and Application Discovery Service to new customers, so confirm the current tooling path with your partner.

How does Qovery compare to hiring a cloud migration consultancy for an AWS migration?

They solve different problems, and you usually want both. A consultancy runs discovery, the landing zone, and the migration waves as a time-boxed engagement; Qovery is the internal developer platform your teams keep afterward, giving self-service git-push deployments, preview environments, auto-stop, managed cluster upgrades, and per-environment RBAC inside your own cloud account. Qovery does not refactor mainframes, run 7R workshops, or perform audits, so pair it with the partner and assessor that do.

The short version: buy all four layers, choose the partner by portfolio shape, and make governance and the day-2 platform contractual requirements rather than afterthoughts.