How Much Does It Cost to Migrate From Heroku to AWS in 2026?

Heroku was the default platform for startups for over a decade. You could push a Rails app, a Node API, or a Django project and have it running in production within minutes. No Dockerfiles, no Terraform, no VPC configurations. It was magic, and teams paid a premium for that simplicity.

Then Salesforce killed the free tier in November 2022. Overnight, hobby projects and early-stage startups that relied on free dynos had to start paying or leave. But the free tier removal was just the surface. The deeper problem is that Heroku's pricing has not kept pace with the market. A single Standard-2X dyno with 1 GB of RAM costs $50/month. A Performance-M dyno with 2.5 GB of RAM runs $250/month. Heroku Postgres Standard 0, the cheapest production-grade database, starts at $50/month with a 64 GB storage limit. Add Redis Premium 0 at $15/month, a couple of add-ons for logging and monitoring, and a basic two-dyno setup quickly hits $400 to $600/month.

For comparison, running the same workload on AWS with a t3.medium EC2 instance (2 vCPU, 4 GB RAM), an RDS db.t3.micro Postgres instance, and an ElastiCache t3.micro Redis node costs roughly $120 to $180/month in us-east-1. That is a 60% to 70% reduction in monthly spend for the same compute and storage.

Beyond pricing, teams hit hard limits on Heroku that AWS simply does not have. Heroku dynos restart every 24 hours. WebSocket connections get terminated after 55 seconds of inactivity. You cannot run background threads reliably. There is no way to attach a GPU for ML inference. Deployment slugs are capped at 500 MB. If your application has outgrown these constraints, you are not just saving money by leaving. You are removing ceilings on what your product can do.

The third driver is compliance. SOC 2, HIPAA, and FedRAMP auditors want to see that you control your infrastructure. Heroku's shared-tenancy model and limited audit logging make compliance significantly harder than it needs to be. AWS gives you dedicated VPCs, granular IAM policies, CloudTrail audit logs, and encryption options that satisfy even the most demanding compliance frameworks.

Before you can estimate costs, you need a complete inventory of what you are running on Heroku. Most teams undercount. They think about their web dynos and database but forget about the worker processes, scheduled tasks, add-ons, and CI/CD pipeline that hold everything together. Here is the full list of components you need to account for.

Web dynos to ECS Fargate or EKS. Your Heroku web processes need to move to a container orchestration service. For most teams, ECS Fargate is the right choice. It is serverless, so you do not manage EC2 instances, and it maps conceptually to Heroku's dyno model. You define a task with CPU and memory limits, set a desired count, and Fargate handles placement and scaling. If you are running a Kubernetes-heavy stack or need fine-grained control over networking and service mesh, EKS is the alternative, but it adds significant operational complexity and cost. A managed EKS cluster alone costs $73/month before you add any worker nodes.

Heroku Postgres to RDS or Aurora. This is usually the most nerve-wracking part of the migration. Your database holds your business data, and any corruption or data loss is catastrophic. AWS RDS for PostgreSQL is the direct replacement. It supports the same Postgres versions, extensions, and connection pooling (via RDS Proxy) that you are used to on Heroku. Aurora PostgreSQL is the premium option, offering 3x throughput and automatic storage scaling, but it costs roughly 20% more than standard RDS for equivalent instance sizes.

Heroku Redis to ElastiCache. If you are using Heroku Redis for caching, session storage, or Sidekiq/BullMQ job queues, ElastiCache for Redis is the direct replacement. The migration is straightforward because Redis data is usually ephemeral. You provision the ElastiCache cluster, update your connection strings, and redeploy. The main decision is whether you need cluster mode (for sharding across multiple nodes) or a single-node setup.

Worker dynos to ECS tasks or Lambda. Heroku worker dynos that run background jobs (Sidekiq, Celery, BullMQ) map to ECS tasks running the same container image as your web service but with a different entrypoint command. If your workers are processing short-lived tasks under 15 minutes, AWS Lambda is a cost-effective alternative since you only pay per invocation. For long-running workers or those that need persistent connections, stick with ECS.

Heroku Scheduler to EventBridge or CloudWatch Events. If you are using Heroku Scheduler for cron jobs, AWS EventBridge Scheduler is the replacement. It supports cron expressions, one-time schedules, and can trigger ECS tasks, Lambda functions, or Step Functions. Unlike Heroku Scheduler, which is notoriously unreliable about exact timing, EventBridge runs tasks within one second of the scheduled time.

Add-ons to AWS-native services. This is where migrations get complicated. Every Heroku add-on needs a replacement. Papertrail becomes CloudWatch Logs or a third-party like Datadog. New Relic or Scout APM becomes CloudWatch APM, X-Ray, or you keep the same vendor with a direct integration. SendGrid stays SendGrid (it works fine outside Heroku) or becomes SES. Cloudinary, Algolia, and other SaaS add-ons usually just need updated environment variables since they were never Heroku-specific to begin with.

CI/CD pipeline. Heroku's git-push deployment model is one of its best features, and you will miss it. On AWS, you need to build a deployment pipeline from scratch. The typical stack is GitHub Actions (or GitLab CI) for building and testing, ECR for storing container images, and ECS service updates or CodeDeploy for rolling deployments. Setting up blue-green deployments with health checks and automatic rollback takes real engineering time.

After migrating dozens of applications from Heroku to AWS, we have found that costs fall into three predictable tiers based on application complexity. These numbers include engineering labor, infrastructure setup, testing, and a two-week post-migration support period. They do not include ongoing AWS monthly costs, which we cover in the next section.

Tier 1: Simple Application ($8,000 to $20,000)

A simple application is a single web service with a Postgres database, possibly Redis, and minimal background processing. Think a Rails or Express API with a React frontend, fewer than 10 database tables, and under 1,000 daily active users. There are no complex integrations, no multi-tenant data isolation requirements, and no strict compliance mandates.

At this tier, the migration typically takes 2 to 4 weeks with a single senior engineer. The work includes containerizing the application with Docker, provisioning AWS infrastructure with Terraform or CDK, setting up ECS Fargate, migrating the database using pg_dump/pg_restore, configuring an ALB with SSL, setting up CloudWatch logging, and building a basic CI/CD pipeline with GitHub Actions. Most of the cost is engineering labor at $150 to $200/hour.

Tier 2: Medium Complexity ($20,000 to $50,000)

Medium complexity means multiple services (a web app, an API, one or two worker processes), a larger Postgres database (50 GB to 500 GB), Redis with persistent data, several Heroku add-ons, and some form of scheduled task processing. The application might serve 5,000 to 50,000 daily active users and have staging and production environments that both need to be migrated.

This tier takes 4 to 8 weeks with a team of two: a senior DevOps/infrastructure engineer and a backend developer who knows the application code. The additional complexity comes from database migration with minimal downtime (using AWS DMS or logical replication for databases over 100 GB), setting up VPC networking with proper security groups, configuring auto-scaling policies, replacing Heroku add-ons with AWS-native services, and ensuring environment parity between staging and production. You also need a more robust CI/CD pipeline with automated testing, staging deployments, and production approval gates.

Tier 3: Complex Multi-Service ($50,000 to $120,000)

Complex migrations involve a microservices architecture with 5+ services, large databases (500 GB+), strict uptime requirements (99.9%+), compliance needs (SOC 2, HIPAA), and deeply embedded Heroku-specific patterns like Heroku Connect for Salesforce sync or Private Spaces for network isolation. These applications typically serve 100,000+ daily active users and generate significant revenue, meaning any migration downtime has a direct financial cost.

This tier takes 8 to 16 weeks with a team of three to four engineers. The work includes designing a multi-account AWS organization structure, implementing Infrastructure as Code for the entire stack, setting up service mesh networking (often with AWS App Mesh or a service discovery pattern), orchestrating a zero-downtime database migration with replication and cutover planning, implementing comprehensive monitoring and alerting with CloudWatch, PagerDuty, and runbooks, and conducting load testing to validate performance parity. The higher cost is justified by the risk. A botched migration of a revenue-generating application can cost far more than the migration itself.

The migration is a one-time cost. The monthly savings are what make it worthwhile. Here is how AWS monthly costs compare to Heroku for three common application profiles, based on us-east-1 pricing as of early 2026.

Small application (equivalent to 2 Standard-1X dynos + Postgres Standard 0 + Redis Premium 0):

• Heroku: $200/month (2 x $25 dynos + $50 Postgres + $15 Redis + ~$60 add-ons)
• AWS: $80 to $130/month (ECS Fargate 0.5 vCPU/1 GB x 2 tasks: ~$30, RDS db.t3.micro: ~$15, ElastiCache t3.micro: ~$13, ALB: ~$18, CloudWatch: ~$5, data transfer: ~$5)
• Monthly savings: $70 to $120

Medium application (equivalent to 4 Standard-2X dynos + 2 worker dynos + Postgres Standard 2 + Redis Premium 3):

• Heroku: $900 to $1,200/month (4 x $50 web dynos + 2 x $50 worker dynos + $200 Postgres + $100 Redis + ~$150 add-ons)
• AWS: $350 to $500/month (ECS Fargate 1 vCPU/2 GB x 6 tasks: ~$180, RDS db.t3.medium Multi-AZ: ~$90, ElastiCache t3.small: ~$35, ALB: ~$25, CloudWatch + X-Ray: ~$30, S3 + data transfer: ~$20)
• Monthly savings: $500 to $750

Large application (equivalent to 8 Performance-M dynos + 4 worker dynos + Postgres Premium 0 + Redis Premium 5):

• Heroku: $3,500 to $5,000/month (8 x $250 web dynos + 4 x $250 worker dynos + $400 Postgres + $200 Redis + ~$300 add-ons)
• AWS: $1,200 to $1,800/month (ECS Fargate 2 vCPU/4 GB x 12 tasks: ~$600, RDS db.r6g.large Multi-AZ: ~$300, ElastiCache r6g.large: ~$180, ALB + WAF: ~$60, CloudWatch + X-Ray + Datadog: ~$100, S3 + CloudFront + data transfer: ~$80)
• Monthly savings: $2,000 to $3,200

For more strategies on reducing your cloud bill after migration, check out our guide on how to cut your cloud spending without sacrificing performance.

The pattern is clear: the more you spend on Heroku, the larger your savings on AWS. For small apps, the monthly savings are modest and it might take 12 to 18 months to recoup the migration cost. For large apps spending $3,000+ per month on Heroku, the migration pays for itself in 3 to 6 months. That calculus should drive your urgency.

One important caveat: these AWS costs assume you have someone who knows how to optimize the infrastructure. Naive AWS deployments with oversized instances, uncompressed CloudWatch logs, and no Reserved Instance commitments can actually cost more than Heroku. The savings require active management, which is either your team's time or a managed services contract.

A well-executed Heroku to AWS migration follows a predictable sequence. Rushing it leads to downtime, data issues, and a frantic first week on AWS where your team is firefighting instead of building features. Here is the process we follow and recommend.

Week 1 to 2: Discovery and infrastructure design. Audit every Heroku resource: dynos, databases, add-ons, environment variables, custom domains, SSL certificates, and scheduled tasks. Document the current architecture, traffic patterns, and performance baselines. Design the target AWS architecture, choosing between ECS and EKS, selecting instance types, planning VPC layout, and mapping every Heroku add-on to an AWS service or third-party replacement. Write the Terraform or CDK code for the infrastructure. This phase is entirely non-disruptive to your production Heroku environment.

Week 3 to 4: Containerization and CI/CD. Write Dockerfiles for every service. This is usually straightforward for Node, Python, and Ruby applications, but it can surface hidden dependencies on Heroku's build system (like specific buildpack behaviors, asset compilation steps, or system-level packages). Build the CI/CD pipeline in GitHub Actions or GitLab CI. Test the full build, test, push, and deploy cycle against a staging environment on AWS. If you have not read our overview of planning a cloud provider migration, it covers the general process in more detail.

Week 5 to 6: Database migration and testing. This is the highest-risk phase. For databases under 50 GB, a maintenance-window approach works: put the Heroku app in maintenance mode, run pg_dump, transfer the dump to S3, restore into RDS, verify row counts and data integrity, update connection strings, and bring the AWS version online. Total downtime is 30 minutes to 2 hours depending on database size. For databases over 50 GB, use AWS Database Migration Service (DMS) for continuous replication. DMS copies the initial dataset while the Heroku app continues running, then replicates changes in near-real-time. At cutover, you stop writes to Heroku, let DMS catch up (usually under 60 seconds of lag), switch DNS, and start serving from AWS. Downtime drops to under 5 minutes.

Week 7 to 8: Cutover and stabilization. Run the application on AWS in shadow mode alongside Heroku if possible, routing a percentage of traffic to AWS via weighted DNS (Route 53 weighted routing policies). Monitor error rates, response times, and database performance. When you are confident, flip DNS fully to AWS. Keep the Heroku app running in read-only mode for one to two weeks as a fallback. After the stabilization period, decommission Heroku resources and cancel add-on subscriptions.

For complex migrations (Tier 3), add 4 to 8 weeks for the additional work around multi-service orchestration, compliance validation, load testing, and runbook development. The timeline scales linearly with the number of services and the strictness of your uptime requirements.

Every migration has surprises. But some surprises show up so consistently that they should be planned for, not discovered during a 2 AM incident. Here are the ones that catch teams most often.

Heroku buildpack magic you did not know existed. Heroku buildpacks do a lot of implicit work: installing system dependencies, compiling native extensions, setting memory limits, tuning garbage collection, configuring connection pooling. When you move to Docker, all of that becomes explicit. The most common issue is native gem or npm package compilation. A Ruby app that installs nokogiri effortlessly on Heroku might fail to build in Docker because the Alpine base image is missing libxml2 headers. Budget an extra 1 to 2 days per service for Dockerfile debugging.

Connection string formats and SSL requirements. Heroku Postgres provides a DATABASE_URL that includes SSL parameters. RDS uses a different SSL certificate chain and different connection parameters. ORMs and database drivers handle this inconsistently. ActiveRecord, Sequelize, Prisma, and SQLAlchemy all have slightly different ways of configuring SSL connections to RDS. Test database connectivity from your application container to RDS before you start the data migration, not after.

Forgetting about Heroku's built-in routing. Heroku's HTTP router handles SSL termination, request buffering, WebSocket upgrades, and idle connection timeouts automatically. On AWS, you configure all of this yourself on the Application Load Balancer. The most common mistake is not setting the ALB idle timeout to match your application's longest request. Heroku defaults to 30 seconds. ALB defaults to 60 seconds. If your app has long-running requests (file uploads, report generation, SSE streams), you need to tune this explicitly or users will see 504 errors.

Logging and monitoring gaps. On Heroku, logs go to stdout and appear in the Heroku CLI or a logging add-on. On AWS, you need to configure CloudWatch log groups, set retention policies (the default is "never delete," which gets expensive), parse structured logs, and set up alarms for error rates and latency thresholds. Teams that skip this step end up flying blind for the first few weeks on AWS, unable to debug issues that would have been trivial to diagnose on Heroku.

DNS and SSL certificate timing. If you are using Heroku's automated SSL (via ACM), your SSL certificate is tied to Heroku's infrastructure. You need a new certificate on AWS, either through AWS Certificate Manager (free for ALB and CloudFront) or by importing your own. The certificate provisioning and DNS validation process takes 10 to 30 minutes but must be done before cutover. Teams that forget this step end up with a working application that shows SSL warnings to users, which is worse than downtime.

Underestimating operational overhead. Heroku manages OS patches, security updates, runtime upgrades, and capacity planning for you. On AWS, that is your responsibility. If your team does not have DevOps experience, you need to factor in the ongoing cost of managing the infrastructure: patching ECS task definitions, rotating RDS certificates, monitoring for AWS service deprecations, and responding to infrastructure alerts. This is not a one-time migration cost. It is a permanent increase in operational burden that costs 5 to 15 hours per month for a small to medium application.

AWS is the obvious destination, but it is not always the right one. If your primary motivation is cost savings and you do not need AWS-specific services (SageMaker, Bedrock, DynamoDB, Kinesis), several platforms offer Heroku-like simplicity at a fraction of the cost. Consider these before committing to a full AWS migration.

Railway ($5/month base + usage). Railway is the closest spiritual successor to Heroku. You connect a GitHub repo, Railway detects your language and framework, and deploys automatically on every push. It supports Postgres, Redis, and cron jobs natively. Pricing is usage-based: you pay for actual CPU and memory consumption rather than fixed dyno sizes. A typical web app that costs $200/month on Heroku runs for $30 to $60/month on Railway. The tradeoff is that Railway is a smaller company with a smaller support team, and it does not offer the compliance certifications that enterprise customers require.

Render ($7/month for starter instances). Render positions itself as "Heroku done right." It supports web services, background workers, cron jobs, Postgres, and Redis with automatic deploys from Git. Pricing starts at $7/month for a 512 MB instance and scales to $85/month for 4 GB. Render offers managed Postgres starting at $7/month, which undercuts both Heroku and RDS. The platform has matured significantly since 2023 and now supports private networking, auto-scaling, and preview environments. For a deeper comparison of these platforms, see our breakdown of Vercel, AWS, and Railway.

Fly.io ($0/month free tier + usage). Fly.io runs your Docker containers on bare-metal servers at edge locations worldwide. It excels at low-latency applications because your code runs physically close to your users. Fly supports Postgres (via fly-postgres, which is a managed Postgres cluster running on Fly's infrastructure), Redis (via Upstash integration), and persistent volumes. Pricing is competitive: a shared-cpu-1x VM with 256 MB RAM costs roughly $1.94/month. The tradeoff is that Fly's platform has a steeper learning curve than Railway or Render, and their managed Postgres offering is less mature than RDS.

When AWS is genuinely the right choice. Choose AWS if you need services that only AWS provides (ML inference with SageMaker, serverless with Lambda at scale, data warehousing with Redshift), if your compliance framework requires specific AWS certifications, if you are already running other workloads on AWS and want to consolidate, or if your traffic scale demands the kind of fine-grained autoscaling and global distribution that only a hyperscaler can deliver. For a startup spending $300/month on Heroku with no compliance requirements, Railway or Render is almost certainly a better migration target than AWS. For a Series B company spending $4,000/month on Heroku with SOC 2 requirements and a dedicated DevOps engineer, AWS is the clear winner.

If you are unsure which path makes sense for your specific application, team, and budget, we are happy to help you figure it out. We have done this migration enough times to give you a straight answer in 30 minutes. Book a free strategy call and we will walk through your Heroku setup, estimate the migration cost, and recommend the right destination platform.