| Cloud migration is the process of moving business systems, data, and applications from on-premises servers (or older cloud platforms) to modern cloud services. Done well, it reduces hardware overhead, improves scalability, and gives the business stronger security and faster access to new capabilities. |
Almost every NZ business now runs at least some workloads in the cloud, but a true migration is bigger than turning on Microsoft 365 or signing up for a single SaaS tool. It means deliberately moving the systems the business depends on from a server cupboard or ageing data centre into a cloud platform built for the way teams work today.
Done well, a cloud migration removes years of accumulated maintenance burden, sharpens security, and frees the business to grow without buying more hardware. Done badly, it drags on for months, blows budgets, and quietly recreates all the old problems on new infrastructure.
This blog covers what cloud migration actually means, the four main migration approaches, a practical checklist for getting it right, and the risks worth managing along the way. It is written for owners and managers making the decision, not for technical teams handling the implementation.
What Is Cloud Migration and Why Do It?
Cloud migration is the structured move of business systems away from on-premises infrastructure and toward services hosted in the cloud. Businesses do it to reduce capital spending on hardware, gain flexibility to scale, improve resilience, and access modern features that simply do not exist on legacy platforms.
The reasons sound abstract until you live them. A business migrating off ageing physical servers stops having to plan for the next hardware refresh. A business migrating off an unsupported operating system stops carrying compliance and security risk. A business migrating into Microsoft 365 or Google Workspace stops having to maintain its own mail server. Each step removes a quiet drag on the business.
What does cloud migration actually involve?
At a practical level, a cloud migration involves picking the right cloud platform, planning how each workload will move, preparing the data and applications, running pilots, executing the cutover, validating that everything works, and decommissioning the old environment. The technical work matters less than the planning. Most failed cloud migrations were under-planned long before anyone touched a server.
Why are NZ businesses moving to the cloud now?
Four forces are pushing the move at the same time: ageing on-premises hardware reaching end of life, hybrid working making remote access non-negotiable, security threats outpacing what older infrastructure can defend against, and the cost-benefit of cloud platforms having shifted significantly in the last five years. Most NZ SMEs hit at least two of these triggers within any three-year period.
The Four Main Types of Cloud Migration
Not every workload moves to the cloud the same way. The four standard approaches (sometimes called the “four Rs”) are rehost, re-platform, refactor, and repurchase. Knowing which one applies to each system in your environment is one of the single biggest predictors of a smooth migration.
Rehost (lift and shift)
Rehosting takes an existing application and moves it as-is to a cloud equivalent of its current environment. It is the fastest approach because the application stays essentially unchanged. The drawback is that you carry across any inefficiency or technical debt the application had on premises. Rehosting suits applications that work fine today and just need a new home.
Re-platform
Re-platforming moves the application to the cloud and updates parts of it to use cloud-native services along the way, like switching to a managed database instead of running one yourself. It takes longer than rehosting but produces meaningfully better operational outcomes. This middle path suits applications that have a few years of life left and benefit from modest modernisation.
Refactor (re-architect)
Refactoring rebuilds the application to take full advantage of cloud-native architecture. It is the most expensive approach but produces the strongest long-term result. Refactoring suits applications that are strategic to the business, expected to grow significantly, or where the current architecture is genuinely holding the business back.
Repurchase (SaaS swap)
Repurchasing replaces an on-premises application with an equivalent SaaS product, like swapping a hosted CRM for HubSpot or Salesforce. It is often the right move for commodity functions where modern SaaS products meet the need without the maintenance burden. The migration becomes a data migration and process change rather than a technical rebuild.
The Practical Cloud Migration Checklist
A successful cloud migration follows six phases: assess, plan, prepare, pilot, execute, and optimise. Working through them in order, with proper sign-off at each stage, is the difference between a smooth project and one that drags on for months while costs creep up.
Phase 1: Assess your current environment
Document every server, application, database, integration, and data store the business currently relies on. Note ownership, criticality, dependencies, and current pain points. Most NZ businesses doing this audit for the first time discover applications nobody is sure are still in use, plus a couple of integrations that exist only in someone’s head. Both need attention before any migration plan is meaningful.
A formal Cybersecurity Risk Assessment at this stage also surfaces security weaknesses in the current environment that might otherwise migrate across unchanged, and gives the new cloud setup a clean baseline to build from.
Phase 2: Plan and choose the right cloud platform
Decide which workloads will move, which approach each will use (rehost, re-platform, refactor, repurchase), and which cloud platform fits. For most NZ SMEs the choice is between Microsoft Azure, AWS, and Google Cloud, plus SaaS platforms like Microsoft 365 and Google Workspace for productivity. Cost, existing skill base, vendor relationships, and integration with current tools all play into the decision.
Phase 3: Prepare data, applications, and people
Clean up data before moving it, not after. Removing duplicates, tidying file permissions, archiving things nobody uses, and standardising naming conventions are all easier to do in the existing environment than in the new one. People preparation matters too: identify who will own each system after the move, who needs new training, and what processes will change.
Phase 4: Pilot with a non-critical workload
Pick one or two non-critical applications and run the full cloud migration cycle on them first. The pilot exposes the things your plan got wrong, the integrations that did not work as expected, and the assumptions that turned out to be incorrect. Better to learn these on a low-stakes workload than on the system that runs payroll.
Phase 5: Execute the migration in phases
Migrate the wider environment in waves rather than all at once. Each wave should deliver a complete, working result. Avoid running half-migrated environments for extended periods because they create operational confusion, double-billing during transition, and security gaps. Each cutover happens in a planned window, usually outside business hours, with clear rollback procedures in case something needs to revert.
Phase 6: Optimise and decommission
Once everything has moved, watch the new environment for at least a quarter. Right-size cloud resources (cloud bills almost always start higher than necessary because nobody trims them during the rush), tighten security policies, and confirm performance is meeting expectations. Then decommission the old environment so it is no longer drawing power, software licences, or attention.
Common Risks in Cloud Migration and How to Manage Them
Cloud migration risks fall into four predictable buckets: data loss during transfer, application compatibility surprises, cost overruns, and security gaps during transition. All four are manageable with proper planning and none of them should derail a well-prepared project.
Data loss during transfer
Bulk data movement is where many cloud migrations quietly slip. Files can be corrupted in transit, permissions can be stripped, metadata can be lost, and edge cases nobody documented can surface in unhelpful ways. Mitigate this by running checksums on transferred data, doing test restores from your post-migration backups, and keeping the source data intact until the new environment has been operating cleanly for at least a month.
Application compatibility surprises
Applications that ran fine on-premises sometimes behave differently in the cloud. License servers may not work, hardcoded paths can break, integrations with legacy systems can fail, and performance characteristics can shift. The pilot phase catches most of these. Skipping the pilot turns these surprises into incidents in production.
Cost overruns and surprise bills
Cloud billing is consumption-based, which means a poorly sized deployment can produce dramatically higher costs than planned. Common causes are oversized virtual machines, storage tiers chosen on autopilot, network egress traffic that nobody anticipated, and forgotten services that run quietly in the background. Build cost monitoring into the migration plan from day one, not as an afterthought.
Security gaps during transition
Running two environments side-by-side during a cloud migration creates a temporary expansion of the attack surface. Old systems may be loosely monitored, new systems may not yet have full controls in place, and access permissions are easier to get wrong during change. A defence-in-depth approach during the transition window reduces this risk significantly.
The Defence in Depth principles apply just as strongly during migration as they do in steady state, and arguably matter more during the months when the environment is in flux.
After the Migration: What Actually Changes
A successful cloud migration changes how the business operates in three meaningful ways: the IT team’s daily rhythm shifts, cost monitoring becomes essential rather than optional, and security and governance need ongoing attention rather than periodic check-ins. None of these are bad, but they are different from running an on-premises environment.
New operational rhythms
Instead of patching servers and replacing failed disks, the operations team monitors dashboards, manages identity, watches cost telemetry, and tunes cloud services. The work is more strategic and less reactive, which is positive, but it does require people to learn new tools and habits. Budget for training, not just for the technical move.
Cost monitoring becomes essential
On-premises infrastructure costs were predictable: you bought the gear, you knew what it would cost. Cloud costs vary with usage and can drift up quietly. Set budgets and alerts during the migration, review them monthly, and assign a clear owner. Without this discipline, savings predicted in the business case have a habit of disappearing within twelve months.
Security and governance shift toward continuous
Cloud platforms surface much richer telemetry than on-premises systems, which is good, but only useful if someone is watching it. Resilience also has to be designed in rather than assumed, since the cloud provider is responsible for the infrastructure but the business is responsible for how it is used.
Building Cyber Resilience into the post-migration operating model from the start avoids the common pattern where new environments inherit old, complacent habits.
Plan Your Cloud Migration With Confidence
Cloud migration is one of the larger technology investments a business makes, and the planning matters more than the technology choices. Exodesk works with businesses across Christchurch, Dunedin, and the South Island to scope migrations, choose the right platforms, prepare environments properly, and deliver the work in phases that protect day-to-day operations.
Our Cloud Solutions team covers everything from initial assessment through to post-migration optimisation and ongoing managed support.
Contact us today to discuss how we can help your business or connect with us on LinkedIn to stay updated with more insights.
Frequently Asked Questions
What is cloud migration in simple terms?
Cloud migration is the process of moving business systems, applications, and data from on-premises servers or older platforms to cloud services. It can range from a simple lift-and-shift of one application through to a full re-architecture of the entire IT environment. The goal is usually to reduce hardware overhead, improve flexibility, and access modern capabilities.
What are the different types of cloud migration?
The four standard approaches are rehost (lift and shift to the cloud unchanged), re-platform (light modernisation during the move), refactor (rebuild for the cloud), and repurchase (replace with a SaaS product). Most real migration projects use a mix of these depending on the workload, with rehost being the most common starting point for legacy applications.
How much does cloud migration cost?
Costs vary significantly with the size of the environment, the migration approach chosen, and the cloud platform. Vendor pricing is set by the cloud providers and changes regularly, so meaningful figures only come from a scoped assessment based on your actual workloads. A reputable IT partner can produce a clear budget after a discovery and assessment phase.
How long does cloud migration take?
A small business migrating a single application can complete in four to eight weeks. A full business-wide migration covering multiple systems, integrations, and user training typically runs four to nine months for an NZ SME. Larger or more complex organisations take longer. The assessment and planning phases tend to be faster than expected; the application and data migration phases tend to be slower than expected.
What are the biggest risks in cloud migration?
The four main risks are data loss during transfer, application compatibility surprises, cost overruns from cloud consumption, and security gaps during the transition window when two environments run side-by-side. All four are well understood and manageable with proper planning, a pilot phase, and clear ownership of each phase of the migration.
Which cloud platform should I choose for migration?
The right choice depends on your existing skills, current tools, and what each workload needs. Microsoft Azure suits businesses already standardised on Microsoft 365 and Windows environments. AWS suits broader workloads with a wide ecosystem of services. Google Cloud suits data-heavy and analytics use cases. Many NZ SMEs end up with a primary platform plus a few SaaS products for specific functions, which is a perfectly sensible outcome.
Will cloud migration cause business downtime?
A well-planned migration causes minimal user-visible downtime. Cutovers are scheduled outside business hours, run-in-parallel approaches let new systems be validated before old ones are decommissioned, and rollback plans handle anything that goes wrong on the day. Poorly planned migrations can cause extended outages, which is usually a sign that the assessment and pilot phases were skipped or rushed.
Can we move back from the cloud if it does not work?
Yes, though it is rarely worth doing. Reverse migrations (sometimes called cloud repatriation) are technically possible but usually expensive and disruptive. The right answer when a cloud migration is not delivering the expected value is normally to diagnose the specific issue (cost, performance, application fit) and fix it within the cloud environment rather than reversing the move entirely.
What skills do we need for a cloud migration?
You need project management, cloud architecture, application knowledge, data migration expertise, security skills, and change management. Most NZ SMEs do not have all of these in-house and engage an IT partner to bring the missing skills for the duration of the project. The internal team typically focuses on application knowledge and business context, while the partner handles the cloud-specific technical work.
How do we actually start a cloud migration?
Start with a discovery and assessment phase before making any platform or vendor commitments. The assessment identifies what is in your current environment, what should move, what approach suits each workload, and what the realistic timeline and cost look like. Only with that picture in hand can you make informed decisions about which cloud platform to use and how to phase the work.
