Heroku Migration Services

When Heroku’s Costs Outpace Your Value

Your Rails application runs successfully on Heroku, but the economics have shifted. Heroku eliminated free tiers in November 2022 and increased prices across all plans. Your $7/month dyno now costs $20+, and your monthly hosting bill has climbed 200-400% without any changes to your application. Meanwhile, platforms like Render offer similar developer experience at lower costs, Fly.io provides global edge deployment, and AWS gives you enterprise control without enterprise complexity.

Migration to these alternatives typically reduces hosting costs by 50-80% while improving deployment speed, resource control, and scaling predictability.

Schedule a free 30-minute consultation to discuss your Heroku migration options. We’ll analyze your current setup and provide a preliminary cost comparison.

Why Teams Are Migrating from Heroku

Costs That Scale With Usage, Not Hope: Heroku charges for “Performance” dynos ($252/month) when you might need only a 1GB RAM container ($20-50/month). Modern platforms charge for actual resource consumption-CPU, memory, bandwidth-not arbitrary tier levels.

Deployment Speed and Predictability: Heroku builds take 2-5 minutes for typical Rails apps. Platforms like Fly.io and Render complete builds in under 90 seconds, with faster cache reuse on subsequent deploys.

Control Without Complexity: Heroku abstracts away infrastructure until you need something it doesn’t support. Modern platforms give you direct access to networking, volumes, and scaling rules when needed, while maintaining simple defaults.

Portability for Future Flexibility: Container-based platforms (Fly.io, Railway, AWS ECS) use Docker, making your deployment configuration portable across providers if your needs change.

Common Migration Challenges

Before discussing our approach, it’s helpful to understand why Heroku migrations aren’t always straightforward:

Environment Variable Propagation: Heroku stores configuration in config vars, but applications often rely on Heroku-specific variables like DATABASE_URL or REDIS_URL. These need conversion to platform equivalents, and connection pooling settings may differ.

Buildpack Compatibility: Heroku uses specific buildpack versions that may behave differently on other platforms. Ruby buildpacks, in particular, cache gems differently and may need adjustment for optimal performance.

Add-on Dependencies: Some Heroku add-ons have proprietary APIs or configuration formats. Migrating from Papertrail to Better Stack, for example, requires updating log drain configurations and recreating saved searches.

Background Job Queues: Heroku’s Redis add-on includes specific persistence and eviction policies. Migrating Sidekiq or Resque requires ensuring the new Redis instance matches these policies to prevent job loss.

DNS and Domain Management: Heroku provides automated SSL certificate management. Moving to other platforms requires configuring SSL certificates, updating DNS records, and potentially managing certificate renewals.

Understanding these challenges upfront helps plan for them rather than discovering them during cutover.

When Migration Might Not Make Sense: If your Heroku costs are under $100/month and your team values the simplicity, migration might not provide enough savings to justify the effort. We sometimes recommend optimizing current Heroku usage instead-downgrading dynos, adding Redis caching, or using Heroku’s new lower-cost options.

Migration Methodology

Assessment Phase

Before migrating, we audit your Heroku configuration to identify dependencies and potential issues:

• Add-on mapping: Document each Heroku add-on (Postgres, Redis, SendGrid, Papertrail) and identify target platform equivalents, including version compatibility and feature gaps
• Environment inventory: Catalog all environment variables, buildpacks, Procfile entries, scheduler jobs, and Heroku-specific configurations like heroku-preboot or heroku-repo
• Database analysis: Measure database size, identify large tables (>1GB), check for PostGIS extensions, and plan migration strategy based on downtime tolerance
• Dependency review: Check gem compatibility with target Ruby version, identify gems with native extensions that may need recompilation, and verify platform-specific dependencies
• Background job audit: Document Sidekiq/Resque configuration, queue priorities, scheduled jobs, and retry policies that need replication
• Asset pipeline assessment: Check for Heroku-specific asset compilation settings, CDN configurations, and storage service dependencies

This assessment typically takes 1-2 days and produces a detailed migration plan with risk analysis, including a dependency graph showing which components must migrate together.

Platform Selection

Based on your application’s requirements, we recommend one of these alternatives. Understanding the difference between buildpack and container approaches helps inform the decision:

Buildpack platforms (Render, DigitalOcean App Platform) work like Heroku-push code, platform builds and deploys. Simpler workflow but less control over the runtime environment.

Container platforms (Fly.io, AWS ECS) require Dockerizing your application. More setup initially, but complete control over dependencies, system libraries, and deployment configuration. Better for applications with specific runtime requirements.

Here are our platform recommendations:

• Render: Closest to Heroku’s developer experience-Git-based deploys, managed PostgreSQL with automatic backups, free tier for staging environments. Supports both native buildpacks and Docker. Monthly cost: $7-200 depending on plan.
• Fly.io: Container-based with global edge deployment using Anycast routing. Your Rails app runs in multiple regions simultaneously with automatic failover. Best for applications needing low-latency global access. Pricing: $1.94/month base + $0.000225/GB-hour.
• Railway: Simple interface with per-second billing and generous $5 credit/month. Supports both Heroku buildpacks and Dockerfiles. Good for startups and side projects that need Heroku simplicity without Heroku pricing.
• AWS (ECS/Fargate): Full control over networking, IAM roles, and auto-scaling policies. Integrates with CloudWatch for monitoring and ALB for load balancing. Best for applications with complex compliance requirements or existing AWS infrastructure. More complex but offers enterprise features.
• DigitalOcean App Platform: Managed platform with automatic scaling, free SSL, and managed databases. Supports both buildpacks and Docker. Good middle ground between simplicity and control. Pricing: $5-25/month per service.

We evaluate based on: monthly cost projections (typically 50-80% lower than Heroku), deployment workflow preferences, compliance requirements, and scaling needs.

Contact us to discuss which platform fits your needs. We’ll provide a platform comparison with cost estimates specific to your application.

Migration Execution

We follow this sequence to minimize downtime:

1. Provision target infrastructure - Create databases with identical PostgreSQL versions, Redis instances with same memory allocation, and application containers with appropriate CPU/memory limits
2. Configure environment variables - Port all configuration from Heroku config vars using heroku config -s, converting Heroku-specific variables (like DATABASE_URL) to platform equivalents
3. Migrate database - Use pg_dump -Fc for databases under 10GB, logical replication for 10-100GB, streaming replication for larger databases. Verify with pg_checksums and row counts.
4. Deploy application - Push to new platform using git push or docker push, verify web workers respond to health checks, and background jobs process from queues
5. Connect add-ons - Update application configuration for new email (Postmark/SES), logging (Better Stack/Datadog), and monitoring (Scout/New Relic) services. Test each integration.
6. Run acceptance tests - Execute full RSpec/Minitest suite against staging environment, including integration tests that verify external service connections
7. Schedule cutover - Plan DNS switch during low-traffic period (typically 2-4 AM UTC), document rollback procedure including database restore steps
8. Monitor post-migration - Watch error rates in Sentry/Bugsnag, response times in APM, background job queue depths in Sidekiq/Resque dashboard for 48 hours

Add-on Migration Strategy

Each Heroku add-on requires specific migration steps:

• Heroku Postgres → Managed PostgreSQL: Export with pg_dump -Fc --jobs=4 for parallel dump, restore with pg_restore -j 4 for parallel restore. For databases over 50GB, we use pg_dump with custom format for parallel restore. Update DATABASE_URL and connection pool settings.
• Heroku Redis → Managed Redis: Export RDB file with redis-cli --rdb, restore to target Redis instance, update REDIS_URL configuration. Background job queues (Sidekiq/Resque) require queue draining before cutover to prevent job duplication.
• SendGrid → Transactional Email: Configure SPF/DKIM records for new provider, migrate templates and API keys, verify sending reputation. We typically use Postmark for transactional emails due to deliverability focus. Test with curl to verify email delivery.
• Papertrail → Log Aggregation: Update log destination configuration via rails syslog or lograge, set up log drains to Better Stack or Datadog, recreate saved searches and alerts. Test with heroku logs -t equivalent.
• New Relic/Scout → Application Monitoring: Install new agent gem, configure newrelic.yml or scout_apm.yml with environment-specific settings, recreate custom dashboards and alert thresholds. Verify with test requests.
• Heroku Scheduler → Platform Cron: Convert scheduler entries to platform-native cron syntax. Heroku Scheduler’s hourly/daily becomes specific cron expressions. Test with at command or platform-specific testing tools.

Database Migration Strategies

Database migration is the most critical part of any Heroku migration. PostgreSQL offers several migration methods, each with different trade-offs between downtime, complexity, and data consistency.

The key factors determining our approach are:

• Database size: Larger databases require different tools and strategies
• Downtime tolerance: How much downtime can your application afford?
• Data consistency requirements: Do you need perfect point-in-time consistency?
• Schema changes: Are you making schema changes during migration?

Database size determines our migration approach:

Under 10GB: Direct pg_dump -Fc --jobs=4 for parallel dump, pg_restore -j 4 for parallel restore. We disable triggers during restore, then re-enable and verify constraints. Typical downtime: 5-15 minutes during maintenance window.

10-100GB: Logical replication using pg_dump for initial data load, then logical replication slots to catch up. We drain writes during final synchronization using application-level locks or maintenance mode. Typical downtime: 1-5 minutes.

Over 100GB: Streaming replication with pg_basebackup for initial sync, then streaming replication to maintain consistency. Cutover involves promoting replica with pg_ctl promote and switching connection strings. Typical downtime: under 1 minute.

For all approaches, we verify row counts with SELECT COUNT(*), checksums with pg_checksums, and application test suite passes against migrated database before cutover. We also test connection pooling settings (PgBouncer) and verify index performance with EXPLAIN ANALYZE.

What You Receive

Migration Documentation: Complete runbook detailing every step, command executed, and verification performed. Your team can repeat the process or troubleshoot issues.

Infrastructure as Code: Terraform or platform-specific configuration files that define your entire deployment stack. Version-controlled infrastructure means changes are reviewable and reversible.

Cost Comparison Report: Detailed analysis showing current Heroku costs vs. projected costs on target platform, including break-even timeline for migration investment.

Operational Runbook: Day-to-day procedures for your new platform-deploying code, scaling resources, managing databases, and handling common incidents.

Team Knowledge Transfer: 2-hour training session covering platform differences, deployment workflows, and operational procedures specific to your application.

30-Day Stabilization Support: We monitor your migrated application for 30 days, addressing any performance issues, configuration problems, or operational questions that arise.

Migration Timeline

Timeline depends on database size, add-on complexity, and testing requirements:

1-2 weeks: Applications with under 10GB database, standard add-ons (Postgres, Redis, SendGrid), and existing test coverage.

3-6 weeks: Applications requiring add-on replacements, database over 50GB, or custom buildpacks. Includes time for compatibility testing and performance validation.

6-12 weeks: Enterprise applications with compliance requirements, complex deployment pipelines, or dependencies on multiple Heroku-specific features.

All timelines include buffer for unexpected issues-we’ve never completed a migration without discovering at least one undocumented dependency.

Investment and ROI

Migration costs depend on database size and add-on complexity:

$3,000-8,000: Applications with under 10GB database, standard add-ons (Postgres, Redis, SendGrid), and existing test coverage. Includes migration plan, database transfer, add-on replacement, and 30-day support. Typical ROI: 2-4 months.

$8,000-15,000: Applications requiring custom add-on replacements, database over 50GB, or complex deployment pipelines. Includes performance testing, compatibility validation, and operational runbook creation. Typical ROI: 4-6 months.

$15,000-30,000: Enterprise applications with compliance requirements (HIPAA, SOC2), complex deployment pipelines, or dependencies on multiple Heroku-specific features. Includes security review, compliance documentation, and extended support. ROI varies based on current hosting spend.

ROI calculation: (Monthly Heroku cost - Monthly target platform cost) × 12 months = Annual savings. Example: A Rails app with $200/month Heroku cost moving to $50/month Render saves $1,800/year. Migration pays for itself in 2-4 months. Most applications reduce hosting costs by 50-80%, with database-heavy applications seeing higher savings due to Heroku Postgres pricing premiums ($50/month for 10GB vs. $15/month for equivalent managed PostgreSQL).

Beyond immediate cost savings, migration provides long-term value: better performance characteristics, clearer cost predictability, and platform flexibility if your needs change. This isn’t just about saving money-it’s about building infrastructure that scales with your application.

Next Steps

Schedule a free 30-minute consultation to discuss whether migration makes sense for your application. We’ll review your current setup, estimate migration complexity, and provide a platform recommendation with cost projections. Even if you decide not to migrate, you’ll leave with a clear understanding of your options and potential savings.

Prefer to evaluate independently first? Download our Heroku Migration Checklist - a step-by-step guide covering the 15 most common migration pitfalls and how to avoid them.