switching software/cloud infrastructure

Heroku to AWS: PaaS to IaaS Migration for Growing Teams

Transition from Heroku simplicity to AWS control for cost and customisation.

1. Executive Summary

Migrating from Heroku to AWS represents a transition from a Platform-as-a-Service (PaaS) abstraction to an Infrastructure-as-a-Service (IaaS/CaaS) model. While Heroku offers rapid developer velocity via "Buildpacks," AWS provides granular control over networking, security, and scalability. This guide outlines the strategic shift from Heroku’s managed environment to AWS services like ECS/EKS, RDS, and S3, focusing on achieving operational maturity while maintaining the agility of your original deployment pipeline.

2. Why Businesses Migrate

  • Drivers: Cost optimization at scale, architectural flexibility (e.g., microservices requiring custom sidecars), advanced networking requirements (PrivateLink, Direct Connect), and deeper integration with native cloud services (AI/ML, Data Lakes).
  • Anti-patterns: Attempting a "lift-and-shift" without containerizing applications, neglecting to implement Infrastructure-as-Code (IaC), or failing to account for the overhead of managing the underlying OS/runtime patches previously handled by Heroku.

3. The 6 Rs of Migration (Heroku-Specific)

  • Rehost (Lift-and-Shift): Moving the application to EC2 instances. Not recommended as it loses cloud-native benefits.
  • Replatform (Lift-and-Reshape): Moving from Heroku Dynos to AWS App Runner or ECS Fargate. This is the "sweet spot" for most mid-market users.
  • Refactor: Rewriting legacy monolithic Heroku code into serverless functions (AWS Lambda) or microservices architecture to optimize for cost and performance.
  • Repurchase: Swapping Heroku Add-ons for AWS Marketplace native equivalents (e.g., moving from Heroku Postgres to Amazon RDS).
  • Retire: Deleting unused legacy apps that were kept alive due to Heroku's ease of deployment.
  • Retain: Keeping specific components on Heroku if they require specialized third-party integrations not yet available in the AWS ecosystem.

4. Pre-Migration Assessment

  • Inventory: Extract all heroku config variables, add-on manifests, and buildpack configurations.
  • Network Mapping: Map Heroku’s ephemeral routing mesh to an AWS VPC architecture (Public/Private subnets, NAT Gateways).
  • IAM: Map Heroku "Collaborators" to AWS IAM Roles/Users using AWS IAM Identity Center (SSO). Implement Principle of Least Privilege.
  • Data Transfer Calc: Assess the egress volume from Heroku Postgres to AWS RDS. Use AWS DataSync or AWS Database Migration Service (DMS) for continuous replication.

5. Step-by-Step Execution Plan

  1. Foundation: Deploy a Landing Zone via AWS Control Tower. Set up VPC, Subnets, and Security Groups.
  2. Pilot: Migrate a low-criticality service to ECS Fargate. Establish CI/CD via AWS CodePipeline or GitHub Actions targeting ECR.
  3. Data Migration: Use AWS DMS for Postgres-to-RDS migration. Execute a schema migration followed by full-load and CDC (Change Data Capture) to minimize cutover downtime.
  4. Cutover: Update DNS (Route53). Implement a "Blue/Green" deployment strategy, routing traffic incrementally from Heroku to AWS using weighted records.

6. Troubleshooting Common Issues

  • Networking: Heroku Dynos have dynamic IPs; AWS services require static or predictable IP ranges. Use AWS Network Firewall or Security Groups to mimic Heroku’s egress filtering.
  • Environment Variables: Heroku config vars are injected at runtime; ensure AWS Parameter Store or Secrets Manager is integrated into your application startup sequence.
  • Logging: Heroku drains logs natively; transition to Amazon CloudWatch Logs using the AWS FireLens log router for containers.

7. UK-Specific Compliance

  • GDPR: Ensure data residency by selecting the eu-west-2 (London) region.
  • Data Residency: Utilize AWS Organizations to restrict service deployment to UK regions, ensuring PII does not leave the jurisdiction. Ensure all S3 buckets have "Block Public Access" enabled and utilize KMS for encryption at rest.

8. Cost Modeling

  • Heroku: Pay for Dyno-hours + Add-on premiums.
  • AWS: Pay for compute (Fargate), storage (EBS/S3), data transfer (egress), and managed services (RDS).
  • Optimization Tip: Utilize Savings Plans for compute and RDS Reserved Instances to achieve a 30–50% cost reduction compared to Heroku at scale.

9. Conclusion

Migrating from Heroku to AWS is a transition from managed convenience to architectural sovereignty. By focusing on containerization and automated infrastructure, mid-market organizations can effectively lower long-term OpEx while gaining the security and compliance posture required for modern enterprise applications. Prioritize a phased Replatforming strategy to maintain velocity while unlocking the full power of the AWS ecosystem.