Heroku to AWS Migration: A Zero-Downtime Playbook

The six-step playbook for moving from Heroku to AWS without downtime, and the three planning mistakes that cause most migrations to stall.

Engineering teams evaluating Heroku alternatives in 2026 face a consistent challenge. The infrastructure move to AWS is straightforward. The organizational discipline required to execute it without downtime is not.

Most Heroku to AWS migrations do not fail because of technical mistakes. They fail because the migration was treated like a technical project. In reality, it is an operational one. The infrastructure moves successfully. Then something nobody documented, a webhook pointing to the old URL, a background job hitting the wrong database, an SSL certificate missing before DNS cutover, causes an incident. Two extra days of preparation would have prevented it.

The best Heroku alternative is only as good as the migration that gets you there. This playbook is written for engineering teams who want to get it right the first time.

TL;DR

What this covers: Step-by-step migration from Heroku to AWS with zero downtime, database cutover, DNS migration, cost reduction, and the planning mistakes that cause delays

Who it is for: Engineering teams actively planning a migration away from Heroku who need a practical operational playbook

The core principle: Operational discipline determines migration outcomes. Not technical complexity.

Want to skip straight to the technical steps? The full step-by-step reference is here.

Why Heroku to AWS Migrations Stall

Engineering teams evaluating the best Heroku alternatives in 2026 encounter the same failure modes repeatedly. Understanding them before starting is how teams avoid them.

Three planning mistakes account for the majority of delayed migrations.

Mistake 1: Starting before the inventory is complete.

Teams begin provisioning AWS infrastructure before documenting what they are migrating. Halfway through, they find a Heroku-specific buildpack nobody remembered. Or a scheduled job not captured in any deployment manifest. Or a third-party integration that assumes the Heroku environment and breaks silently in the new setup.

Each undocumented dependency adds days. Several at once add weeks. The inventory is not overhead. It is the foundation on which everything rests.

Mistake 2: Treating database migration as a single step.

Database migration is the highest-risk part of any Heroku alternative migration. Teams that treat it as one step export, restore, switch connection strings, consistently run into problems. A parallel running approach would have caught these issues before customers were affected.

Running both databases simultaneously, verifying integrity at each stage, and keeping rollback options open is the operational standard. Not a precaution.

Mistake 3: Skipping the observation period.

Teams that move directly from “testing looks good” to “update DNS” skip the most valuable risk mitigation available, time. Real production traffic surfaces edge cases that testing never reveals. Background jobs behave differently under real load. Third-party webhooks go to stale URLs. Queries that passed testing degrade under concurrent traffic.

Teams that execute Heroku alternative migrations cleanly treat parallel running as non-negotiable.

Step 1: Run the Inventory Sprint

Every successful Heroku to AWS migration begins with documentation. Not infrastructure.

Before provisioning a single AWS resource, complete a full inventory of everything being migrated. For most production applications, this takes two to three days. It consistently eliminates the undocumented dependencies that cause mid-migration delays.

What to inventory:

Every Heroku service, dyno type, dyno count, buildpack configuration, the GitHub branch it deploys from, and any Heroku-specific environment assumptions in the code.

Every add-on, including ones that look unused. Some were enabled for features that no longer exist but were never removed. All need to be evaluated before migration begins.

Every config var, exported from Heroku and mapped to equivalents in the new environment. Pay close attention to Heroku-specific values: callback URLs pointing to herokuapp.com, DATABASE_URL values in Heroku’s format, and add-on credentials that need replacement.

Every third-party integration, services sending webhooks to the Heroku application, external APIs with the Heroku domain whitelisted, and email services with Heroku-specific callback URLs. These are the most commonly missed items. They are also the most common source of post-migration incidents.

Every scheduled job, whether running through Heroku Scheduler, the whenever gem, or a clock process. Scheduled jobs are easy to miss because they only run at specific intervals. They rarely surface during standard testing.

Heroku’s dependency on AWS equivalent:

Teams with years of Heroku-specific buildpacks, Heroku Postgres, and add-on dependencies do not need to rewrite their application stack. They need to map each dependency to its AWS equivalent and validate the replacement before cutover. LocalOps handles this mapping automatically for the most common stacks, including Rails, Node.js, Python, and Go. This makes it a practical Rails hosting Heroku alternative as well as a general AWS deployment platform.

Application code does not change for most of these migrations. Connection strings change. Environment variables change. The underlying logic stays the same.

Step 2: Provision the AWS Environment

With the inventory complete, provision the target environment in AWS before touching Heroku production.

With LocalOps, this takes under 30 minutes. Connect your AWS account through keyless IAM role assumption; credentials never leave your cloud. Connect your GitHub repository. Create a new environment. LocalOps then provisions a dedicated VPC, EKS cluster, load balancers, IAM roles, and a complete observability stack, Prometheus, Loki, and Grafana, automatically.

No Terraform. No Helm charts. No manual configuration.

Every environment follows AWS Well-Architected standards by default. Private subnets, least-privilege IAM policies, encrypted secrets via AWS Secrets Manager, and security group configurations are applied automatically. This is what makes LocalOps a genuine Heroku self-hosted alternative: your infrastructure, your AWS account, your compliance posture.

Verify before moving on:

Confirm the environment is provisioned in the correct AWS region. Confirm VPC configuration meets your security and compliance requirements.

Get started and provision your first environment in under 30 minutes.

Step 3: Deploy and Verify the Application

Push application code to a ‘prod’ branch. Create a service in the environment created by LocalOps and configure the prod branch as the source. LocalOps detects the push, builds the container image automatically, and deploys to EKS. Rails, Node.js, Python, Go, and .NET are all detected and configured automatically.

Heroku buildpack replacement happens transparently. If your team has Heroku-specific buildpack configurations, LocalOps’s container build process handles the equivalent setup. No application code changes are required. This is one of the most common concerns teams raise when evaluating alternatives to Heroku. In practice, it is one of the simpler parts of the migration.

Configure secrets in the service. Use the same Heroku postgres database string for now.

Do not proceed to database migration until all of these pass:

• Web service endpoints respond correctly

• Background workers start and process test jobs

• Scheduled jobs execute at configured intervals

• File storage operations work with the new backend

• All environment variables load correctly

• Third-party integrations connect and respond

• Logs and metrics appear in Grafana dashboards

Teams that rush this phase find the issues later, during the database migration phase, under production pressure.

Step 4: Migrate the Database

Database migration is the highest-risk phase of any Heroku migration. Treat it as a phase with distinct steps and verification gates.

The full technical reference is in the LocalOps Heroku migration guide. The operational steps are:

Create and verify a backup. Create a manual backup of Heroku Postgres using the Heroku CLI. Verify the backup file size matches the expected database size before proceeding.

Provision Amazon RDS. LocalOps provisions RDS inside your VPC automatically. The database runs privately, not publicly accessible, with credentials stored in AWS Secrets Manager.

Restore and run integrity checks. Restore the backup to RDS using an EC2 instance inside the same VPC. Run integrity checks before switching any application traffic. Check row counts on critical tables, spot-check recent data, and verify all Postgres extensions are present. Do not proceed until every check passes.

Run both databases in parallel. For production applications where downtime is unacceptable, use AWS Database Migration Service to replicate ongoing changes from Heroku Postgres to RDS in near-real time. Both databases receive writes. Both stay in sync. Keep both running until confidence in the target database is high, not just until initial tests pass.

Handle background workers. Scale background workers to zero before switching the database connection string. Let in-flight jobs complete. Later, switch the connection string. Verify connectivity. Scale workers back up. Monitor job processing closely for the first hour after the switch.

Switch connection strings and monitor. Update environment variables to point to RDS. Deploy the change. Monitor logs and database metrics for the first 30 minutes. Watch specifically for connection pool exhaustion, query performance changes, and connectivity errors.

Read the full database migration walkthrough.

Step 5: The Parallel Running Period

Before updating DNS, run both the Heroku app and the AWS environment simultaneously with real production traffic.

This is the step most commonly compressed under deadline pressure. It is also the source of most post-migration incidents. Teams that skip parallel running consistently discover in production the edge cases that a proper observation period would have caught safely.

What parallel running catches:

• Background jobs behave differently under real load

• Third-party webhooks are going to stale URLs

• Cron jobs creating conflicts under real concurrency

• Queries degrade under concurrent production traffic

Minimum periods:

Small applications - 48 to 72 hours.

Mid-size production applications - 5 to 7 days.

Large applications with complex dependencies - 2 weeks.

If unexpected behaviour surfaces, extend the period. Do not compress it to meet a deadline.

Step 6: DNS Cutover

DNS cutover is the second-highest-risk step when migrating to an AWS Heroku alternative. Execute it with preparation and a documented rollback plan.

48 hours before:

Lower TTL on all DNS records to 60 seconds. Verify SSL certificates are active for all custom domains in AWS Certificate Manager. LocalOps provisions these automatically, but verify before cutover day. Document the rollback procedure and confirm the team member responsible is available during the cutover window.

On cutover day:

Update DNS records to point to the new LocalOps environment. Both environments receive traffic briefly during propagation, keep both operational with monitoring active. Watch the new environment closely for the first four hours. Look specifically for elevated error rates, response time changes, job processing failures, and integration errors.

After cutover:

Keep Heroku running for 24–48 hours. The cost of two extra days is far lower than the cost of rolling back under pressure. Do not decommission Heroku until the observation period is complete.

Prefer to have LocalOps engineers handle the cutover for you? Schedule a migration call.

What the Cost Reduction Looks Like

The cost reduction from moving to an AWS Heroku alternative via LocalOps comes from two structural sources.

Source 1: No platform margin.

Heroku runs on AWS and charges a markup on every resource it provisions. Every dyno carries a Heroku margin. Every Heroku Postgres instance is an Amazon RDS with a Heroku margin. Every Heroku Redis instance is an ElastiCache with a Heroku margin.

With LocalOps, you pay AWS list pricing for every resource. The margin is gone. The size of the difference depends on dyno count, database tier, and traffic volume. However, the direction is structural; AWS pricing without a platform margin is lower than PaaS pricing with one.

Source 2: No observability add-on fees.

A typical production Heroku stack includes paid add-ons for log management and application performance monitoring. LocalOps includes Prometheus, Loki, and Grafana pre-configured in every environment. These tools are included, not sold separately.

This is a structural difference from Heroku open source alternatives, where observability setup is entirely your team’s responsibility, and from first-generation alternatives to Heroku like Render or Railway, where monitoring add-ons remain separate cost items.

For an estimate based on your current Heroku setup, speak with the LocalOps team.

The timeline is determined by documentation quality and parallel running discipline. Teams that invest in both migrate faster, because they are not debugging mid-migration the issues the inventory would have caught upfront.

White-glove migration available. LocalOps engineers handle the entire process end-to-end, including database migration, environment variables, custom domains, and DNS cutover. Most teams are live within a day. Schedule a migration call.

How LocalOps Works as the Best AWS Heroku Alternative

LocalOps is an AWS-native Internal Developer Platform built for teams, replacing Heroku.

Connect your AWS account. Connect your GitHub repository. LocalOps provisions a dedicated VPC, EKS cluster, load balancers, IAM roles, and a full observability stack automatically. No Terraform. No Helm charts. No manual steps. First environment ready in under 30 minutes.

From that point, the developer experience matches Heroku exactly. Push to your configured branch. LocalOps builds, containerizes, and deploys to AWS automatically. Logs and metrics are available from day one. Autoscaling and auto-healing run by default.

The infrastructure lives in your AWS account. If you stop using LocalOps, it keeps running. Nothing needs to be rebuilt. This is the fundamental difference between LocalOps and alternatives to Heroku that simply replace one managed platform with another.

“Even if we had diverted all our engineering resources to doing this in-house, it would have easily taken 10–12 man months of effort , all of which LocalOps has saved for us.” – Gaurav Verma, CTO and Co-founder, SuprSend

“We saved months of DevOps effort by using LocalOps.” – Shobit Gupta, Ex-Uber, CTO and Co-founder, Segwise

Get started for free - first environment live in under 30 minutes.

Frequently Asked Questions

1. What is the highest-risk step when migrating to an AWS Heroku alternative?

Database migration carries the highest risk. It involves moving the most critical stateful component with limited rollback options if something goes wrong. The safe path runs both databases in parallel using AWS DMS, switches connection strings only after integrity is verified, and keeps Heroku Postgres running until confidence in RDS is established. DNS cutover is the second-highest-risk step. Lower TTL 48 hours before the switch, document the rollback plan before starting, and keep Heroku running through the full observation period after propagation.

2. What are the best Heroku alternatives in 2026 for zero-downtime migration?

AWS-native Internal Developer Platforms are the strongest Heroku alternatives in 2026 for teams with strict uptime requirements. The migration approach uses AWS DMS for near-real-time database replication. Both environments run simultaneously until confidence is high. DNS cutover happens after a full parallel running period. The Heroku application stays live throughout, with no forced downtime window. First-generation alternatives to Heroku, like Render and Railway, do not support this model because they require rebuilding infrastructure rather than running parallel environments.

3. How long does a Heroku to AWS migration realistically take?

Small applications, two to three services, database under 2GB, take three to seven days. Mid-size production applications, five to ten services, background workers, and custom domains, take two to four weeks. Large applications with ten or more services and compliance requirements take six to twelve weeks. Documentation quality before migration begins is the primary timeline variable. A two to three-day inventory sprint consistently reduces overall timelines by eliminating undocumented dependencies.

4. Do we need to rewrite the application when choosing the best Heroku alternative?

No. Teams with years of Heroku-specific buildpacks, Heroku Postgres, and add-on dependencies do not need to rewrite their stack. Application code stays the same. Connection strings change. Environment variables change. LocalOps handles buildpack replacement automatically through container build detection. The DATABASE_URL connection string format requires a configuration update, not a code change.

5. What is a Heroku self-hosted alternative?

A Heroku self-hosted alternative is a deployment platform running on infrastructure the team owns, in their own AWS account, rather than on a shared third-party cloud. Teams should consider this path when compliance requirements demand data residency in their own cloud, when enterprise customers require VPC isolation and private networking, or when the platform margin of a managed PaaS has become a meaningful cost concern. LocalOps provides a self-hosted Heroku alternative without the operational overhead of building and running the platform layer from scratch.

6. How do Heroku open source alternatives compare to LocalOps?

Heroku open source alternatives like Coolify and Dokku give full infrastructure control but require the team to own the complete operational burden, provisioning, security patching, observability setup, scaling, and on-call response for the platform itself. LocalOps provides the same infrastructure ownership with the platform layer managed. For teams without dedicated platform engineering capacity, the operational cost of running a Heroku open source alternative in production consistently exceeds initial estimates. LocalOps is designed for teams that want infrastructure ownership without building and maintaining the platform themselves.

Key Takeaways

A zero-downtime Heroku migration is an operational achievement. Not a technical one.

The engineering work is straightforward with the right tooling. LocalOps provisions production-ready AWS infrastructure in under 30 minutes, preserves git-push developer workflows, and includes built-in observability. What this playbook provides is the operational discipline that turns a technically correct migration into a production-safe one.

For engineering teams evaluating Heroku alternatives in 2026, the right decision is not just about what is cheapest or fastest. It is about what still works when the system, compliance requirements, and team are significantly larger than they are today. The best Heroku alternative solves the immediate migration problem and the long-term infrastructure ownership problem at the same time.

Schedule a Migration Call → LocalOps engineers handle the migration end-to-end, database, environment variables, domains, and DNS.

Get Started for Free → First environment live in under 30 minutes. No credit card required.

Read the Technical Migration Guide → Step-by-step commands, configuration, and RDS setup, all covered.

Related reading:

Heroku Alternatives in 2026: The Complete Guide for Engineering Leaders

How to Migrate from Heroku to AWS Without Losing Developer Experience