Checklist: Moving a Production App from Heroku to AWS
Map Heroku data, secrets, observability, cutover, and rollback before moving. KUMO is an AWS Partner. Get the checklist for engineering leaders in 2026.
Jul 29, 2026
Checklist: Moving a Production App from Heroku to AWS
A Heroku-to-AWS migration should be treated as a production change programme, not a hosting copy. Inventory applications, add-ons, data, build and release behaviour, secrets, domains, workers, scheduled jobs, logs, alerts, backups, and support ownership. Rehearse cutover and rollback before changing production traffic.
Use the downloadable Heroku to AWS Cutover and Rollback Checklist while you work through the decision. If the choice affects revenue, customers, data, or operating control, Book a 30-Min Discovery Call to map the smallest safe first release.
Who this guide is for
This checklist is for a revenue-stage technology or operations leader who needs more architectural control, regional design, networking options, observability, or scaling flexibility. It is not an argument that every Heroku application should move. Stay when Heroku still meets the operational and commercial requirement.
The decision at a glance
| Decision area | Stay on Heroku | Move to AWS |
|---|---|---|
| Strong fit | Team values managed platform simplicity and current limits are acceptable | Team needs deeper infrastructure, regional, networking, control, or service choices |
| Operations | Platform conventions reduce infrastructure work | Company must own architecture, deployment, monitoring, security, and cost controls |
| Cutover risk | No migration risk | Requires rehearsal, data plan, traffic shift, and rollback |
| Security | Heroku platform and application controls | AWS identity, network, encryption, logging, and account controls must be designed |
| ROI and payback | Avoid migration and operating overhead | Justified when control or scale requirements exceed transition cost |
The table is a starting point. Weight the factors that create business value, expose customer risk, or determine ownership after launch. Speed matters, but a fast option that leaves permanent manual repair or weak control can be the expensive choice.
For an evidence-based comparison of scope, ownership, and payback, Book a 30-Min Discovery Call before approving a vendor or architecture.
How to evaluate the decision
Application and dependency inventory
Record every web process, worker, scheduler, buildpack, runtime, add-on, external service, domain, certificate, and environment dependency. Heroku’s Platform API reference can help teams enumerate platform resources rather than relying on memory.
Record the current baseline, the required future state, the owner, the evidence available today, and the consequence if this area fails. This prevents a sales demonstration or technical preference from deciding a business-critical system.
Data and state
Map databases, caches, object storage, queues, file handling, backups, retention, replication, and restore tests. Decide whether cutover uses a maintenance window, continuous replication, dual writes, or another verified pattern.
Record the current baseline, the required future state, the owner, the evidence available today, and the consequence if this area fails. This prevents a sales demonstration or technical preference from deciding a business-critical system.
Secrets and identity
Move configuration into an approved AWS secrets and identity design. Avoid copying every config variable into a new environment without classifying ownership, rotation, exposure, and least-privilege access.
Record the current baseline, the required future state, the owner, the evidence available today, and the consequence if this area fails. This prevents a sales demonstration or technical preference from deciding a business-critical system.
Build, release, and rollback
Reproduce build artefacts, migrations, release commands, health checks, and rollback rules. A successful container start is not proof that the production release process is safe.
Record the current baseline, the required future state, the owner, the evidence available today, and the consequence if this area fails. This prevents a sales demonstration or technical preference from deciding a business-critical system.
Observability and support
Create logs, metrics, traces, alerts, dashboards, on-call ownership, and business checks before traffic moves. The target should make customer impact visible, not only infrastructure health.
Record the current baseline, the required future state, the owner, the evidence available today, and the consequence if this area fails. This prevents a sales demonstration or technical preference from deciding a business-critical system.
Cutover and DNS
Rehearse traffic shift, DNS TTL, certificate behaviour, database validation, queue drain, background jobs, and support communication. Define stop conditions and the last safe rollback point.
Record the current baseline, the required future state, the owner, the evidence available today, and the consequence if this area fails. This prevents a sales demonstration or technical preference from deciding a business-critical system.
Cost and governance
Set account structure, tagging, budgets, alerts, backup policy, patch ownership, and monthly review. AWS flexibility creates value only when the operating model is explicit.
Record the current baseline, the required future state, the owner, the evidence available today, and the consequence if this area fails. This prevents a sales demonstration or technical preference from deciding a business-critical system.
Evidence and operating proof
KUMO is an AWS Partner and operates CampaignHQ as a production B2B SaaS product on AWS. That proof supports cloud delivery experience, but it does not mean AWS is automatically the right destination for every Heroku app. The migration case should be made from control, reliability, security, and operating economics.
Primary references
Use primary sources for platform behaviour, pricing, and governance. Recheck live vendor pages on the decision date because terms, features, and rates can change. Professional legal, privacy, security, employment, and financial advice may still be required for the specific company and geography.
Investment, timeline, and payback
KUMO treats software and AI work as a custom engineering engagement, not a self-serve plan. A Starter Build typically ranges from $15K to $50K and 4 to 16 weeks. A Grow Build typically ranges from $50K to $100K and 16 to 24 weeks. Larger multi-workstream programmes can take 24+ weeks. The final quote follows scoping, integrations, security, migration risk, and ownership after launch. The useful comparison is expected payback against the cost of delay, operating effort, failure exposure, and the expense of changing direction later.
Build the business case from four lines: the current operating cost, the cost of delay, the expected value of the change, and the ongoing cost of ownership. Use ranges and expose assumptions. Do not turn an illustrative model into a promised saving or universal benchmark.
A practical implementation sequence
1. Establish the baseline
Document the users, workflow, systems, data, exceptions, cost, risk, and owner before selecting technology. Use real records and recent failures where possible.
2. Define the smallest safe release
Choose one outcome that can prove value without forcing the company to replace every adjacent system. Define acceptance and stop conditions in business language.
3. Prove the risky path first
Test the integration, data, security, migration, evaluation, or exception path that could invalidate the plan. A polished interface should not hide an unproven operating dependency.
4. Rehearse operations
Assign monitoring, support, approval, incident, rollback, and change owners. Run the workflow with representative data and people before broad release.
5. Measure and expand
Track outcome quality, failure recovery, operator effort, customer impact, and cost. Expand only when the evidence supports another workflow, user group, or market.
Create a decision record that survives the project
The final decision should state the business outcome, alternatives considered, evidence used, assumptions, owner, approval date, review date, and conditions that would change the choice. This record prevents the team from reopening the same argument when a vendor changes, a new stakeholder joins, or the first difficult exception appears. It also gives the delivery team a clear boundary between a deliberate trade-off and an accidental omission.
Define ownership before delivery
Name the business owner, product owner, technical owner, data owner, security reviewer, support owner, and commercial approver. One person can hold more than one role in a smaller company, but no role should be invisible. Ownership is especially important for exceptions, permissions, customer communication, cost approval, and the decision to pause or roll back a release.
Set acceptance evidence
Write acceptance in observable terms. Include representative records, user roles, successful and failed paths, integration responses, permission checks, support procedures, and operating dashboards. The evidence should allow a person outside the delivery team to understand why the release is safe enough to use. A demonstration is useful, but it does not replace repeatable checks and signed ownership.
Plan the first operating month
Reserve time for user support, issue triage, data reconciliation, performance review, cost review, and decision-making after release. The first month is when hidden assumptions become real operating work. Record what changed, which cases required intervention, how long recovery took, and whether the expected business outcome is appearing. Use that evidence to expand, adjust, or stop the next phase.
Measure quality and business value together
Technical success and business success should appear in the same review. Track reliability, security events, data quality, and recovery alongside customer completion, operator effort, turnaround time, conversion, margin, or another approved outcome. A system that is technically stable but creates more manual work is not successful. A system that creates value but cannot be governed is not ready to scale. Keep the baseline, evidence source, review owner, and decision date beside every measure so the next phase is based on comparable information rather than memory or optimism.
Risks to resolve before commitment
- Migrating services before documenting release and recovery behaviour.
- Moving the database without proving restore, validation, and rollback.
- Recreating infrastructure without logs, alerts, budgets, and owners.
- Changing DNS before background jobs and integrations are verified.
- Assuming AWS will be cheaper without modelling engineering and support effort.
Related KUMO resources
- AI infrastructure service
- custom software development
- CampaignHQ case study
- AWS Bedrock production cost guide
- software QA and release checklist
- software project rescue plan
What to Do This Week
- Export the full Heroku resource and dependency inventory.
- Map each dependency to an AWS target and named owner.
- Run a non-production rehearsal with production-like data volumes.
- Test restore, rollback, alerts, and business transactions.
- Approve go or no-go criteria before changing DNS or traffic.
Put the completed worksheet beside the current vendor quote, architecture, or hiring plan. The gaps should become explicit decisions with owners rather than assumptions hidden in the proposal.
Questions buyers ask
Should every Heroku app move to AWS?
No. Move when control, networking, regional, security, scale, or service requirements justify the transition and operating responsibility. Stay when platform simplicity remains the better business choice.
What is the first migration task?
Create a verified inventory of applications, processes, add-ons, data, secrets, domains, scheduled work, logs, and support dependencies.
How should rollback be designed?
Define the traffic switch, database state, jobs, writes, and support steps needed to return to the last known safe environment without losing new transactions.
What must be tested before cutover?
Test build and release, data migration, restore, health checks, business transactions, alerts, permissions, certificates, integrations, workers, and rollback.
How should AWS cost be evaluated?
Include cloud consumption, observability, backups, data transfer, security, engineering, support, and governance. Compare the full operating model with the current platform.
About KUMO
KUMO builds production AI and custom software for growing businesses. The team works across the US, UK, EU, Middle East, and India, with senior engineers from start to finish.
If you want a scoped recommendation using your systems, constraints, and commercial priorities, Book a 30-Min Discovery Call.
