AWS MAP vs Google Migration Center vs Azure Migrate: which one actually funds a PaaS exit in 2026?

Key points:

• Only one of the three is a funding program. The AWS Migration Acceleration Program (MAP) bundles assessment, AWS "financial investments" and partner delivery. Google Cloud Migration Center and Azure Migrate are free assessment tools. The money on those clouds sits in sibling programs: Google's Rapid Migration and Modernization Program (RaMP) and Microsoft's Azure Accelerate, the program that absorbed Azure Migrate and Modernize in 2025 and now runs as Frontier Accelerate for Azure.
• All three were built for datacenter, VM and database estates. Their discovery tooling inventories servers, VMware hosts and SQL instances, so none of them will find Heroku dynos, Render services, Vercel projects, Fly machines or Platform.sh containers. A PaaS exit gets scoped as application modernization.
• Real money flows through a partner or account team on all three clouds. Self-serve gets you the free tooling and none of the funding, so budget the partner statement of work before you count the credits.
• Credits pay for the move, never for the platform you land on. Git-push deployments, per-PR preview environments, environment lifecycle, RBAC and Kubernetes day-2 operations are out of scope, and that gap is where PaaS exits stall.
• Land on a platform that runs inside your own cloud account so migrated spend, Savings Plans, committed use discounts and Azure reservations stay in your name.

Teams keep asking me which hyperscaler will pay for their move off a managed PaaS. Two of the three programs they are comparing do not pay for anything. The AWS Migration Acceleration Program is a funding program; Google Cloud Migration Center and Azure Migrate are free assessment consoles, and their clouds fund migrations through separate programs you have to ask for.

Comparison verified November 2026 against each vendor's own published pages. Program names in this space change often, and two of them changed in the last eighteen months.

Which of these three programs actually pays you to leave a managed PaaS?

The AWS Migration Acceleration Program (MAP) is the only one of the three named programs that funds a migration. Google Cloud Migration Center and Azure Migrate are free assessment tools, and the funding on those clouds lives in Google RaMP and Azure Accelerate (formerly Azure Migrate and Modernize). For a PaaS exit, MAP is the strongest vehicle on AWS, Google RaMP publishes the clearest funding formula, and Azure Accelerate is the most application-aware path on Azure.

The tools themselves cost nothing. Google states you can use Migration Center "to run a cost estimate and to create an assessment at no cost" (Google Cloud). Microsoft says Azure Migrate tools "are available at no additional charge," with server migration free for the first 180 days per machine and $25 per month per replicated instance after that (Azure Migrate pricing).

Credits pay for the move, never for the platform you land on.

The decision rule: pick AWS MAP if the migrated workloads carry material annual AWS spend, pick Azure Accelerate if you already hold an Enterprise Agreement or MACC, and run Google Cloud Migration Center first if the cloud is not chosen yet. This ranks programs for a PaaS exit, not clouds. A VMware or datacenter exit reorders the list completely.

How did we score these programs for a PaaS exit?

We scored each program on six criteria: whether it pays cash or credits instead of only producing a report, whether it requires a partner, whether discovery understands application platforms, what spend commitment it demands, how long until the first dollar lands, and what you still own the day after cutover.

1. Real funding versus free tooling. Money on the table, or only an assessment console.
2. Partner dependency. What you can claim self-serve versus what routes through a systems integrator or account team.
3. PaaS awareness. Whether discovery handles Heroku dynos, Render services, Vercel projects, Fly machines or Platform.sh containers, or only servers, VMware and databases.
4. Commitment required. Minimum migrated spend, multi-year committed spend, MACC drawdown, or none.
5. Time to first dollar. How much assessment and mobilization happens before funding lands.
6. What you still own after cutover. Pipelines, environment lifecycle, preview environments, RBAC, cluster upgrades, cost guardrails.

The structural mismatch is obvious once you write it down. A PaaS footprint is tiny in server count and huge in developer-experience value, and every one of these programs measures success in migrated servers and workloads.

On method: I scored from the vendors' own published program pages as of November 2026, not from private partner agreements. Where a vendor does not publish a percentage, I describe the mechanism and leave the number out.

What exactly is the AWS Migration Acceleration Program, and will it pay for leaving a PaaS?

The AWS Migration Acceleration Program (MAP) is a three-phase program, "Assess, Mobilize, and Migrate & Modernize," that combines AWS methodology, partner expertise and "financial investments" to "offset initial migration costs" (AWS MAP). The AWS Migration Acceleration Program will fund a PaaS exit, but you will engage through a partner or AWS, and the incentive tracks the AWS spend your migrated workloads represent.

The phases, per AWS:

• Assess: find capability gaps across the six dimensions of the AWS Cloud Adoption Framework and "build a realistic TCO model."
• Mobilize: "close the gaps identified in the assessment phase and build your operational foundation."
• Migrate & Modernize: execute with AWS migration services, AWS Professional Services and AWS Migration Competency Partners.

AWS does not publish MAP credit amounts or percentages on the program page, and I will not invent one. Your account team or partner sizes the investment against the projected spend.

The PaaS catch is discovery. AWS Application Discovery Service collects data about "on-premises servers and databases," through a vCenter collector or agents on VMs and physical servers (AWS docs). Both it and AWS Migration Hub are also closed to new customers, with Migration Hub closed "as of November 7, 2025" and AWS Transform named as the replacement (AWS docs). Your PaaS inventory gets hand-built from billing exports and app manifests either way.

A realistic MAP-funded PaaS exit looks like this: an EKS or ECS landing zone, RDS or Aurora replacing PaaS add-on databases, S3 and CloudFront replacing static hosting, then a platform layer on top to give developers back their deploy button. If the migrated workloads do not represent material annual AWS spend, the AWS Migration Acceleration Program is not worth the paperwork or the partner SOW.

Is Google Cloud Migration Center a funding program or just a free assessment tool?

Google Cloud Migration Center is a free assessment and TCO tool, not a funding program. Google Cloud Migration Center discovers and inventories servers and databases, maps dependencies, runs fit assessments and generates TCO reports; the money on Google Cloud comes from the separate Rapid Migration and Modernization Program (RaMP).

Google lists its discovery scope as "servers, Microsoft SQL Server, MySQL, and PostgreSQL databases," built "by automatically scanning your on-premises environment" or by manual upload (Google Cloud). Google Cloud Migration Center will not find Heroku add-ons, Render services, Vercel projects or Fly machines. That inventory comes from your PaaS billing export and your repositories, which you can upload manually.

Where it wins: an exportable TCO model comparing your current PaaS bill against a GKE Autopilot or Cloud Run landing zone, produced before you commit to any cloud. Pair it with real discount math. Compute Engine hardware commitments cut up to 55% for most machine series and up to 70% for memory-optimized ones (Google Cloud CUDs).

Google RaMP is the most transparent funding program of the three. Its phases are Assess, Plan, Migrate and Innovate, and the RaMP assessment "formally qualifies your project for RaMP funding and incentives." Service funds, which offset the cost of a partner or Google Professional Services, start at "20% of the projected Annual Recurring Revenue (ARR), capped at $2M per workload," and Google Cloud credits arrive quarterly "based on the incremental growth of your tagged workloads" (Google RaMP). Untagged workloads earn nothing.

Pick Google Cloud if your team already leans toward GKE Autopilot or Cloud Run, or if your CFO needs a cost artifact before the cloud decision is locked.

Does Azure Migrate cover modern app platforms, or only VMs?

Azure Migrate is a free discovery, assessment and migration toolset that reaches further into application-level assessment than its AWS and Google equivalents, but it still only sees workloads you run yourself. Azure Migrate assesses servers, SQL Server, web apps and virtual desktops, and migrates web apps to Azure App Service and Azure Kubernetes Service (Microsoft Learn).

Microsoft calls Azure Migrate a "free service" for inventory, assessment against IaaS and PaaS targets, planning and migration, with partner tools possibly charging extra. Discovery runs through the Azure Migrate appliance, "a virtual appliance that can be deployed on a server in your datacenter." That is where the application awareness stops: Azure Migrate assesses servers and web apps you already host, not a third-party PaaS tenancy where you have no appliance to install.

The funding lives elsewhere. In July 2025 Microsoft folded Azure Migrate and Modernize, Azure Innovate and Cloud Accelerate Factory into one offering, Azure Accelerate (Microsoft Azure Blog), which the program page now calls Frontier Accelerate for Azure. It offers "Azure credits and partner engagement funding," "a funded migration and modernization assessment," and zero-cost deployment help from Microsoft experts through Cloud Accelerate Factory, including moving containerized workloads to AKS or Azure Container Apps (Frontier Accelerate for Azure). You get in through your Microsoft account representative or a specialized Azure partner.

The MACC angle can beat raw credits on net economics. A Microsoft Azure Consumption Commitment is a contract to spend a set amount on Azure, and "eligible Microsoft Marketplace purchases automatically count toward fulfilling this commitment" when bought through the Azure portal (Microsoft Learn). Pick Azure if you are Microsoft-heavy, already hold an EA or MACC, or carry .NET and SQL Server weight.

How do AWS MAP, Google RaMP and Azure Accelerate compare on money, partner lock-in and time to value?

The AWS Migration Acceleration Program, Google RaMP and Azure Accelerate converge far more than their marketing suggests. All three gate real money behind a partner or account team, all three tie incentives to migrated or committed spend, all three measure success in migrated workloads, and none of them fund the platform layer you need the day after cutover.

Only Microsoft publishes a hard number for one track: Frontier Accelerate for Databases offers "delivery funding and Azure credits, both offered at 50% of year-one usage" (Microsoft). Everything else on the AWS side is negotiated.

These are channel incentives. Model the partner statement of work as a real cost and compare it with the credit value before anyone signs. Watch the commitment trap too: credits tied to one-to-three-year committed spend can outlast the architecture you are migrating onto.

The dominant cost of a PaaS exit is engineering time, not infrastructure. The Stack Overflow 2025 Developer Survey puts the global median DevOps engineer salary at $87,011 and cloud infrastructure engineer at $103,113 (Stack Overflow), and Flexera's 2026 State of the Cloud report found wasted cloud spend rising to 29%, the first increase in five years (Flexera). Neither cost shows up in a credit memo.

What do migration credits not cover when you leave a managed PaaS?

Migration credits stop at the landing zone. The moment your workloads run in the new cloud, the funding ends and you inherit everything the PaaS did for you.

• Git-push deployments with build, release and rollback.
• Per-pull-request preview environments.
• Environment lifecycle and cleanup, so idle staging stops billing.
• Per-environment RBAC for who can deploy where.
• Managed databases wired to apps with credentials injected.
• Sane production defaults: TLS, health checks, autoscaling, logs.

This is where PaaS exits stall. The cluster is up, the credits are spent, and developers who used to ship by git push now file tickets. The CNCF's 2025 survey found "cultural changes with the development team" is now the top challenge to cloud native adoption, cited by 47%, ahead of lack of training at 36%, even as 82% of container users run Kubernetes in production (CNCF).

The economics favor staying in your own account. Workloads there keep the migration funding plus AWS Compute Savings Plans at up to 66% off (AWS), Google committed use discounts at up to 55% or 70% (Google Cloud) and Azure reservations at up to 72% off pay-as-you-go (Azure). A vendor-hosted PaaS bills you on its own invoice, so none of that applies.

Building it yourself is a legitimate choice, and most organizations make some version of it: DORA reports 90% of organizations use an internal developer platform and 76% have dedicated platform teams (DORA). The question is whether you staff that team before the credits run out.

Where does Qovery fit, and when is it the wrong choice?

Qovery is an internal developer platform that runs inside your own AWS, GCP, Azure or Scaleway account, or on your existing Kubernetes cluster, so it restores the PaaS developer experience while migrated spend still counts toward your MAP, RaMP or Azure commitment. Qovery is the wrong choice if you want a vendor to host your infrastructure, or if you already run a mature internal platform with a staffed team.

What Qovery does on top of your account:

• Git-push deployments.
• Preview and ephemeral environments per pull request.
• Environment auto-stop for non-production.
• Managed cluster upgrades.
• Per-environment RBAC.
• Databases backed by managed cloud services such as RDS or Cloud SQL.

Running in your own account matters for funding. The cloud bill stays in your name, so migration credits, Savings Plans, committed use discounts and reservations apply to every workload Qovery deploys. Because Qovery is cloud-agnostic, the funding program you qualify for can pick the cloud, instead of your tooling picking it for you.

You get real Kubernetes in your account without anyone on your team maintaining it manifest by manifest, and you can ship without a dedicated DevOps hire.

Honest limits. Qovery is not a discovery or TCO tool, so run Google Cloud Migration Center or Azure Migrate for the assessment, then land on Qovery. For a full VMware or datacenter lift-and-shift, take AWS MAP or Azure Accelerate with a partner and Qovery is irrelevant. If you want no cloud account of your own at all, Render or Fly.io is the better answer.

How do I run a PaaS exit with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once and your coding agent can set up the landing zone, deploy the first service into your own cloud account and configure per-PR preview environments, without you hand-writing Kubernetes manifests.

Install globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI). This installs the skills that deploy: qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform.

curl -fsSL https://skill.qovery.com/install.sh | bash

Or keep the skills inside one repository:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the MCP Server to Claude Code. It uses OAuth, is read-only by default, lets the agent inspect what already runs, and asks you to approve the login in your browser:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change things (this also requires write access enabled in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Then ask in plain language: "deploy this app to my AWS account with Qovery" or "set up a preview environment per pull request." Full setup is in the AI agent quickstart and the Claude Code integration page.