Heroku to AWS Migration: Step-by-Step Guide Using ECS, ECR, and CodePipeline

You’ve just received a Heroku sunset email, and now your entire weekend is shot. Breathtaking timing, isn’t it?

I’ve been there. When Heroku announced their free tier shutdown, dozens of our clients scrambled for AWS migration solutions that wouldn’t require rebuilding their entire CI/CD pipeline from scratch.

This guide walks you through a complete Heroku to AWS migration strategy using container services that actually make sense for production workloads. No oversimplified tutorials or theoretical approaches.

By the end, you’ll have a working AWS deployment pipeline that mirrors what you loved about Heroku’s simplicity, but with the reliability and scalability your growing application demands.

But first, let’s talk about the biggest migration mistake that even senior DevOps engineers make when moving containerized apps…

Understanding the Migration Landscape

Key Differences Between Heroku and AWS

Switching from Heroku to AWS is like trading your apartment for a house with a workshop. Heroku gives you a simple, managed experience while AWS hands you the keys to a massive toolbox. With AWS, you’re trading Heroku’s simplicity for granular control over infrastructure, scaling options, and cost management. The learning curve is steeper, but the possibilities? Way bigger.

Benefits of Migrating to AWS

Migrating to AWS isn’t just about following trends—it’s about unlocking serious power. Your applications can scale more precisely, cutting those oversized Heroku dynos that drain your wallet. You’ll gain deeper infrastructure visibility, tighter security controls, and services that Heroku simply doesn’t offer. For growing applications, AWS provides room to breathe that Heroku’s walled garden just can’t match.

Common Migration Challenges

Nobody tells you how painful it is moving from Heroku’s magic to AWS’s machinery. You’ll struggle with configuration management, service selection paralysis, and mysterious networking issues. Teams often underestimate the DevOps knowledge gap—what took minutes on Heroku now requires understanding VPCs, security groups, and IAM policies. Budget creep happens too, as all those “pay-for-what-you-use” services start adding up.

Essential AWS Services for Heroku Alternatives

The AWS ecosystem can replace every piece of your Heroku stack—if you know what to use. Start with ECS or EKS for container orchestration (goodbye Dynos), ECR for your Docker images, and RDS to replace Heroku Postgres. For continuous deployment, CodePipeline and CodeBuild deliver the goods. S3 handles static assets, while CloudWatch covers the monitoring Heroku used to handle automatically.

Preparing Your Application for Migration

A. Analyzing Your Current Heroku Architecture

Look under the hood of your Heroku setup before jumping ship. What dynos are you running? How’s your app structured? Map out those web processes, workers, and schedulers. Snap a screenshot of your Heroku dashboard – trust me, you’ll thank yourself later when configuring AWS resources to match your current performance needs.

B. Identifying Dependencies and Services

Got add-ons? Make a list – every Postgres database, Redis instance, and third-party service your app can’t live without. Heroku’s ecosystem is cozy, but AWS offers equivalent (often more powerful) alternatives:

Heroku Add-on	AWS Alternative
Heroku Postgres	Amazon RDS
Heroku Redis	ElastiCache
Papertrail	CloudWatch Logs
SendGrid	Amazon SES
Memcachier	ElastiCache Memcached

Don’t forget about those hidden dependencies in your app.json file!

C. Containerization Strategies for Seamless Migration

Docker is your best friend now. Create a Dockerfile that mirrors your Heroku environment – same runtime version, same package managers. The secret sauce? Structure it to handle both development and production environments:

FROM node:16

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["npm", "start"]

Multi-stage builds keep your images slim and deployments speedy.

D. Environment Variables and Configuration Management

Heroku’s config vars need a new home. AWS Systems Manager Parameter Store is perfect for this job – especially for secrets. Create a script to migrate them:

# Export Heroku config vars
heroku config -a your-app > heroku_config.txt

# Parse and import to AWS
while IFS='=' read -r key value; do
  aws ssm put-parameter \
    --name "/app/${key}" \
    --value "${value}" \
    --type "SecureString" \
    --overwrite
done < heroku_config.txt

Update your app to pull from SSM instead of environment variables.

E. Data Migration Considerations

Database migration is the trickiest part. For small datasets, a simple pg_dump/restore works:

# Dump from Heroku
heroku pg:backups:capture -a your-app
heroku pg:backups:download -a your-app

# Restore to RDS
pg_restore --verbose --clean --no-acl --no-owner -h your-rds-endpoint -U postgres -d your_db latest.dump

For larger databases (10GB+), consider AWS Database Migration Service to minimize downtime. Plan for a maintenance window regardless – your users will understand a scheduled 30-minute outage better than random errors during a live migration.

Setting Up Your AWS Environment

A. Creating and Configuring Your AWS Account

Jumping into AWS can feel overwhelming at first. But trust me, it’s easier than it looks. Start by signing up at aws.amazon.com with your email and payment info. Enable multi-factor authentication immediately—seriously, don’t skip this step. Then explore the AWS Management Console, your command center for everything you’ll build.

B. Designing a Secure VPC Architecture

Your Virtual Private Cloud is like your own isolated corner of AWS—it’s where all your resources will live. Create one with at least two public and two private subnets spread across different availability zones. This redundancy is your insurance policy against outages. Set up a proper CIDR block (something like 10.0.0.0/16) that gives you room to grow.

C. Setting Up IAM Roles and Permissions

AWS Identity and Access Management is your bouncer at the door. Create separate IAM roles for your ECS services, CI/CD pipeline, and any other components that need to talk to each other. Follow the principle of least privilege—only give access to what’s absolutely necessary. This might seem tedious now, but you’ll thank yourself later when you’re not scrambling during a security incident.

D. Establishing Networking and Security Groups

Security groups are your firewall rules on steroids. For your Heroku migration, you’ll need groups that allow your application to communicate internally while protecting it from the outside world. Configure inbound rules to accept traffic only on your application ports (like 80/443) and from trusted sources. Set up outbound rules to limit where your application can send data. Remember, every open port is a potential vulnerability.

Mastering Amazon ECR (Elastic Container Registry)

Creating Your First ECR Repository

Ever tried setting up an ECR repository? It’s actually pretty simple. Just hop into your AWS Management Console, navigate to the ECR service, and click “Create repository.” Name it something that makes sense for your app (like “my-heroku-app”), choose your encryption settings, and boom – you’re ready to store Docker images.

Configuring Authentication for Container Pushes

Before pushing images, you’ll need to authenticate. Run the AWS CLI command aws ecr get-login-password followed by docker login with your registry URL. This creates a temporary token that lets Docker talk to your ECR repository. No more authentication headaches!

Building and Tagging Docker Images

Time to build your Docker image. Navigate to your project directory and run docker build -t your-app-name . to create the image. Then tag it with your ECR repository URL using docker tag your-app-name:latest {account-id}.dkr.ecr.{region}.amazonaws.com/your-repo:latest. The tag tells Docker where this image belongs.

Pushing Images to ECR

Now for the fun part – actually getting your image into ECR. Just run docker push {account-id}.dkr.ecr.{region}.amazonaws.com/your-repo:latest and watch as your image uploads to AWS. After a successful push, you’ll see your image in the ECR console, ready for deployment to ECS.

Deploying with Amazon ECS (Elastic Container Service)

A. Choosing Between Fargate and EC2 Launch Types

Stuck between Fargate and EC2? The choice boils down to control versus convenience. Fargate is the no-server-management option – you deploy containers and AWS handles the rest. Perfect for teams wanting to focus purely on application code. EC2 gives you full control over your instances, ideal when you need custom configurations or have specific performance requirements. Most Heroku migrations lean toward Fargate for its similar hands-off approach.

B. Creating ECS Clusters and Task Definitions

Task definitions are your container blueprints in ECS – they’re where the magic happens. Think of them as your Heroku Procfile on steroids. You’ll specify container images, memory/CPU requirements, port mappings, and environment variables here. Creating a cluster is surprisingly simple:

aws ecs create-cluster --cluster-name heroku-migration-cluster

Your task definition JSON needs to include your ECR image, resource limits, and any mounted volumes:

{
  "family": "app-task",
  "executionRoleArn": "arn:aws:iam::your-account:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "app-container",
      "image": "your-ecr-repo-url:latest",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 3000,
          "hostPort": 3000
        }
      ],
      "environment": [
        {
          "name": "DATABASE_URL",
          "value": "postgres://username:password@host:5432/database"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/app-task",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}

C. Setting Up ECS Services for High Availability

ECS services maintain your desired task count running at all times – your fail-safe against crashes. When moving from Heroku, you’ll want to set a minimum of two tasks across different availability zones. This gives you similar redundancy to Heroku’s dyno system.

The CLI command looks like:

aws ecs create-service \
  --cluster heroku-migration-cluster \
  --service-name app-service \
  --task-definition app-task:1 \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:region:account-id:targetgroup/target-group-name/target-group-id,containerName=app-container,containerPort=3000"

This creates a service that keeps two instances of your app running and restarts any that fail – just like Heroku does automatically.

D. Configuring Load Balancing for Your Containers

Application Load Balancers (ALBs) are your traffic directors in AWS – routing requests to your containers while handling SSL termination. They’re crucial for Heroku migrations since you’re used to Heroku’s built-in routing.

Setting up an ALB involves:

Creating target groups linked to your ECS service
Configuring health checks (similar to Heroku’s ping system)
Setting up SSL certificates (via ACM)
Defining routing rules

The most common setup routes traffic based on paths, letting you handle multiple services under a single domain – perfect for microservices:

aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:region:account-id:listener/app/my-load-balancer/50dc6c495c0c9188/f2f7dc8efc522ab2 \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-targets/73e2d6bc24d8a067

E. Implementing Auto-scaling Strategies

Auto-scaling in ECS mirrors Heroku’s formation scaling but with more control. You can scale based on CPU, memory, request count, or custom metrics. The simplest approach uses target tracking:

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/heroku-migration-cluster/app-service \
  --min-capacity 2 \
  --max-capacity 10

aws application-autoscaling put-scaling-policy \
  --policy-name cpu-tracking-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/heroku-migration-cluster/app-service \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{"TargetValue":70.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'

This setup maintains CPU utilization around 70% by adding or removing tasks automatically – giving you the same elasticity as Heroku but with finer control over when and how scaling happens.

Automating Deployments with AWS CodePipeline

A. Creating a Pipeline for Continuous Delivery

Gone are the days of manual deployments. AWS CodePipeline handles the heavy lifting, connecting your code repos to production with just a few clicks. You set it up once, then watch as your code flows seamlessly from commit to deployment—no more SSH sessions or deployment scripts. It’s like having a dedicated DevOps engineer working 24/7.

B. Integrating Source Code Repositories

GitHub, BitBucket, or AWS CodeCommit—take your pick. CodePipeline plays nice with all major repositories. Just connect your repo, select your branch, and you’re good to go. Every push triggers your pipeline automatically. No more wondering if you’re deploying the latest code—CodePipeline keeps track for you.

C. Configuring Build and Test Stages

Build stages are where the magic happens. CodeBuild compiles your app, runs your tests, and packages everything up. Define your build commands in a buildspec.yml file—install dependencies, run tests, build assets. Failed tests? The pipeline stops right there. No broken code reaches production, ever.

D. Setting Up Deployment Strategies

Blue/green deployments aren’t just for the big players anymore. With CodePipeline and ECS, you can gradually shift traffic to new containers, monitor for issues, and roll back instantly if something goes wrong. Zero downtime deployments become your new normal, and your users won’t even notice when you push updates.

Optimizing Your AWS Infrastructure

A. Cost Management Techniques

After migrating from Heroku, AWS costs can quickly spiral out of control if you’re not careful. Start by using AWS Cost Explorer to identify resource hogs, implement auto-scaling to match actual usage patterns, and leverage reserved instances for predictable workloads. The difference between proper and poor cost management can mean thousands of dollars annually.

B. Performance Monitoring and Optimization

CloudWatch is your best friend here. Set up custom dashboards to monitor your ECS services, track CPU/memory usage, and identify bottlenecks. Don’t just collect metrics—act on them. Rightsize your instances based on actual performance data, not guesswork. Your application’s responsiveness directly impacts user satisfaction and retention.

C. Implementing Logging and Observability

Centralized logging isn’t optional—it’s essential. Configure CloudWatch Logs to aggregate data from all your containers and services. Use X-Ray for distributed tracing to understand request flows across your microservices. When production issues inevitably arise, you’ll thank yourself for having comprehensive observability tools already in place.

D. Backup and Disaster Recovery Planning

Nobody plans to fail, but you must plan for failure. Implement automated EBS snapshots, RDS backups, and consider cross-region replication for critical data. Test your recovery procedures regularly—an untested backup plan isn’t a plan at all. Remember: in AWS, you’re responsible for your data’s safety, not Amazon.

Advanced Migration Scenarios

A. Handling Database Migrations

Migrating databases from Heroku to AWS? It’s not just about dumping and restoring data. You’ll need to consider schema compatibility, zero-downtime migrations, and proper connection string updates. Amazon RDS offers solid options for PostgreSQL and MySQL, while DynamoDB works great if you’re using Heroku’s MongoDB add-ons.

B. Implementing Caching Solutions

Heroku’s memcached add-ons served you well, but AWS has ElastiCache ready to take over. Configure proper cache invalidation strategies, connection pooling, and session management. Remember to update your application’s cache configuration to point to your new ElastiCache endpoints – and don’t forget proper connection handling for multi-AZ setups.

C. Managing Microservices Architectures

Microservices on Heroku transitioning to AWS? ECS isn’t your only option. Consider AWS App Runner for simpler services or Lambda for event-driven components. Implement service discovery with AWS Cloud Map and manage inter-service communication with API Gateway. Your service mesh strategy needs rethinking for the AWS environment.

D. Migrating Heroku Add-ons to AWS Equivalents

Those Heroku add-ons you’ve grown dependent on have AWS counterparts waiting. Map SendGrid to SES, New Relic to CloudWatch, Papertrail to CloudWatch Logs, and Redis to ElastiCache. Each migration requires configuration changes and sometimes code updates. Test thoroughly – interface differences can bite you where it hurts.

E. Implementing CI/CD Beyond CodePipeline

CodePipeline is solid, but AWS offers more CI/CD flexibility. Consider GitHub Actions integration with AWS deployments, or look at AWS Amplify for frontend workflows. CircleCI and Jenkins work seamlessly with AWS too. The key is establishing environment parity and implementing proper testing gates before production deployments.

Migrating from Heroku to AWS offers tremendous potential for scaling, cost optimization, and enhanced control over your infrastructure. By following the step-by-step approach outlined in this guide—from preparing your application and setting up your AWS environment to implementing ECR, ECS, and CodePipeline—you can achieve a seamless transition while maintaining continuous deployment capabilities. The journey through container management, automated pipelines, and infrastructure optimization equips you with the tools needed for a successful cloud migration.

As you embark on your migration journey, remember that AWS’s ecosystem provides flexibility for both simple and complex migration scenarios. Take time to optimize your infrastructure, monitor costs, and leverage AWS’s extensive service offerings to build a robust, scalable architecture that meets your specific requirements. The initial effort invested in a well-planned migration will pay dividends through improved performance, better resource utilization, and the ability to adapt to evolving business needs in the future.