Can AWS Credits Pay for Your Heroku Migration? What Activate, MAP, and Partner Credits Actually Cover

Key Points:

• Credits cover the AWS side, nothing else. AWS credits can absorb the AWS-consumption part of a Heroku exit - duplicate environments, database replication, data transfer, and the first months of production - but they never pay your Heroku invoices, third-party SaaS, consultancy fees, or engineering time.
• Activate is the startup path. A self-service tier is open to most early-stage companies, and larger tiered packages generally need a referral from an accredited Activate Provider (a VC, accelerator, or AWS Partner). Amounts and eligibility are set by AWS and change, so verify on the official Activate page before you budget.
• MAP is the bigger pool for a migration. It runs in three phases - assess, mobilize, migrate and modernize - funding is tied to committed scope, and the request is driven by an AWS Partner on your behalf rather than filed by you.
• The parallel-run window is the main creditable cost. You pay AWS and Heroku at the same time for roughly four to eight weeks. Budget credits to absorb that overlap, and expect NAT Gateway and data transfer to be the two AWS charges that surprise you.
• Keep the AWS account in your own name. With BYOC platforms like Qovery, your Activate and MAP credits, Savings Plans, and negotiated discounts apply directly. Move to a PaaS that resells capacity and you forfeit all of them.

Most teams plan a Heroku exit as an engineering project. The thing that actually stalls it is money: for roughly four to eight weeks you pay Heroku and AWS at the same time, and that double-bill is what quietly drains the budget before cutover.

Here is the short version. AWS promotional credits can absorb the AWS-consumption side of that overlap, but they never touch your Heroku invoices, your third-party add-ons, or your engineering time. So the real question is not "can credits pay for the migration" - it is "which credits can I actually get, what does a migration consume, and how do I sequence the cutover so the switching cost lands on credits instead of my P&L?" That is what this piece is about.

Can AWS credits actually pay for a migration off Heroku?

Yes, partly. AWS promotional credits can absorb most of the AWS-consumption cost of a Heroku migration, including the parallel-run window where both platforms are live, but they apply only to eligible AWS usage and never to your Heroku invoices, third-party add-ons, taxes, or engineering hours.

The cleanest way to think about it is three cost buckets. Only the first is creditable.

Credits are promotional balances AWS applies to eligible usage on your bill. They do not apply to AWS Marketplace purchases, AWS Professional Services, Training, Certification, or taxes, and they cannot pay the upfront fee on a Savings Plan or Reserved Instance (AWS Promotional Credit terms). They do nothing for a bill that is not AWS.

The parallel-run window is where credits earn their keep. In a zero-downtime migration you cannot flip a switch; you stand up AWS, replicate data, shift traffic gradually, and keep Heroku warm as a rollback. For that stretch you pay both platforms. The length of that overlap is the single variable you control, and it is exactly the shape credits are good at absorbing: a one-to-three month spike on top of a steady-state bill.

Set the expectation honestly with your finance team. Credits shift when you pay and shrink the switching cost. They do not make the migration free, and they do not fund the platform work that replaces Heroku's control plane.

How does AWS Activate work, and who is eligible?

AWS Activate is AWS's startup program that grants promotional credits plus AWS support and training credits. There is a self-service tier open to most early-stage startups with a valid company profile and no prior Activate credits, and larger packages that generally require a referral from an accredited Activate Provider such as a VC, accelerator, or AWS Partner.

AWS advertises up to $200,000 in Activate credits for eligible startups, with additional credits possible for AI startups ready to grow (AWS Activate). Treat that as a ceiling, not an entitlement. Activate amounts, tiers, and terms change often, so the figure you budget against should be the one on the live Activate page the week you apply, not a number you read in a blog post (including this one).

The signals AWS weighs are company age, funding stage, whether you have received Activate credits before, whether you are already a large AWS spender, and whether the account is new. The referral path matters: going through a VC, accelerator, or AWS Partner that is an accredited Activate Provider usually yields a larger package than self-service, because the provider vouches for you with an organization ID.

Two details decide whether Activate credits help your migration at all. First, credits carry an expiry date, and unredeemed credit is forfeited when it lapses (AWS Promotional Credit terms) - so credit approval and migration timing have to be sequenced together, not run in parallel by accident. Second, Activate also includes AWS Business Support credits and training, both of which cut real risk during a cutover when you are standing up unfamiliar services.

A practical checklist before you apply: incorporate first, apply with a company-domain email on a clean AWS account, and get the expiry date confirmed in writing before you provision anything you intend credits to cover.

What other AWS and partner credits can fund a migration?

Beyond Activate, the funding that actually pays for migrations comes through AWS Partners. The two main vehicles are the AWS Migration Acceleration Program (MAP) and partner-funded assessments or proofs of concept, and both are driven by a partner on your behalf after an assessment rather than filed by you directly.

MAP runs in three phases - Assess, Mobilize, and Migrate and Modernize - and AWS delivers it through its Migration Competency Partners, bundling tools, expertise, and financial investment (AWS Migration Acceleration Program). The funding scales with committed migration scope, which is why MAP fits a mid-size or larger estate - dozens of services, compliance requirements, a real discovery phase - rather than a three-dyno side project. If your whole footprint is a handful of dynos and one database, MAP is probably not your path; Activate plus disciplined sequencing is.

Partner-led options are worth a call even below MAP scale. AWS Partner Network consultancies - for example nClouds, and firms such as Shadhin Lab that market Heroku-to-AWS work - can run the assessment and package the funding request for you. Once your workload shape stabilizes after cutover, the after-credits cost levers are AWS Marketplace private offers, Enterprise Discount Programs for larger committed spend, and Savings Plans.

Savings Plans deserve a flag here: Compute Savings Plans cut EC2, Fargate, and Lambda costs by up to 66%, and EC2 Instance Savings Plans by up to 72% versus On-Demand (AWS Savings Plans). That is a large lever, but it is a lever for after the migration, once you know your real workload shape.

One rule underpins all of this. Keep the AWS account in your own name. Credits, Savings Plans, and negotiated discounts attach to the account that holds the spend. If a vendor resells you AWS capacity under their account, you usually forfeit both your credits and your ability to commit. And a pitfall worth repeating: credits requested after you have already provisioned and burned the spend are rarely retroactive.

How many credits does a Heroku-to-AWS migration realistically consume?

For a typical small-to-mid Heroku app, creditable AWS spend during the migration is dominated by three things: the duplicate production environment running in parallel, database replication plus data egress, and the managed services you must stand up before Heroku can be switched off - RDS, EKS or ECS, a load balancer, and NAT gateways.

Let me make it concrete with a worked example. Treat these as labelled assumptions, not a benchmark - swap in your own numbers.

Assumptions: 3 Standard-2X web dynos, 2 Standard-2X worker dynos, 1 Heroku Postgres Standard-0 plan, 1 Heroku Key-Value Store (Redis) Premium 1 add-on, roughly 200 GB egress per month.

On Heroku list pricing that steady-state bill is: web dynos 3 x $50, worker dynos 2 x $50, Postgres Standard-0 $50, and the Premium 1 Key-Value Store $30 (Heroku pricing). That is about $330 a month, and it keeps running every day Heroku is live.

Now the AWS side. Before you run a single container, the fixed platform floor is real: an EKS control plane is $0.10 per cluster per hour, about $73 a month (Amazon EKS pricing), and one NAT Gateway is $0.045 per hour plus $0.045 per GB processed, roughly $33 a month before processing (Amazon VPC pricing). A multi-AZ setup usually means two or three NAT gateways, so that floor multiplies. On top of that floor you add compute, RDS, ElastiCache, an Application Load Balancer, CloudWatch, S3, and AWS DMS if you replicate with it.

NAT Gateway and data transfer are the two charges teams leaving Heroku consistently underestimate. AWS gives you 100 GB of data transfer out to the internet free each month aggregated across services, with tiered per-GB charges beyond that (Amazon EC2 pricing); 200 GB of egress plus the per-GB NAT processing adds up faster than the dyno math suggests.

Here is the citable asset - a like-for-like component map.

The number that matters is the overlap multiplier. During the parallel run you carry the AWS stack and the roughly $330-a-month Heroku bill at the same time, so your migration-period cash burn is close to double your steady state for four to eight weeks. Credits cover the AWS half. The Heroku half is cash, which is exactly why you timebox the overlap.

Budget the non-creditable costs separately: Heroku invoices during the overlap, third-party add-ons you have to replace, DNS and observability tooling, and engineering time. None of it touches a credit balance.

How do you sequence a zero-downtime Heroku migration so credits absorb the switching cost?

Get credits approved and their expiry confirmed before you provision anything, then run the migration in strict order - infrastructure, continuous data replication, gradual traffic shift - so the expensive double-run window falls entirely inside the credit validity period.

• Step 0 - Fund first. Apply for Activate or line up a MAP/partner engagement, confirm the expiry window in writing, and only then open the AWS account you will migrate into. Provisioning before the credits land can waste weeks of the validity window.
• Step 1 - Stand up the target. Build the VPC, cluster, managed database, and secrets, and reproduce the app build. I will not re-explain buildpacks and Dockerfiles here; our Heroku-to-AWS migration guide covers the mechanics.
• Step 2 - Replicate continuously. Set up ongoing replication from Heroku Postgres so cutover is a promotion, not a dump-and-restore. Heroku Postgres supports followers and continuous protection via WAL (Heroku Dev Center), and AWS DMS supports change data capture for continuous replication from PostgreSQL (AWS DMS).
• Step 3 - Shift traffic gradually. Use Route 53 weighted routing to move a small share of traffic first and raise it as confidence grows (Amazon Route 53). Keep Heroku warm as rollback until replication lag is zero and you hold a verified backup.
• Step 4 - Decommission, then commit. Turn Heroku off, observe two to four weeks of real workload shape, and only then buy Savings Plans. Committing before you know the shape locks in the wrong size.

The discipline is a hard end date on the overlap with a named owner. Every extra week of parallel run burns credits you would rather spend on steady-state production. For a single-app estate that calendar is realistically four to eight weeks; for a multi-service estate with compliance gates it stretches, and that is precisely where a partner-led MAP engagement with a formal assessment pays for itself.

Which migration services and platforms handle a no-downtime Heroku-to-AWS move?

There are four genuinely different answers, and the right one depends on your estate size and who you want owning the platform afterward: an AWS Partner or AWS Professional Services for a bespoke, MAP-funded project; a PaaS that replaces Heroku with its own control plane; an internal developer platform like Qovery that deploys into your own cloud account so credits and discounts stay with you; or staying on Heroku.

A few honest calls. For a 200-service estate with audit requirements, a partner-led MAP engagement with AWS Professional Services is the better answer - say yes to the assessment. For a hobby app, staying on Heroku is fine; Fir is now generally available and, interestingly, runs on AWS EKS under the hood (Heroku generations). Render and similar managed PaaS are the simplest operationally, but the cloud bill sits with the vendor, so AWS Activate and MAP credits do not apply.

Where Qovery fits is the bring-your-own-cloud (BYOC) case. Qovery gives you git-push deployments, a preview environment per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services - running inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster. Because the account and the bill stay in your name, your Activate and MAP credits, your Savings Plans, and your negotiated discounts apply directly to what Qovery deploys. And because it is not AWS-only, the AWS decision you make today does not lock you in tomorrow.

What do AWS credits not cover, and where do teams get burned?

Credits stop at eligible AWS usage. They do not pay your Heroku bill during the overlap, third-party SaaS replacements, AWS Marketplace purchases, AWS Professional Services, taxes, or your engineering time - and unused credits expire, which makes a slipped timeline the most common way teams lose the funding.

The exclusion list is worth reading from the source before you budget. Credits cannot be applied to AWS Marketplace, AWS Professional Services, Training or Certification, Route 53 domain registration, or several other services, nor to the upfront fee on Savings Plans and Reserved Instances, nor to sales, use, or similar transaction-based taxes (AWS Promotional Credit terms).

Timeline slip is failure mode number one. Credits carry an expiry date, and if the parallel run drags, the funding advantage evaporates before cutover. The fix is governance, not optimism: track credit burn monthly in AWS Billing so you know by week four whether the overlap is on budget.

Then there is the post-credit cliff. Model your month-13 AWS bill before you migrate, not after, with Savings Plans, right-sizing, and auto-stopped non-production environments already in the model. This matters because waste is the default state of cloud: Flexera's annual survey puts self-estimated wasted cloud spend at about 27% (Flexera 2025 State of the Cloud Report), and 84% of organizations say managing cloud spend is a challenge (Flexera). Credits paper over that for a while, then stop.

The last cost credits never cover is the day-2 platform: rebuilding buildpacks as containers, review apps, add-on databases, on-call, and cluster upgrades. That is the real price of leaving Heroku, and it is the part a platform either absorbs for you or hands you to staff. Keep the steady-state bill honest with environment auto-stop for non-production, right-sized clusters, per-environment cost visibility, and a quarterly right-sizing review.