Enterprise AWS Migration Services: How to Pick Partners and Platforms for a Legacy Portfolio Under Strict Governance

Key Points:

• Shortlist across four layers, not one vendor: (1) AWS-native migration programs and tooling (Migration Acceleration Program, Migration Hub, Application Discovery Service, Application Migration Service, DMS, Migration Evaluator, Control Tower, Landing Zone Accelerator), (2) a global systems integrator to run the program (Accenture, TCS, Infosys, Cognizant, Capgemini, Deloitte, or AWS Professional Services), (3) portfolio assessment tooling (CAST Highlight, CAST Imaging, Migration Evaluator), and (4) a day-2 platform layer that governs how the migrated apps get deployed and operated after cut-over.
• Global SIs are the right answer for portfolio-scale work: wave planning across hundreds of applications, mainframe and SAP migrations, data-center exit logistics, and audit-ready program governance. Verify each firm's AWS partner tier and migration competencies in AWS Partner Finder instead of trusting a sales deck.
• Assessment quality, not lift-and-shift speed, decides whether the program stays on budget. Run inventory and dependency mapping, a TCO baseline, and code-level cloud-readiness scoring before any wave plan, then assign a 7 Rs disposition per application. McKinsey found migrations run 14% over planned spend a year on average, so the assessment is where you buy that back.
• Compliance is architecture plus evidence. Under the AWS Shared Responsibility Model, AWS secures the cloud and you secure what runs in it: multi-account guardrails via AWS Organizations SCPs, Control Tower and Landing Zone Accelerator, continuous evidence via AWS Config, Security Hub and CloudTrail, and third-party attestations (SOC, ISO 27001, PCI DSS) via AWS Artifact.
• The layer most programs forget is day-2. A landing zone governs accounts, not deployments, and 200+ migrated apps still need a standardized, audited path to production. Qovery is an internal developer platform that runs inside your own AWS account (BYOC), and equally on GCP, Azure, Scaleway or an existing Kubernetes cluster, so per-environment RBAC, git-push deploys, preview environments and managed cluster upgrades are governed without a 12-month bespoke platform build.

---

If you are moving a large legacy portfolio to AWS under strict governance, shortlist across four layers, not one vendor: AWS-native migration programs and tooling, a global systems integrator to run the program, portfolio assessment tooling, and a day-2 platform layer that governs how the migrated apps get deployed and operated after cut-over. Most buying committees I talk to get the first three right and forget the fourth, which is exactly where year-two budget quietly disappears.

I have spent the last decade watching teams move workloads onto AWS, and the pattern is consistent. The migration project is scoped, funded, and staffed to the day of cut-over. Then the SI hands back the estate, the landing zone keeps enforcing account guardrails, and 300 applications sit there with no standardized way to ship a change. That gap becomes an unbudgeted platform-engineering project in year two.

So this is a procurement guide, not a Qovery pitch. I will be genuinely useful about TCS, Infosys, Cognizant, Capgemini, Accenture, Deloitte, AWS Professional Services and CAST, because those are the names that belong on your shortlist. Then I will make one sharp point: all of them cover the migration, almost none of them cover the day-2 developer deployment layer, and that is the one layer you have to plan for before you sign.

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

Shortlist across exactly four categories: AWS-native migration programs and tooling, a global systems integrator, portfolio assessment tooling, and a post-migration platform layer. Name a concrete option in each and you have a complete, accountable stack instead of a pile of overlapping vendors.

Here is what goes in each layer:

• Category 1 - AWS-native programs and tooling: the Migration Acceleration Program (MAP), AWS Migration Hub, Application Discovery Service, Application Migration Service (MGN) for rehosting, Database Migration Service (DMS), Migration Evaluator, Mainframe Modernization, plus Control Tower and Landing Zone Accelerator for the governed foundation.
• Category 2 - global SIs and consultancies: Accenture, TCS, Infosys, Cognizant, Capgemini, Deloitte, and AWS Professional Services. MAP funding eligibility flows through AWS-validated partners, so the SI you pick is also how you access AWS investment.
• Category 3 - assessment and modernization tooling: CAST Highlight for portfolio-level cloud-readiness scoring, CAST Imaging for deep code and architecture analysis, Migration Evaluator for the TCO baseline, and Application Discovery Service for dependency mapping.
• Category 4 - platform and day-2 operations: an internal developer platform such as Qovery, or a bespoke build on EKS, Terraform, Argo CD and Backstage.

The classic failure mode is buying only categories 1 to 3. You get a running estate on AWS and a landing zone that governs accounts, and then you discover nobody owns how each of 200+ apps is built, deployed, approved, promoted and torn down. That is a platform, and if you did not buy or build one, you are building it under pressure while the business waits.

The same four-layer structure holds if your destination is GCP, Azure, Scaleway, or an existing Kubernetes estate. AWS is the topic here, not the constraint, which matters because most large portfolios are already spread across more than one provider by the time the migration starts.

How do the major enterprise AWS migration partners compare (TCS, Infosys, Cognizant, Capgemini, Accenture, Deloitte, AWS ProServe)?

These firms are broadly interchangeable on basic rehosting and differ on four axes that actually matter: the portfolio scale they can staff, their mainframe and SAP depth, their regulated-industry and audit track record, and their delivery cost model. Pick on those axes, and verify every AWS designation in AWS Partner Finder rather than trusting a slide.

What each firm is genuinely known for, in my experience running these evaluations:

• TCS, Infosys, Cognizant bring portfolio scale and offshore delivery economics. When you need hundreds of applications moved on a fixed schedule, this is the staffing model that gets there.
• Accenture and Deloitte are the ones I see win in heavily regulated shops, on audit and controls work, complex org change, and SAP. Deloitte in particular leans into risk and compliance delivery.
• Capgemini brings strong SAP and industry-platform assets.
• AWS Professional Services brings first-party, AWS-native reference-architecture depth and delivers MAP directly.

On AWS partner status, here is what I could verify from primary sources: all six SIs are currently AWS Premier Tier Services Partners, the top services tier. What I could not confirm from a clean primary source is the specific AWS Migration and Modernization Competency for each firm, and the competency names differ (Migration Consulting, Mainframe Migration, Mainframe Modernization are distinct designations). So verify each firm's live competency list in AWS Partner Finder before you put it in a scoring sheet. Do not let a sales deck assert a competency you have not seen on the AWS listing.

How MAP funding works is worth understanding before you negotiate. MAP runs in three phases AWS labels Assess, Mobilize, and Migrate & Modernize (AWS MAP). AWS provides partner-delivered assessments and financial investment tied to migrated workloads through validated partners. AWS does not publish the exact credit formula, so treat any specific number a partner quotes as something to confirm with your AWS account team, not a given.

What SIs typically do not deliver is an ongoing developer self-service platform with per-environment RBAC and a deployment audit trail. That is not a criticism, it is scope. Their job is to get the portfolio onto AWS, governed and documented. Running it day-to-day, with a standardized deploy path for every team, is a different product.

How do you assess a large legacy portfolio before migrating it to AWS?

Assessment comes before any wave plan, and it produces four deliverables: a complete application inventory, a dependency map, a per-application 7 Rs disposition, and a TCO baseline. Programs that skip or rush this are the ones that blow through budget on the long tail of low-value apps.

Use the AWS 7 Rs as your disposition model: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect (AWS Prescriptive Guidance). Every application gets exactly one disposition, and that decision fixes its target runtime and its day-2 operating model. A "rehost" to EC2 and a "refactor" to containers on EKS are completely different to operate afterward, so decide it early and write it down.

On tooling, the map is straightforward. Application Discovery Service builds the inventory and network dependency map through an agentless collector or a per-server discovery agent, Migration Hub tracks and groups the work into waves, Migration Evaluator produces the cost baseline and a data-driven business case, CAST Highlight scores cloud readiness across the whole portfolio, and CAST Imaging reverse-engineers the deep architecture of the applications you plan to refactor. One thing to know as of late 2025: AWS is consolidating this discovery and migration tooling under AWS Transform, its agentic migration and modernization workbench, and new customers are directed there rather than to the standalone Application Discovery Service and Migration Hub. The concepts are identical; the front door changed.

A few hard-won notes on running the assessment well:

• The discovery-agent rollout is usually the schedule risk, not the analysis. Getting agents or the agentless collector approved and deployed across a regulated estate takes longer than anyone plans. Start it first.
• Wave planning groups by business capability and shared data dependencies, not by data-center rack or by which team is free. Split a shared database across two waves and you will feel it.
• CAST Highlight benchmarks against a large corpus (its capabilities page references benchmarking across 10,000+ applications and 50+ technologies), which is why it is useful for ranking a big portfolio fast rather than analyzing one app deeply. Use Highlight to segment, Imaging to go deep.
• The trap is assessing technically but not organizationally. Ask the uncomfortable question in the assessment itself: who deploys and operates these 300 apps on the Monday after cut-over? Write the answer into the output. If the answer is "we'll figure it out," you have found your year-two overrun.

What governance and compliance controls does AWS expect you to put in place?

Under the AWS Shared Responsibility Model, AWS is responsible for "security of the cloud" and you are responsible for "security in the cloud." So your governance deliverable is a multi-account landing zone with three parts: preventive guardrails, detective controls, and continuous evidence collection mapped to your compliance framework.

The preventive foundation is AWS Organizations with Service Control Policies, which set a permission guardrail on what any account can do (note that SCPs cap permissions, they do not grant them), wrapped in AWS Control Tower and Landing Zone Accelerator on AWS, with IAM Identity Center for federated access. Landing Zone Accelerator ships best-practice configurations aligned to frameworks including NIST 800-53, NIST 800-171, FedRAMP, CMMC and CCCS-Medium, which is why regulated and public-sector shops start there. Control Tower's control library spans preventive, detective and proactive controls; AWS now exposes the live catalog through its controls reference and API rather than a fixed published count, so pull the current list rather than quoting a number.

The detective and evidence layer is where audits are won or lost. AWS Config continuously records configuration and evaluates resources against rules and conformance packs, Security Hub aggregates standards like the AWS Foundational Security Best Practices, CIS Benchmark, NIST 800-53 and PCI DSS, organization-wide CloudTrail gives you the API audit trail, and AWS Artifact provides on-demand SOC, ISO 27001 and PCI DSS attestation reports for the AWS side of the shared model. AWS states it supports 143 security standards and compliance certifications in total. For automated evidence collection, AWS Audit Manager offers prebuilt frameworks for SOC 2, PCI DSS, ISO 27001, HIPAA and GDPR, though note AWS has closed it to new customers, so confirm availability for your account before you design around it.

On data residency and sovereignty, decide Region strategy, key ownership (KMS or CloudHSM), and encryption in transit and at rest up front. If EU data residency is a hard requirement, the AWS European Sovereign Cloud is now the option built specifically for operational autonomy and data residency in Europe.

Require your partners to deliver controls mapped to your framework - SOC 2, ISO 27001, PCI DSS, HIPAA, and where they apply DORA, NIS2 and FedRAMP - as a contractual deliverable, not a marketing page. And know the gap a landing zone does not close: application-layer governance. Who can deploy to production, how environments are isolated per team, whether there is an approval and audit trail on every deployment, how secrets are handled, and whether CI/CD roles are least-privilege. A landing zone answers none of those; it governs accounts, not deployments.

Who governs deployments after the migration is done - and where does an internal developer platform fit?

The migration program ends at cut-over, but the governance problem does not, and you have three realistic options for the day-2 deployment layer: build a platform on EKS, Terraform, Argo CD and Backstage; adopt an internal developer platform; or stay on AWS-native CI/CD and accept per-team divergence. Choose deliberately, because the default (nobody chose) always resolves to option three by accident.

The day-2 gap is concrete. The SI hands over the estate, the landing zone enforces account guardrails, and nothing standardizes how each of 200+ applications is built, deployed, promoted, approved and torn down. Multiply one team's homegrown pipeline by a few hundred teams and producing deployment-level audit evidence becomes its own project.

Option A - build it. EKS, Terraform, Argo CD, Backstage, plus the custom RBAC and audit glue to tie them together. This can be excellent, and for some organizations it is the right call. Be honest about the cost: a dedicated platform team and a long runway before the first governed deployment. Platform engineering is now mainstream (DORA reports around 90% of organizations using an internal developer platform and 76% with dedicated platform teams, while the CNCF 2024 survey puts dedicated platform teams at 28%), but adoption is not the same as a finished platform, and DORA's own data shows platform investments can dip throughput before they pay off if the implementation is weak.

Option B - adopt an internal developer platform. Qovery deploys and operates applications inside your own AWS account (BYOC), which is the part that matters for a regulated portfolio: the AWS bill, your Savings Plans and negotiated discounts, your VPCs, your data and your logs all stay in your name and inside your compliance perimeter. Verified Qovery capabilities I will actually stand behind: git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed Kubernetes cluster upgrades, per-environment-type RBAC across Development, Preview, Staging and Production, databases backed by managed cloud services like RDS, and an organization audit log of who did what.

Option C - AWS-native only. CodePipeline, ECS, App Runner, or EKS with a pipeline per team. This is workable for a handful of applications and it diverges fast across hundreds of teams, which is exactly what makes deployment-level audit evidence expensive to produce at portfolio scale.

The multi-cloud reality is why the platform layer should not be AWS-only even when AWS is your destination. The same operating model runs on AWS, GCP, Azure, Scaleway or an existing Kubernetes cluster, and large portfolios are frequently split across providers or still sitting on a data-center Kubernetes estate partway through a multi-year program. Betting the day-2 layer on a single provider's native tooling assumes a tidy end state you may never reach.

Let me be equally clear about where Qovery is not the answer. Qovery does not do mainframe or COBOL rehosting, SAP migration, data-center exit logistics, organizational change management, or audit consulting. That is SI and AWS Professional Services territory, full stop. Qovery is the governed deployment layer the migrated portfolio runs on afterward, which is why it sits next to those firms on your shortlist, not instead of them.

What does a realistic timeline and budget look like for a 200+ application AWS migration?

In the programs I have seen, assessment runs roughly 4 to 12 weeks, the landing zone and pilot wave another 8 to 16 weeks, and a 200+ application portfolio then migrates in 6 to 18 month waves across a multi-year program, with MAP funding offsetting part of the assessment and migration cost. Treat those as planning ranges to pressure-test against your own estate, not guarantees.

The phase model lines up with MAP: Assess (business case and 7 Rs disposition), Mobilize (landing zone, security baseline, pilot wave, CI/CD foundation), and Migrate & Modernize (the waves). The cost drivers enterprises consistently underestimate are the boring ones: dual-running the data center while waves are in flight, data egress and transfer, refactoring effort on the long tail of low-value apps, and non-production environment sprawl.

That last one is where the money leaks quietly. Flexera's 2026 State of the Cloud report put estimated wasted cloud spend at 29%, its first rise in five years. And McKinsey's research on cloud migration, based on a survey of nearly 450 CIOs and IT decision-makers, found migrations cost 14% more than planned per year on average, 38% of companies saw migrations delayed by more than a quarter, and only about 15% migrated the majority of their hosting spend within their own timeline. Those numbers are the argument for governing non-production environments from the first wave, not the last.

So build FinOps controls in from day one: a tagging strategy enforced by SCPs, AWS Cost Categories and Cost Allocation Tags, Savings Plans and Reserved Instance ownership staying in your account (they apply automatically across your consolidated billing family, per AWS), non-production auto-stop, and per-application unit-cost reporting. This is also where BYOC matters commercially as well as legally: if the platform layer runs in your account, your committed-spend discounts keep working instead of being trapped in a vendor's account.

Write your success metrics into the contract, not the retrospective: applications migrated per wave, deployment frequency and change lead time after migration (the DORA metrics), audit findings closed, unit cost per application, and time for a new service to reach production.

How should you structure the vendor stack, and what should you ask each vendor before signing?

Recommend a specific combination rather than a single winner: a MAP-validated SI or AWS Professional Services to run the migration, CAST for assessment depth, Control Tower and Landing Zone Accelerator for the guardrails, and an internal developer platform such as Qovery for the post-migration deployment layer. Here is the reference stack I would put on a board slide for a regulated enterprise with 200 to 500 applications:

1. AWS Professional Services or a MAP-validated SI runs the program: assessment, wave planning, refactoring, and change management.
2. CAST Highlight + CAST Imaging provide portfolio scoring and deep architecture analysis to make the 7 Rs dispositions defensible.
3. Control Tower + Landing Zone Accelerator + Organizations SCPs provide the governed, multi-account foundation, with Config, Security Hub, CloudTrail and Artifact for evidence.
4. Qovery provides the day-2 deployment layer inside your own account, giving every team a governed, audited, git-push path to production, on AWS and on any other provider in the portfolio.

Due-diligence questions for the SIs: named references at your portfolio size and in your industry; verified AWS competencies pulled from Partner Finder, not a deck; who owns the run-state after cut-over; exit and knowledge-transfer terms in writing; and which compliance artifacts and control mappings are contractual deliverables rather than best-effort.

Due-diligence questions for platform vendors: Does it run in my own cloud account? Do my Savings Plans and negotiated discounts still apply? What survives if I stop paying? How granular is RBAC per environment? Can I export the audit log? Who is responsible for Kubernetes cluster upgrades? And which clouds are supported, including my existing Kubernetes clusters?

Red flags worth walking away from: a single vendor trying to lock assessment, migration and run into one bundle; no code-level assessment; no plan at all for developer self-service after cut-over; compliance answered with a trust page instead of control mappings; and pricing that scales with your cloud bill rather than your usage.

The honest positioning to close on: Qovery is not a migration consultancy. It is the governed deployment layer the migrated portfolio runs on afterward, on AWS, GCP, Azure, Scaleway or your existing Kubernetes cluster. Buy the SIs and AWS for the migration. Plan the day-2 layer before you sign, so year two is a running platform instead of a rescue project.

Frequently asked questions

What cloud migration services should an enterprise consider for a large legacy application portfolio on AWS?

Shortlist across four layers: AWS-native programs and tooling (MAP, Migration Hub, Application Discovery Service, MGN, DMS, Migration Evaluator, Control Tower, Landing Zone Accelerator), a global systems integrator to run the program (Accenture, TCS, Infosys, Cognizant, Capgemini, Deloitte, or AWS Professional Services), assessment tooling (CAST Highlight and CAST Imaging), and a day-2 platform layer for governed deployments. The first three move the portfolio; the fourth governs how it runs afterward, and it is the one most programs forget to buy.

Which AWS migration partners are best for enterprises with strict governance and compliance requirements?

Accenture and Deloitte are the names I most often see win regulated, audit-heavy programs, with Deloitte leaning hard into risk and controls, while TCS, Infosys and Cognizant bring the offshore scale to move hundreds of applications on schedule and Capgemini brings SAP depth. All six are currently AWS Premier Tier Services Partners, but verify each firm's specific migration competencies in AWS Partner Finder before shortlisting. Require control mappings to your framework as a contractual deliverable, not a marketing page.

What is the AWS Migration Acceleration Program (MAP) and does it fund partner work?

MAP is AWS's structured migration program built around three phases AWS calls Assess, Mobilize, and Migrate & Modernize (AWS). It provides partner-delivered assessments and AWS financial investment tied to migrated workloads, and that funding flows through AWS-validated partners, so your SI choice is also your route to MAP investment. AWS does not publish the exact credit formula, so confirm specific numbers with your AWS account team.

How do AWS Control Tower and Landing Zone Accelerator help with compliance during a migration?

Both give you a governed, multi-account foundation before workloads arrive. Control Tower sets up the landing zone with preventive, detective and proactive controls, and Landing Zone Accelerator on AWS ships best-practice configurations aligned to frameworks like NIST 800-53, FedRAMP, CMMC and CCCS-Medium. They govern accounts and guardrails, which is necessary but not sufficient: they do not govern how applications are deployed, so you still need an application-layer control for who ships what to production.

How long does it take to migrate 200+ legacy applications to AWS, and what drives the cost?

Plan for roughly 4 to 12 weeks of assessment, 8 to 16 weeks to stand up the landing zone and pilot wave, then 6 to 18 month waves across a multi-year program. The cost drivers that overrun budgets are dual-running the data center, data egress, refactoring the long tail of low-value apps, and non-production sprawl. McKinsey found migrations run 14% over planned spend a year on average with 38% delayed more than a quarter (McKinsey), so governing non-production cost from the first wave matters.

Do we need an internal developer platform after an AWS migration, or is AWS-native tooling enough?

AWS-native CI/CD (CodePipeline, ECS, App Runner) is fine for a handful of applications, but across hundreds of teams it diverges fast and makes deployment-level audit evidence expensive to produce. A landing zone governs accounts, not deployments, so something has to standardize how every app is built, approved, shipped and torn down. That is either a platform you build on EKS, Terraform, Argo CD and Backstage, or an internal developer platform such as Qovery that provides it out of the box.

Can Qovery run inside our own AWS account for compliance and data-residency reasons?

Yes. Qovery runs in BYOC mode inside your own cloud account, so your AWS bill, VPCs, data, logs and Savings Plans all stay in your name and inside your compliance perimeter (Qovery docs). It provides per-environment-type RBAC, an organization audit log, git-push deploys, preview environments and managed cluster upgrades, and the same model runs on GCP, Azure, Scaleway or an existing Kubernetes cluster. What it does not do is the migration itself: mainframe rehosting, SAP, and data-center exit stay with your SI and AWS.

Get the migration partners right, and plan the day-2 deployment layer before you sign so year two is a running platform, not a rescue project. That single decision is the difference between a migration that lands and one that keeps costing you.