Cloud Migration: Rehost, Refactor, or Replatform? Here’s What Actually Worked

When we first spoke with the tech team behind a hospitality management platform and marketplace, “cloud migration” wasn’t on their agenda.

Stability was.

Their stack was hosted on IONOS Cloud, running on basic virtual machines. Everything — from deployments to debugging — was done manually. No pipelines. No observability. A docker-compose up via SSH was their “deployment strategy.”

The product team was moving slowly. Developers were wasting time chasing invisible issues. Customers were complaining. And when problems arose — which they did often — the team struggled to detect, reproduce, or resolve them.

Their infrastructure wasn’t just slowing them down — it was holding them hostage.

The Real Driver Behind the Migration

Contrary to popular belief, migration is rarely the goal. In this case, the client didn’t come to us saying “we want to move to AWS.” They said, “we need to move faster, and we need things not to break.”

Our job was to unblock product velocity and bring back trust in the platform.

To do that, migration became a means to an end — but the end goal was always about stability and speed.

Choosing the Right Approach: Not Refactor, Not Rehost

The moment we reviewed their architecture, we saw a familiar sight: the application was already running in containers, split into small services, and using message queues.

So we had three options:

Rehost: Lift-and-shift their exact VM setup to AWS. Fast, but it wouldn’t solve their problems.
Refactor: Re-architect the entire application to be “cloud-native.” Expensive, slow, and unnecessary.
Replatform: Move to AWS and make minimal but essential changes — just enough to leverage AWS’s managed services, automation, and scale.

➡ We chose replatforming. And it worked.

From Concept to Cloud in Days, Not Months

We started with a product the customer nominated — not live, but struggling — to run a fast experiment.

Within a day, we provisioned a fully operational AWS setup using our pre-tested infrastructure-as-code boilerplates.

We spent the first week building out a CI/CD pipeline, deploying to a staging environment on EKS. By week two, everything was in place for testing.

Then came reality.

Apps Aren’t Always Cloud-Ready — But They Don’t Have to Be

Although the infra was ready, the app wasn’t. It lacked proper health checks, didn’t read configs from environment variables, and routing was inconsistent.

Rather than pause and demand refactoring, we jumped in and collaborated with the developers.

We:

Implemented health checks.
Aligned env var configurations.
Built monitoring dashboards and alerting from scratch (again, boilerplates helped).
Introduced Linkerd for inter-service observability.
Set up Sentry for runtime error tracking.
And established an incident response process with clear ownership and alerts.

It wasn’t magic — just experience and good communication. Within a month, the platform was live on AWS.

What Changed Post-Migration

The improvements were night and day.

✅ Autoscaling kicked in smoothly during user traffic spikes.
✅ Developers had a predictable deployment process.
✅ Incidents dropped significantly — and when they occurred, detection and resolution were fast.
✅ Monitoring and alerting closed the feedback loop, so bugs didn’t go unnoticed.
✅ The team gained confidence, knowing their tools supported them, not the other way around.

We didn’t change everything. We changed what mattered.

Replatforming Is the Unsung Hero

There’s a lot of talk about refactoring. About going all-in on serverless. About redesigning for microservices.

But here’s the truth from the trenches:

If your app runs on a VM, you’re 80% of the way to running it in a modern cloud environment.

You don’t always need a full rewrite. Most apps can be packaged into containers, wired into managed services, and deployed with good observability — all without a complete architectural overhaul.

Replatforming gets you the reliability and scalability you need — fast — without the costs of refactoring or the limits of a simple rehost.

CTOs, Don’t Pay to Learn the Cloud

You don’t need to become an expert in provisioning Grafana, scaling Prometheus, tuning EKS, or choosing the “right” database.

Let infrastructure experts do that — ideally ones who’ve built things themselves and can collaborate with your team like true partners.

Use proven templates and battle-tested patterns, not guesswork. You’re not just paying for infrastructure — you’re paying to skip the mistakes.

Final Thought: Move Fast, But Don’t Break the App

If your cloud provider is holding you back, and your app is even halfway modern, don’t wait.

Start with a replatform. Fix the blockers. Go live. Split services later — when it makes sense.

Migration isn’t a goal. Velocity is.