AWS Consulting Case Study: How to Plan a Heroku to AWS Migration Without Live Access

Introduction

The riskiest part of a cloud migration is usually what nobody has written down. A German fitness equipment brand with a live strength-training app had its backend on an outgoing agency's Heroku setup. It wanted the backend in an AWS account it owns, but nobody outside the agency knew exactly what that backend depended on.

In this AWS consulting case study, we mapped the backend in about 3 weeks with no live access to the old systems, found 11 migration blockers and gave the client a plan it could choose and act on.

Results at a Glance

• About 3 weeks from kickoff to a finished migration plan
• 3 code repositories reviewed and turned into one verified inventory
• 11 migration blockers found before any infrastructure was built, 4 of them rated high-severity
• 2 options, 1 clear recommendation, and the client chose it
• 6-phase cutover plan with a rollback for each phase

The Client

The client is a German fitness equipment brand. It sells online and runs a strength-training app for iOS and Android with a few thousand users. The app handles sign-in, training programs, exercise videos and AI-assisted program matching. A small in-house team owns the product, while an external agency had built and hosted the backend.

Why Did the Client Need AWS Consulting Before Migrating?

The agency relationship was ending. The client wanted the backend in its own AWS account, built so its own team and partners could run it. Their biggest worry was the unknown: hosting, the database account, media storage and error tracking all sat with the agency, and the client had only rough monthly cost figures.

What Constraints Did We Work Within?

• No live access to the old systems, so we worked from source code and an agency handover session
• No personal data touched before a data processing agreement was signed
• All data stays in the EU
• A live app that could not stop, with an app-store release cycle outside our control

How Does AWS Discovery Work Without Live Access to the Old System?

Inventory first. We reviewed all 3 code repositories and listed every service and integration. Each fact was marked as verified, agency-stated or unknown, and every unknown was given an owner. That turned the unknowns into a short list of questions with names next to them.

Blockers ranked by severity. We recorded 11 migration blockers before touching infrastructure: 4 high, 5 medium and 2 low. Three of them show why this phase matters.

Which Migration Blockers Changed the Plan?

Why Does a Hardcoded Hostname Block a Mobile App Migration?

High severity. The mobile apps had the old server address hardcoded. A DNS change would have moved nothing, and every phone running an older app version would have lost its backend. We built the whole cutover plan around this fact.

What Happens When a Media Service Run by the Agency Disappears?

High severity. The API sent images and videos to a compression service run by the agency, with no SLA. Had we missed it, media processing would have stopped the day the agency switched it off, and new uploads would have had no thumbnails or compressed versions. Email and AI providers were also missing from the client's own list.

How Can a Scheduled Job Outside the Code Become a GDPR Risk?

Medium severity. Scheduled maintenance, including the account deletion job, was triggered from outside the application. We rated it medium for migration risk, but it was the clearest GDPR compliance risk on the list.

Had we missed it, accounts deleted by users would never have been permanently removed after 30 days, and nobody would have noticed. In the build, the job moved to a scheduler with alarms for failed and missed runs.

What Else Did the Review Uncover?

We also found real-time connection state kept in memory, which blocks running more than one server. Static AWS keys sat in environment variables, and media files were public-read. The database tier turned out much smaller than the cost figures suggested.

Should You Move MongoDB to Amazon DocumentDB When Migrating to AWS?

Plan 1 kept MongoDB Atlas and replaced only what the agency controlled. Plan 2 went fully AWS-native with Amazon DocumentDB.

The deciding factor was another high-severity blocker. The code relies on multi-document MongoDB transactions, and moving to a database without full transaction support would have broken every write that uses them. DocumentDB supports them only with caveats, and Plan 2 cost about the same.

We recommended Plan 1, and the client chose it. Sometimes the best AWS design keeps a proven database where it is.

What Does a Safe Cutover Plan Look Like?

Before writing a line of infrastructure code, we designed a 6-phase cutover with a rollback for each phase. The client could see the order of events and how each step could be undone.

Outcome

The client chose Plan 1, signed a data processing agreement and moved straight into the build with the same team. Read how the migration went in our Heroku to AWS migration case study.

Want the same clarity before your own move? Learn more about our AWS consulting and AWS cloud assessment services.

Planning a move and not sure what depends on what?

We map your setup and rank the risks, so you get a plan before any infrastructure is built.

Book a Discovery Call

Explore AWS Consulting

Mykyta Glushko

Software Engineer at Perfsys with hands-on experience building scalable backend systems on AWS using Python and TypeScript. He works directly on cloud infrastructure projects, bringing practical engineering depth to every topic he covers.