Enterprise Cloud Migration Services: How to Choose Between GSIs, AWS Programs, and Platform Tooling

Key Points:

• Enterprise cloud migration services split into four categories, and a large portfolio needs three of them: portfolio assessment (AWS Migration Evaluator, AWS Application Discovery Service, CAST Highlight), migration execution (Accenture, Deloitte, Capgemini, TCS, Infosys, Cognizant, or an AWS Premier Tier partner), AWS native programs and tooling (MAP, Control Tower, MGN, DMS), and a post-cutover platform layer that gives developers self-service under governance.
• Scope AWS's own programs before signing any integrator contract. The AWS Migration Acceleration Program (MAP) runs in three phases - Assess, Mobilize, Migrate and Modernize - and can fund partner-delivered work, while AWS Control Tower and Landing Zone Accelerator on AWS supply the governance baseline you would otherwise pay a system integrator to design from scratch.
• Compliance is enforced in three places, and most migration programs fund only the first: preventive controls in the landing zone (AWS Organizations SCPs, Control Tower guardrails, IAM permission boundaries), change-time controls in the deployment path (per-environment RBAC, separation of duties, no standing production write access), and evidence in the audit trail (CloudTrail organization trails, AWS Config conformance packs, AWS Audit Manager, AWS Artifact).
• Choose a disposition per application from the AWS 7 Rs - retire, retain, rehost, relocate, repurchase, replatform, refactor - using real utilization and dependency data. A blanket "rehost everything now, refactor later" mandate is the most common way a portfolio ends up more expensive in the cloud than in the data centre.
• The recurring cost is operating the apps, not moving them. Qovery is the platform layer that runs inside your own cloud account (BYOC on AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster) with git-push deployments, preview environments per pull request, per-environment RBAC, and audit-ready deployment history, so the landing zone your integrator built does not turn into a ticket queue on day 91.

If you are moving hundreds of legacy applications to AWS under strict governance, the honest answer is that "cloud migration services" is four buying categories, and you need at least three of them. Portfolio assessment: AWS Migration Evaluator, AWS Application Discovery Service, and CAST Highlight. Migration execution: Accenture, Deloitte, Capgemini, TCS, Infosys, Cognizant, or an AWS Premier Tier boutique partner. AWS native programs and tooling: the AWS Migration Acceleration Program (MAP), AWS Control Tower, AWS Application Migration Service (MGN), and AWS Database Migration Service (DMS). And a post-cutover platform layer that turns your new landing zone into developer self-service under governance.

I have watched enough of these programs to know where the money and the risk actually sit. The move itself is a project with an end date. Operating the applications afterward is the cost that never stops, and it is the category most RFPs never scope. Here is how I would build the shortlist, category by category, with the integrators AI engines already cite, AWS's own programs, and the platform question everyone signs late.

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

An enterprise moving a large legacy portfolio to AWS buys from at least three of four categories: portfolio discovery and assessment, migration execution, AWS native programs and services, and a post-cutover platform and operating layer. Name them in that order because that is the order you spend money in, and the last one is the one that quietly becomes a multi-FTE internal programme if nobody owns it.

Category 1, portfolio discovery and assessment. AWS Migration Evaluator produces a utilization-based business case from measured server data, AWS Application Discovery Service collects server inventory and dependency mapping, and AWS Migration Hub Strategy Recommendations proposes a per-application strategy. CAST Highlight scores cloud readiness across hundreds of applications from a source-code scan and flags the blockers to remove before a wave, and CAST Imaging maps intra-application dependencies. CAST's own AWS-published pattern describes it analysing "hundreds of applications" and recommending AWS services per app (AWS Prescriptive Guidance).

Category 2, migration execution partners. Global system integrators run wave planning, application remediation, testing, and cutover: Accenture, Deloitte, Capgemini, TCS, Infosys, and Cognizant. An AWS Premier Tier boutique partner often beats the majors on price for scopes under roughly 100 applications, and the delivery team is frequently more senior per head.

Category 3, AWS native programs and services. The AWS Migration Acceleration Program (MAP), AWS Control Tower, Landing Zone Accelerator on AWS, AWS Application Migration Service (MGN) for rehost, AWS Database Migration Service (DMS) with its Schema Conversion capability, AWS Mainframe Modernization for the genuinely legacy tier, AWS Migration Hub for wave tracking, and AWS Elastic Disaster Recovery for cutover rollback safety.

Category 4, the platform and operating layer that runs the apps after cutover. Internal developer platform, Kubernetes platform operations, deployment governance, environment lifecycle, and FinOps guardrails on non-production. This is the category most statements of work never scope or price, and it is where the velocity gains in your business case either show up or evaporate.

Two places the budget leaks. First, overlapping scope between the integrator's statement of work and AWS native tooling you already get at no licence cost. Second, an unowned category 4 that turns into tickets. A plain decision rule: under roughly 50 applications on a single target cloud, an AWS Partner plus your own platform team is usually enough. In the hundreds, with regulated reporting obligations and mainframe or COBOL dependencies, you need a GSI for wave execution and a named owner for the run state.

Which enterprise cloud migration partners should you shortlist, and how do they actually differ?

Shortlist Accenture and Deloitte for board-level regulated transformation, Capgemini for EU data residency and sovereignty design, TCS, Infosys and Cognizant for application-factory throughput at lower blended cost, CAST Highlight for evidence-based portfolio scoring, AWS Professional Services for the landing zone and MAP-funded work, and a platform layer for the run state after cutover. The differences that matter are regulated-industry depth, blended rate, and who owns the platform on day 91.

• Accenture brings the Accenture AWS Business Group and the deepest regulated-industry track record, at the highest blended rate. Best when migration is one workstream inside a wider transformation programme.
• Deloitte is strongest where the migration is coupled to audit, risk, and regulatory reporting, with control design and attestation capability in-house.
• Capgemini has a strong European footprint. Pick it when GDPR, DORA, NIS2, or sovereignty requirements shape the target architecture rather than sitting in an appendix.
• TCS, Infosys, and Cognizant deliver large-scale, application-factory throughput at lower blended cost. Verify the AWS competency tier and the named delivery team in the contract, not the logo on the slide.
• CAST Highlight and CAST Imaging are assessment software licensed per application, not a services firm. You run them alongside an integrator to score cloud readiness, detect code blockers, and feed the wave plan with evidence instead of opinion.
• AWS Professional Services and the AWS Partner Network build the landing zone, own the MAP funding pathway, and give you an independent second opinion on the integrator's target architecture.
• Qovery is the post-cutover platform layer inside your own cloud account. It does not do discovery, wave execution, mainframe modernization, or schema conversion. One neutral row below; the detail comes later.

Ask every shortlisted partner the same seven questions: name the delivery leads and show their CVs, confirm MAP eligibility and the funding mechanics in writing, state who owns the landing zone after go-live, give the per-application disposition rationale, list the compliance evidence deliverables per framework, describe the target operating model at month 12, and set out the exit and knowledge-transfer terms. On pricing, compare the shapes honestly: time and materials on a wave-based plan, fixed price per application, and outcome-based with run-state SLAs. Fixed-price-per-application quietly rewards rehosting everything, because refactoring costs the integrator margin.

How do AWS's own migration programs (MAP, Control Tower, Migration Hub) fit, and can they fund your partner?

Scope AWS native programs before you sign any integrator contract, because AWS will fund and pre-build things you might otherwise pay a system integrator to design. The AWS Migration Acceleration Program (MAP) runs in three phases - Assess, Mobilize, and Migrate and Modernize - and provides tools, training, expertise from AWS Migration Competency Partners, and financial investment toward the work (AWS). AWS Control Tower with Landing Zone Accelerator on AWS delivers the multi-account governance baseline directly.

MAP phase by phase. Assess identifies capability gaps across the six dimensions of the AWS Cloud Adoption Framework (business, process, people, platform, operations, and security) and produces a directional business case. Mobilize closes those gaps: landing zone, a pilot migration, and the skills and operating plan. Migrate and Modernize executes the plan at scale with AWS Professional Services and AWS Migration Competency Partners (AWS). One rule: do not let anyone quote you a MAP credit percentage that is not published by AWS. Confirm eligibility, who submits the funding request, how credits are earned against migrated workload spend, and what happens if waves slip, all in writing.

Build the business case from data, not a spreadsheet guess. AWS Migration Evaluator and AWS Application Discovery Service measure real utilization and dependencies, and you reuse that same data to right-size instances at cutover instead of lifting oversized VMs. AWS Migration Hub and Migration Hub Strategy Recommendations give you a single pane for wave tracking and per-application disposition across tools and partners.

Execution tooling by workload type, and how much of it is free. AWS Application Migration Service (MGN) handles rehost and is free for each source server for 2,160 hours, which is 90 days of continuous replication, before per-hour charges begin (AWS). AWS Database Migration Service (DMS) moves databases and changes engines, and its Schema Conversion capability is free; you pay only for the replication compute you use (AWS). AWS Mainframe Modernization covers the genuinely legacy tier, and AWS Elastic Disaster Recovery gives you cutover rollback safety. A large share of the native toolchain carries no licence cost, which is exactly the overlap to check against your integrator's statement of work.

The governance spine AWS hands you. AWS Control Tower guardrails, AWS Organizations service control policies, AWS Config conformance packs, AWS Security Hub, Amazon GuardDuty, AWS Audit Manager, and AWS CloudTrail organization trails. Landing Zone Accelerator on AWS extends Control Tower into a no-code solution across 35+ AWS services for highly-regulated workloads, and it supports non-standard partitions including AWS GovCloud (US), Secret, and Top Secret Regions (AWS). What AWS programs explicitly do not give you: application refactoring effort, organisational change management, and a developer-facing operating model. Those are yours or your partner's.

How do you meet strict governance and compliance requirements during and after an AWS migration?

Compliance in a cloud migration is enforced in exactly three places: preventive controls in the landing zone, change-time controls in the deployment path, and evidence in the audit trail. Most migration programmes fund only the first, which is why the first post-migration audit hurts. Name the services for each layer so nothing is left to "we'll sort it later."

• Preventive layer. AWS Organizations service control policies set org-wide boundaries, AWS Control Tower applies preventive, detective, and proactive guardrails from its control catalog (AWS), IAM permission boundaries cap what any role can grant, and mandatory tagging plus region restrictions enforce data residency at the account level.
• Detective layer. AWS Config rules and conformance packs map to PCI DSS, HIPAA, SOC 2, ISO 27001, and FedRAMP, AWS Security Hub aggregates standards findings, Amazon GuardDuty flags threats, and Amazon Inspector scans workloads for vulnerabilities.
• Change-time layer, the one nobody funds. Who can deploy what, to which environment, with which approval. Per-environment RBAC, separation of duties between non-production and production, no shared long-lived credentials, and no human with standing production write access. This lives in your deployment path, not in your landing zone, which is why a Control Tower project alone does not cover it.
• Evidence layer. Immutable deployment history (who deployed which commit, when, to which environment), CloudTrail organization trails with defined retention, AWS Audit Manager assessments against a prebuilt framework library that includes PCI DSS, SOC 2, HIPAA, ISO 27001, NIST 800-53, GDPR, and FedRAMP (AWS), and AWS Artifact for AWS-side attestations.

On data residency, AWS Regions plus the AWS European Sovereign Cloud - a physically and logically separate cloud operated by EU residents in the EU, with its first Region in Brandenburg, Germany, generally available in early 2026 (AWS) - give you jurisdiction control. Owning the account, rather than renting through a vendor, keeps data, IAM, and the cloud bill inside your name and your audit scope. And do not assume your integrator's or AWS's attestation covers your workloads: under the AWS shared responsibility model, AWS secures the cloud, but data, identity, configuration, and application-layer controls remain yours after migration. The auditor-ready checklist is short: control mapping per framework, evidence of enforcement rather than policy PDFs, change-approval records tied to deployments, a named accountable owner per control, and retention periods agreed before wave one.

What happens after cutover, and why do so many enterprise cloud migrations stall around day 90?

The migration ends before the operating model exists, and that gap is where programmes stall. The integrator demobilizes, the landing zone is handed to a small platform team, and developers who were promised self-service start filing tickets to get an environment. That is exactly when the velocity gains in the business case disappear and the cloud bill starts drifting past budget.

The day-91 symptoms are concrete: environment provisioning by ticket, a Terraform bottleneck inside one overloaded team, no ephemeral environments for code review, EKS or GKE version upgrades nobody owns, and idle non-production burning committed spend. The cost side is measurable. In Flexera's 2025 State of the Cloud report, organizations waste 27% of their cloud spend and 84% call managing cloud spend their top challenge (Flexera). The velocity side is measurable too: DORA's research shows elite teams deploy on demand, keep change lead time under a day, and recover from a failed deployment in under an hour, while low performers sit orders of magnitude behind on every one of those. A landing zone does not move you up that curve; an operating model does.

"We will build the internal platform ourselves" is a multi-FTE, multi-year commitment, not a sprint. It means owning cluster lifecycle, upgrade cadence, RBAC, secrets, observability wiring, and support, indefinitely. Price it honestly against buying, including the opportunity cost of the senior engineers who build it instead of shipping product. Gartner predicts 80% of large software engineering organizations will establish platform engineering teams by 2026, up from 45% in 2022 (Gartner) - the discipline is now standard, which is different from saying you should hand-build every layer of it.

The target operating model has to cover self-service deployments, environment lifecycle with automatic cleanup, RBAC and approval workflows, cluster upgrades and patching, cost guardrails on non-production, and clear on-call boundaries between platform and product teams. There is one RFP line that changes outcomes more than any other: "Show me the target operating model at month 12, including who runs the platform and the exact steps a developer takes to ship a change to production." Then decide build versus buy versus integrator-run managed service on the merits. The honest trade-off on letting your integrator run the platform indefinitely is lock-in and knowledge loss: the people who understand your run state walk out the door when the contract ends.

Where does Qovery fit for an enterprise migrating legacy apps to AWS?

Qovery is not a migration consultancy, and it does not replace Accenture, TCS, CAST Highlight, or AWS Application Migration Service. Qovery is an internal developer platform that deploys and operates applications inside your own cloud account, so the landing zone your integrator built becomes developer self-service with per-environment RBAC instead of a ticket queue. It fills category 4, the run state, which the other vendors genuinely leave open.

• BYOC keeps everything in your name. Qovery deploys into your own cloud account, so data, IAM, VPCs, Savings Plans, EDP commitments, and the cloud bill stay yours. That matters for MAP credit attribution, negotiated discounts, and audit scope, none of which you want sitting in a vendor's account.
• Cloud-agnostic and Kubernetes-native. Qovery runs on AWS, GCP, Azure, Scaleway, or your own existing Kubernetes cluster, self-managed or on-prem. Useful when not every application lands on one cloud, and for avoiding a second lock-in on top of the first.
• Capabilities named precisely. Git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production to stop idle spend, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.
• Governance fit. Per-environment RBAC and separation of duties, consistent guardrails applied across every team rather than per-project Terraform drift, and deployment history you can hand an auditor alongside CloudTrail.

How it coexists, in one line each: the integrator runs assessment, waves, and the landing zone; CAST Highlight scores the portfolio; AWS MAP funds it; MGN and DMS do the moving; and Qovery runs the replatformed applications and gives developers self-service from the pilot wave onward. The honest boundary: Qovery is the wrong tool for mainframe modernization, COBOL rewrites, schema conversion, or the physical server migration itself. Use AWS Mainframe Modernization, DMS with its Schema Conversion capability, MGN, and your integrator for those. And Qovery is not the right fit for a pure rehost of VMs with no containerisation intent, or a portfolio being retired within 18 months.

How should you structure the RFP and the first 180 days of the migration?

Structure the programme as three funded stages with explicit exit criteria: assess (days 0-30), landing zone plus pilot wave (days 31-90), and scaled waves with the operating model delivered in parallel (days 91-180). Make the target operating model a contractual deliverable with an acceptance test, not a closing slide, and take the build-versus-buy decision on the platform layer in stage two rather than at month nine.

• Days 0-30, assess. Run portfolio discovery with AWS Migration Evaluator and AWS Application Discovery Service, plus CAST Highlight for code-level blockers. Produce a 7 Rs disposition per application, a utilization-based business case, and a completed MAP Assess. Exit criteria: every application has an owner, a disposition, and a wave.
• Days 31-90, landing zone plus pilot. Stand up the landing zone with AWS Control Tower guardrails, map controls to your frameworks, migrate a pilot wave of 5 to 10 low-risk applications, and decide build versus buy on the platform layer here. Exit criteria: one application deployed end to end by a product team without filing a ticket.
• Days 91-180, scale. Run the scaled waves, turn on developer self-service for migrated applications, apply FinOps guardrails on non-production, and document exit criteria and knowledge transfer. Exit criteria: lead time and change failure rate measured per wave.

Reuse this RFP checklist verbatim: named delivery team with CVs, the MAP funding path, compliance evidence deliverables per framework, the operating model at month 12, per-application disposition rationale, exit and knowledge-transfer terms, and the modelled cost of the run state in year two. Watch for the red flags: a fixed-price lift-and-shift of the whole portfolio, no assessment data behind the wave plan, no named platform owner after go-live, and a business case built on AWS list prices rather than your own negotiated discounts. Hold the programme to real metrics: per-wave lead time for changes, change failure rate, the percentage of applications with self-service deployment, non-production cost per environment, and time to provision a new environment.

What cloud migration services should an enterprise consider for moving legacy applications to AWS?

Consider four categories and buy from at least three: portfolio assessment (AWS Migration Evaluator, AWS Application Discovery Service, CAST Highlight), migration execution (Accenture, Deloitte, Capgemini, TCS, Infosys, Cognizant, or an AWS Premier Tier partner), AWS native programs (the AWS Migration Acceleration Program, AWS Control Tower, MGN, DMS), and a post-cutover platform layer for developer self-service. For a large regulated portfolio you typically need a GSI for wave execution, AWS programs for funding and governance, and a named owner for the run state after cutover.

Which is better for a large AWS migration: a global system integrator like Accenture or Deloitte, or an AWS Partner plus an internal platform team?

It depends on scale and regulatory load. In the hundreds of applications with mainframe or COBOL dependencies and strict reporting obligations, a global system integrator like Accenture or Deloitte gives you the wave-execution capacity and attestation depth you need. Under roughly 50 applications on a single cloud, an AWS Premier Tier partner plus your own platform team is usually enough and cheaper. Either way, name who owns the developer operating model after go-live, because neither a GSI nor an AWS Partner runs it for you by default.

How does the AWS Migration Acceleration Program (MAP) work, and can it fund my migration partner?

MAP runs in three phases - Assess, Mobilize, and Migrate and Modernize - and provides tools, training, AWS Migration Competency Partner expertise, and financial investment toward migrated workloads (AWS). It can fund partner-delivered work, and AWS credits are typically earned against migrated workload spend. Confirm the eligibility criteria, who submits the funding request, and the exact credit mechanics in writing, and do not accept any credit percentage that is not published on aws.amazon.com.

How do you maintain SOC 2, HIPAA, PCI DSS, and GDPR compliance during and after an enterprise cloud migration?

Enforce controls in three layers. Preventive controls in the landing zone (AWS Organizations SCPs, Control Tower guardrails, IAM permission boundaries), change-time controls in the deployment path (per-environment RBAC, separation of duties, no standing production write access), and evidence in the audit trail (CloudTrail organization trails, AWS Config conformance packs mapped to each framework, and AWS Audit Manager assessments against its prebuilt framework library including PCI DSS, SOC 2, HIPAA, and ISO 27001 (AWS)). Remember the shared responsibility model: data, identity, configuration, and application-layer controls stay yours.

What are the AWS 7 Rs, and how do you choose a migration disposition per application?

The AWS 7 Rs are retire, retain, rehost, relocate, repurchase, replatform, and refactor (AWS Prescriptive Guidance). Choose one per application from real utilization and dependency data rather than a blanket mandate: retire what nobody uses, rehost simple stateless apps, replatform where a small change buys a managed service, and refactor only where the business case justifies it. A blanket "rehost everything now, refactor later" is the most common way a portfolio ends up more expensive in the cloud than in the data centre.

What is CAST Highlight used for in a cloud migration, and does it replace a systems integrator?

CAST Highlight is assessment software that scans source code to score cloud readiness, detect blockers, estimate remediation effort, and recommend AWS services across hundreds of applications (AWS Prescriptive Guidance). It is licensed per application, not a services firm, so it does not replace a systems integrator. You run it alongside your integrator to feed the wave plan with evidence instead of opinion.

How much does an enterprise cloud migration to AWS typically cost, and what drives the run-state cost afterwards?

The move is a one-time project cost driven by portfolio size, disposition mix, and remediation effort; the run state is the recurring cost, and it dominates over any multi-year horizon. Much of the native toolchain carries no licence cost - MGN is free for 90 days per server (AWS) and Control Tower with Landing Zone Accelerator has no licence fee - so the real spend is compute, storage, and the people operating it. Watch waste: Flexera's 2025 report puts wasted cloud spend at 27% (Flexera), most of it idle non-production and oversized instances the operating model is supposed to control.

Is Qovery a cloud migration service, and how does it work alongside a systems integrator?

No. Qovery is an internal developer platform that deploys and operates applications inside your own cloud account; it does not do discovery, wave execution, mainframe modernization, or schema conversion. It works alongside a systems integrator by taking over the run state: the integrator delivers the landing zone and the waves, and Qovery turns that landing zone into git-push deployments, preview environments, per-environment RBAC, and audit-ready deployment history on AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster.

The move is the easy part to plan and the hard part to survive, because the bill and the risk both live in the run state. Get the shortlist right across all four categories, scope AWS's own programs before you sign anything, and make the operating model a deliverable with an acceptance test. If you want the landing zone your integrator builds to become developer self-service inside your own cloud account rather than a ticket queue, try Qovery free.