On-prem to cloud migration goes best when you choose rehost, replatform or refactor separately for each application, not once for the whole estate. Score each app on four things: data gravity, licensing lock-in, uptime needs and your team's skills. For most apps, the right strategy becomes clear within an afternoon.
This is for the CTO who has a board deadline to "be in the cloud", a data centre lease that is running out and forty applications that nobody fully understands. One vendor has probably told you to "lift and shift everything". Another has told you to "rebuild it cloud native". For most estates, both are wrong.
Why does one strategy for the whole estate fail?
It fails because your applications are not alike. A stateless internal web app and a 15-year-old ERP on a licensed database share nothing except the server room.
Here is what each option means:
- Rehost (lift and shift): you move the virtual machine to cloud compute as it is. It is the fastest option with the fewest code changes, and it keeps every problem you already have.
- Replatform: you move the app and make targeted changes on the way. For example, you replace a self-managed database with a managed one such as Amazon RDS or Azure SQL, or you put the app in containers. The effort is moderate and the operational gains are real.
- Refactor: you change the architecture so the app uses cloud services directly, such as queues, autoscaling, serverless functions and object storage. It is the slowest option, with the highest payoff and the highest risk.
If you rehost everything, you end up with the same fragile systems plus a monthly bill that keeps growing, because nothing was sized for elastic infrastructure. If you refactor everything, the migration becomes a rewrite that takes years and often stalls halfway, so you pay for two environments.
What does a wrong choice cost you?
The damage rarely shows up on cutover day.
It shows up three months later.
Say you rehost a chatty app but its database stays on-prem. Now every request crosses a VPN link. Pages that loaded in 200 milliseconds take two seconds, and users notice before your monitoring does. Or you refactor an app your team cannot operate, and the 2 a.m. incidents arrive with nobody who knows how to debug them. Or you move a licensed workload without reading the licence, and the vendor counts cloud vCPUs differently from physical cores. That forces an emergency renegotiation or a rollback.
Each of these means rework and lost trust from the business. It can also mean a paused migration programme while people argue about who made the call.
How do you score each application?
Give every app a score from 1 to 3 on each of four factors. Write the reason next to each score, because you will have to defend that reason later.
| Factor | 1 (low) | 3 (high) |
|---|---|---|
| Data gravity | Small dataset, few integrations | Large database that many systems read from and write to |
| Licensing lock-in | Open source or licences that work on any cloud | Per-core or hardware-bound licences, or vendor support tied to specific OS versions |
| Uptime needs | A weekend outage is acceptable | Revenue or safety stops within minutes of downtime |
| Team skills | The team already runs containers and managed services | The team knows this app only on these servers |
Data gravity measures how strongly other systems depend on the app's data. With high gravity, the app should move in the same wave as its database and its closest consumers. Moving it alone is how latency problems start.
Licensing lock-in decides whether replatforming is allowed at all. Check the bring-your-own-licence terms, whether the vendor certifies the product on your target cloud, and whether licences are counted per physical core.
Uptime needs decide how much cutover risk you can take. High uptime needs call for replication-based cutovers and rehearsed rollbacks, not a big-bang weekend.
Team skills is the factor people skip most often. However elegant an architecture is, it becomes a liability if your team cannot run it.
Which strategy fits which score?
Start with these rules, then challenge them app by app.
- Licensing lock-in is 3: rehost first. Do not replatform until the vendor answers the licence question in writing.
- Data gravity is 3: move the app, its database and its main integrations in one wave, whichever strategy you pick.
- Uptime is 3 and team skills are 1: rehost with replication and a tested rollback. Refactoring under these conditions stacks two risks on top of each other.
- Team skills are 2 or 3 and the app has a self-managed database or file storage: replatform. This is where most of the operational benefit comes for the least effort.
- Refactor only with a clear business reason, such as the app needing to scale, being a product you sell or blocking new features. You also need team skills of 3, or a partner who will train your team as they go.
- Low scores everywhere and nobody can name an owner: consider retiring the app instead of moving it.
The result is a one-page sheet listing each app with its four scores, its strategy, its wave number and the reasoning. Take that sheet to the board. It holds up under questioning far better than "we chose lift and shift".
Do you need outside help for this?
Not always. You may have only a few stateless apps, a team that already runs production workloads on a cloud provider and no licences tied to physical hardware. In that case, the scoring above plus the provider's own tools, such as AWS Application Migration Service or Azure Migrate, will get you there.
Outside help is worth it when you have high data gravity, licensed databases, strict uptime needs or a team that has never run cloud infrastructure in production.
How do you run a pilot that shows real risk?
Choose a pilot app that can fail in useful ways. The common mistake is to take the simplest app in the estate, migrate it in a week and call the approach proven. That demo tells you nothing about the apps that will actually hurt.
A good pilot app has:
- At least one live integration with a system that stays on-prem for now. This tests latency, DNS, firewall rules and authentication across the hybrid link, which is where most surprises hide.
- A real database at production size. Use a sanitised copy of production data, not a test fixture. Long migration times and replication lag only appear at real size.
- Real users, even if only a small group. Synthetic checks will not catch the slow report that finance runs every Monday.
- A medium uptime score. That is high enough to force you to rehearse cutover and rollback, and low enough that a bad day is survivable.
Then treat the pilot like a production change:
- Write the rollback plan before the cutover plan, and run the rollback for real at least once in rehearsal.
- Agree on success criteria before you start: response times, error rates, a tested backup and restore, and an on-call runbook written by the people who will be paged.
- Track running costs for at least two full billing weeks, including outbound data transfer. Most estimates leave that cost out.
- Record every surprise in a shared log. That log becomes the risk register for the waves that follow.
If the pilot ends with an empty surprise log, you probably picked an app that was too easy.
What should you do first?
This week, list every application, score each one on the four factors and choose a pilot using the criteria above. Hold off on any estate-wide strategy until the pilot's surprise log is complete.
Geminate Solutions helps CTOs through this sequence: scoring the estate, running a pilot that tests real risk and handing over runbooks your team can own. You can read how that work runs on our cloud and DevOps page. You can also send us your app list or pilot plan for a free review. We sign an NDA before we talk and reply within 24 hours.
Top comments (0)