Five questions to ask before committing to a cloud migration

Cloud migrations have a reputation problem. Not because cloud is bad -- it is not -- but because a meaningful percentage of migrations end up delivering less than promised, costing more than budgeted, and leaving the engineering team more stressed than before. The technology usually is not the failure point. The failure point is usually the questions that were not asked clearly enough before the work began.

Here are the five questions we ask every client before we recommend a cloud migration.

1. What are you actually trying to change?

"Moving to the cloud" is not an outcome. It is a means to an end. The organisations that get value from migrations are the ones that can answer this question with specificity: we want to reduce our infrastructure costs by 30%; we want to be able to scale the application without manual intervention; we want to eliminate the operational overhead of managing physical servers.

When the goal is vague, the success criteria are vague, and the project team has no principled way to decide between options. Clarity here also helps you choose the right migration strategy -- lift-and-shift, re-platform, or re-architect all make sense in different situations, but only if you know what situation you are actually in.

2. Do you understand your current costs?

Many organisations that come to us for cloud cost advice do not have a clear picture of what they are currently spending on technology. Without a baseline, you cannot measure improvement and you cannot make intelligent trade-offs between migration approaches.

Before any migration, we establish a cost baseline: compute, storage, networking, licensing, and the hidden costs like staff time spent on maintenance. This takes time, but it is the only way to know whether the migration has actually delivered on its cost objectives.

3. What does your team know, and what will they need to learn?

Migrating to the cloud changes what your team needs to know. If you have been running on-premises infrastructure, your engineers probably know how to configure physical servers and manage local networking -- but might not have experience with IAM policies, VPC configuration, or infrastructure-as-code.

The skill gap is not a reason not to migrate. It is a reason to plan the migration in a way that builds capability as it progresses, rather than dumping a cloud environment on a team that does not yet know how to operate it.

4. What will break?

Every non-trivial system has things that are currently working by accident -- implicit dependencies, hardcoded IPs, applications that assume specific filesystem paths, time-zone-sensitive jobs that rely on server-local time. A migration will surface all of these.

The question is not whether things will break. They will. The question is whether you have invested in discovering what will break before it breaks in production. A good migration plan includes an inventory of known risks, a testing strategy that validates behaviour in the new environment, and a rollback procedure that has been practised before go-live.

5. Who is accountable for operations after the migration?

Cloud environments require ongoing management -- cost monitoring, security patching, access reviews, capacity planning. This is not different from on-premises operations; it is just different work. The failure mode we see most often is a successful migration followed by an environment that drifts into disorganisation because nobody took ownership of it.

Before the migration begins, be explicit about who owns the cloud environment in steady state, what tools they will use to manage it, and what budget they have to work with. If you are planning to hand it to a managed service provider, choose the provider before the migration -- not after.

---

None of these questions have wrong answers. A migration that goes in with honest answers to all five is almost always better than one that does not. The questions that matter are not the technical ones; they are the business and operational ones that create the conditions for the technical work to succeed.