Cloud Migration Guide: Planning Your Journey to AWS, Azure, or GCP

Write down the business reason before any technical work. Common reasons include leaving an aging data centre, ending a hardware lease, improving resilience, scaling faster, or reaching software that only runs as a service. The reason shapes every later decision. A move driven by a data centre exit deadline favours speed and rehosting. A move driven by agility favours refactoring the applications that change most often. If you cannot name the reason, the project will be judged on cost alone, and that rarely goes well.

Every workload gets one of six treatments. Decide per workload, not per project.

Retiring is the cheapest strategy, so look for it first. Many environments contain systems that no one has used for years.

You cannot plan a move for systems you have not mapped. Build an inventory that covers:

• Servers, operating systems, versions and sizes.
• Applications, their owners and their business criticality.
• Dependencies between systems, including databases, file shares, authentication and scheduled jobs.
• Network flows, so you know which systems talk to each other and how often.
• Performance baselines for CPU, memory, storage and network over a full business cycle.
• Software licensing terms, because some licences do not transfer to a cloud environment on the same terms.
• Data volumes and how often they change.

Treat privacy and residency as an assessment topic, not a late surprise. In Canada, some organizations, especially in the public sector and health care, have legal or contractual requirements about where data is stored and who can access it. If residency matters, choose a Canadian region, and ask where backups, logs and provider support access sit, because those can live elsewhere by default.

Build the landing zone first

A landing zone is the prepared foundation that workloads arrive into. It should exist before the first migration, and should include:

• An account or subscription structure that separates production from non-production.
• Identity integration with single sign-on, multi-factor authentication and role-based access.
• Network design with segmentation, address ranges that do not overlap with your existing networks, and DNS that resolves in both directions.
• Central logging and audit trails turned on from the start.
• Guardrails as policy, such as required tags, permitted regions and blocked public storage.
• Backup and recovery configuration.

The cloud security checklist is a good test of whether the foundation is ready.

Plan connectivity and data movement

Decide how data and users will reach the cloud. A site-to-site VPN is quick to set up and suits small volumes and early pilots. A dedicated private connection suits steady, high-volume traffic and gives more predictable latency, and it usually takes longer to arrange. Whatever you choose, plan a second path for resilience. The dedicated internet access guide explains the circuit side.

Check the arithmetic on initial data transfer. At a theoretical 1 Gbps, moving one terabyte takes about two and a quarter hours. Real throughput is lower because of protocol overhead, shared links and source disk speed, and large data sets also need time for ongoing changes to be synchronized. For very large volumes, ask whether the provider offers offline transfer using shipped storage devices.

Plan the waves and the cutover

Group workloads into waves by dependency, risk and business timing. Systems that depend on each other usually move together. Write a cutover plan for each wave that names who does what, the exact steps, the test that proves success, and the point past which you will no longer roll back. Avoid scheduling cutovers during month-end, payroll or seasonal peaks.

1. Pilot. Move one or two low-risk, well-understood workloads to prove the landing zone, the tools and the team’s process.
2. Replicate. Copy servers and data to the cloud while the source keeps running, and test the copy in isolation.
3. Cut over. In the agreed window, stop writes at the source, complete the final synchronization, switch users and integrations, and run the acceptance tests.
4. Hold the source. Keep the original system, switched off or read-only, for a defined rollback period.
5. Learn. After each wave, record what went wrong and fix the process before the next wave.

Move the more critical workloads only after the team has proven the process on less critical ones.

Define success criteria before the move, not after. A workable set covers:

• Function. Users and integrations complete their key tasks.
• Performance. Response times match or beat the baseline you recorded.
• Security. Access controls, encryption and logging are in place and tested.
• Resilience. Backups run and a restore has actually been tested.
• Monitoring. Alerts reach the people who will act on them.
• Cost. Running cost is within the forecast.

Migration is not finished when the cutover succeeds. Decommission the source systems on schedule, since running both environments doubles cost. Right-size resources using real utilization data, and set up cost reporting. The cloud cost optimization guide sets out how. Update runbooks, train the support team on the new environment, and review disaster recovery against the new architecture.

• The business reason and the success measures are written down and agreed.
• Every workload has a strategy from the six options and a named owner.
• Dependencies and network flows are mapped.
• Licensing terms have been checked for cloud use.
• Data residency and privacy requirements are confirmed.
• The landing zone is built, tested and reviewed for security.
• Connectivity is in place with a second path.
• Each wave has a cutover plan, a rollback point and acceptance tests.
• Support staff are trained and runbooks are updated.

• Skipping discovery and finding dependencies during the cutover.
• Rehosting everything and expecting the costs to fall automatically.
• Building the landing zone after the first workloads have arrived.
• Leaving data transfer time and cost out of the plan.
• Cutting over without a tested rollback.
• Running the old and new environments side by side indefinitely.
• Treating the project as only technical and not preparing users.

• How do you discover dependencies, and will we see the dependency map before we commit to a plan?
• Who builds and owns the landing zone, and will we own the accounts and the configuration afterwards?
• How do you decide between rehosting and refactoring for a given workload, and will you show that reasoning?
• What is your rollback approach for each cutover, and how long is the source kept?
• How do you handle data residency and where do backups, logs and support access sit?
• What happens after migration, including cost reviews and handover to our team?

How long does a cloud migration take?

It depends on the number of workloads, how tangled their dependencies are, and how many need changes. A small environment of simple servers moves far faster than a large estate with custom applications, and the discovery phase gives you the first realistic estimate.

Is lift and shift a bad idea?

No. It is often the right first step when a deadline is fixed or an application cannot change. The risk is stopping there and expecting cloud economics, because rehosted systems carry their original sizing and design. Plan the optimization step.

How do we avoid downtime?

Replicate while the source stays live, keep the final cutover window short, and rehearse the cutover steps in advance. Some systems tolerate a planned outage and others need continuous replication, so ask each owner what an acceptable outage looks like.

Which cloud should we choose?

Choose against your requirements. Compare identity integration with your existing directory, the services your applications use, Canadian region availability, support, skills in your team and the commercial terms. Avoid choosing on a feature list alone.