A cloud migration rarely goes wrong because of the technology. It tends to go wrong because of a question nobody asked until the project was under way, when changing course costs real money. We would want these six answered in writing, on no more than a couple of pages, before anyone moves a workload.

1. What outcome are we buying?

"Move to the cloud" is an activity. Outcomes sound like: we need to exit this data centre before the lease ends, recover from a site failure within four hours, or release weekly instead of quarterly.

The answer drives everything after it. A hard exit deadline may justify lifting and shifting servers as they are. Faster delivery won't come from that approach at all, since a slow release process moved onto someone else's hardware is still slow. If reduced cost is the stated goal, be sceptical until question 4 is answered, because a like-for-like move of always-on servers often costs more.

2. What do we actually run?

Your documentation is probably out of date, so observe the environment as well as reading about it.

  • Which applications exist, and who owns each?
  • What talks to what? Watch network traffic to find out, and include the overnight and month-end jobs.
  • What depends on low latency to something staying on-site? A chatty application separated from its database can become unusable.
  • Where are IP addresses hard-coded, or where do licences tie software to specific hardware?
  • What should be retired rather than moved?

The dependency map is the most useful artefact of early planning, since it determines which systems have to move together.

3. Where must the data live, and who can reach it?

Establish the actual obligations first. Contracts, sector rules and customer commitments may restrict location, while plenty of assumed "data must stay in New Zealand" requirements turn out to be preference. That preference may still be valid, but it should be recognised as a choice.

Local options have widened: Microsoft's Azure region in Auckland launched in 2024, and AWS opened its Asia Pacific (New Zealand) Region in 2025. Check that the specific services you need are available in a given region, because coverage varies and new regions tend to catch up over time.

Hosting offshore doesn't remove your responsibility. The Privacy Commissioner's guidance on overseas disclosure makes clear you generally remain responsible for personal information you put with a cloud provider. Settle encryption, key control, provider support access and administrator rights now too.

4. What will it cost over three years?

Compare a realistic model against what you pay today, including the true on-premises costs such as hardware refresh, power, space and staff time. Then add what tends to be left out:

  • Running both environments in parallel during migration, which may take far longer than you expect.
  • Data transfer charges, particularly traffic leaving the cloud.
  • Backup, logging and monitoring, which can grow into significant line items.
  • Licensing changes, because some software licences carry different terms in the cloud.
  • Training, and the engineering time of those doing the moving.

Compute prices are the easy part of this model. Treat any estimate built only from a list of servers as a lower bound.

5. Who runs it on day two?

Providers run the facilities and the underlying platform. Under the shared responsibility model, identity, configuration, patching of what you manage, data protection and cost remain yours.

Decide who is on call, who approves changes, who reviews security findings and who watches the bill. Establish account structure, identity, network design and logging as a foundation before the first workload arrives. Retrofitting them across a running estate is painful. If your team is new to the platform, build skills on something low-risk first.

6. How do we move, and how do we go back?

Choose an approach for each workload. Some are worth rehosting, others replatforming onto managed services, and a few redesigning. Some should stay put or be replaced by a SaaS product. A single strategy applied to everything will be wrong for most of it.

For each move, write down:

  • How the data gets synchronised, and how long the final cutover takes.
  • The acceptance tests that will confirm it works.
  • The conditions that trigger a rollback, who makes that call, and the point after which rolling back stops being possible, usually once new writes land in the target.
  • A restore test from backups in the new environment.

Rehearse the cutover at least once with realistic data volumes, since transfer times are a common surprise.

What to do this week

Write down your answers in one document, and mark each as known, assumed or unknown. Share it with finance, security and whoever owns the applications. Everything marked unknown becomes the first tasks on the project plan, ahead of any provisioning. If question 1 has no clear answer, stop there until it does.