Cloud migration planning: avoiding the most common pitfalls

Cloud migration is one of the most significant infrastructure projects a South African business will undertake. When it goes well, the organisation gains flexibility, scalability, and a modern platform for growth. When it goes badly - and it goes badly more often than the industry likes to admit - the business ends up with higher costs, worse performance, and a demoralised IT team.

The good news is that migration failures follow predictable patterns. Understanding these patterns before you start puts you in a far stronger position to avoid them.

The most common migration mistakes

1. Lifting and shifting everything

The “lift and shift” approach - moving applications as-is from on-premises servers to cloud virtual machines - is tempting because it is the simplest path. But it often results in the worst outcome: you are paying cloud prices for workloads architected for on-premises infrastructure, without benefiting from cloud-native capabilities.

A server that was oversized on-premises becomes an oversized (and expensive) VM in the cloud. An application that relied on local storage latency may perform poorly on network-attached cloud storage. A monolithic application that should have been modernised or replaced gets a new address but the same old problems.

Lift and shift has its place - for stable, low-complexity workloads that genuinely do not need rearchitecting - but it should be a deliberate choice, not the default for everything.

2. Ignoring security from the start

On-premises environments benefit from implicit security assumptions - physical perimeter, trusted networks, controlled access. The cloud operates on a shared responsibility model where the provider secures the infrastructure, but you are responsible for everything you deploy on it.

Organisations that defer security planning until after migration routinely discover misconfigured storage buckets, overly permissive network rules, exposed management interfaces, and inadequate identity controls. These gaps are often exploited within days of deployment.

Build security into your migration plan from day one. Engage your cybersecurity and security operations team in the architecture review, not as an afterthought.

3. No rollback plan

Migrations rarely go perfectly on the first attempt. Applications behave differently in the cloud, dependencies surface that were not documented, and performance characteristics change. Without a rollback plan, you are committed to making the cloud deployment work under pressure, often with users unable to work.

For every application you migrate, define:

How you will verify success (acceptance criteria)
How long you will run in parallel before decommissioning the on-premises system
How you will roll back if the cloud deployment does not meet criteria
Who authorises the rollback decision

4. Underestimating bandwidth requirements

Moving terabytes of data to the cloud takes time - and it takes bandwidth. A business with a 100 Mbps internet connection trying to migrate 10 TB of data will need roughly 10 days of continuous transfer, assuming the link is doing nothing else.

Plan your data migration separately from your application migration. Consider:

Dedicated migration links or temporary bandwidth upgrades
Physical data transfer appliances (Azure Data Box, AWS Snowball) for very large datasets
Staged migration with synchronisation to minimise cutover downtime
Off-peak transfer windows to avoid impacting business operations

Your network engineering team should model the bandwidth requirements and validate that the migration timeline is realistic.

5. Forgetting about training and change management

Technology teams need new skills for cloud operations - infrastructure-as-code, cloud-native monitoring, cost management, and provider-specific tooling. End users may need to adapt to new access patterns, authentication methods, or application interfaces.

Organisations that neglect training end up with a cloud environment managed using on-premises habits, which leads to inefficiency, misconfigurations, and frustration.

Budget for training from the start. Identify skill gaps, invest in certifications, and pair less experienced team members with those who have cloud expertise.

6. No clear business case

“Everyone else is doing it” is not a migration strategy. Without a clear understanding of what you expect the cloud to deliver - cost savings, scalability, disaster recovery, speed to market, compliance - you cannot measure success or make informed trade-offs during the project.

Define your objectives before you start. They will guide every decision from provider selection to workload prioritisation.

The 6 Rs of migration

AWS popularised the “6 Rs” framework, and it remains the most practical way to categorise workloads and decide how each should be handled.

Rehost (lift and shift)

Move the application as-is to a cloud VM. Minimal effort, minimal cloud benefit. Appropriate for stable workloads that will eventually be retired or that genuinely do not need modification.

Replatform (lift and reshape)

Make minor adjustments to take advantage of cloud services without rearchitecting the application. Examples: moving a database from a self-managed VM to a managed database service (Azure SQL, Amazon RDS), or replacing local file storage with object storage (Azure Blob, S3).

This is often the sweet spot - meaningful improvement with moderate effort.

Repurchase (drop and shop)

Replace the application with a SaaS alternative. If you are running an on-premises CRM, ERP, or email server, a cloud-native SaaS product may be a better option than migrating the existing application. Evaluate total cost of ownership, including licensing, integration, and ongoing management.

Refactor (rearchitect)

Redesign the application to be cloud-native - using containers, serverless, microservices, and managed services. This delivers the greatest cloud benefit but requires the most effort and skill. Reserve this for strategic applications where the investment is justified by business value.

Retire

Some applications are no longer needed. A migration project is an excellent opportunity to decommission legacy systems, consolidate overlapping tools, and reduce your portfolio. Every application you retire is one you do not have to migrate, manage, or secure.

Retain (do nothing, for now)

Some workloads are best left on-premises - because of latency requirements, regulatory constraints, cost (some workloads are genuinely cheaper on-premises), or because they are scheduled for decommission. Retaining a workload is a valid strategic decision, not a failure.

A practical planning framework

Phase 1: Discovery and assessment

Before you migrate anything, understand what you have and what it will take to move.

Actions:

Application inventory. Catalogue every application, its dependencies, owners, usage patterns, and business criticality.
Infrastructure audit. Document servers, storage, network topology, bandwidth, and utilisation. Your infrastructure team should lead this effort.
Dependency mapping. Identify which applications talk to which databases, which services depend on specific network paths, and where shared resources exist. Undocumented dependencies are the number one cause of migration failures.
Classify each workload using the 6 Rs framework. Involve application owners - they know their systems better than anyone.
Cost modelling. Use provider pricing calculators to estimate monthly costs for each workload in its target configuration. Compare against current on-premises costs, including hardware refresh projections.
Risk assessment. Identify workloads with high migration risk (complex dependencies, poor documentation, legacy technology) and plan accordingly.

Phase 2: Foundation and landing zone

Build your cloud environment before migrating workloads into it. This “landing zone” includes:

Account or subscription structure aligned with your organisational and billing needs
Identity and access management - federate with your existing directory, enforce multi-factor authentication, define role-based access
Network architecture - virtual networks, subnets, DNS, connectivity back to on-premises (VPN or ExpressRoute/Direct Connect), firewall rules
Security baselines - logging, monitoring, encryption, security policies
Governance - tagging policies, cost management, change control

A well-designed landing zone, built with cloud architecture and engineering best practices, prevents the sprawl and security gaps that plague poorly planned migrations.

Phase 3: Pilot migration

Start with a low-risk, low-complexity workload. The pilot is not just about moving an application - it is about validating your migration process, tooling, connectivity, and team readiness.

Choose a pilot that is:

Non-critical (minimal business impact if something goes wrong)
Representative (similar enough to other workloads that lessons learned apply broadly)
Well-documented (you know its dependencies and expected behaviour)

Run the pilot through the full process: pre-migration testing, migration execution, post-migration validation, performance verification, and user acceptance. Document everything. Refine your runbook based on the experience.

Phase 4: Migration waves

Group remaining workloads into waves based on priority, complexity, and dependencies. Migrate in a controlled cadence - typically one wave per two to four weeks, depending on your team’s capacity.

For each wave:

Pre-migration checks - backups verified, rollback plan confirmed, stakeholders notified
Migration execution - following the documented runbook
Post-migration validation - functional testing, performance testing, security verification
Parallel running period - both environments active until the cloud deployment is confirmed stable
Cutover - DNS changes, traffic redirection, user notification
Decommission - remove on-premises resources once the retention period passes

Phase 5: Optimisation

Migration is not the finish line. Once workloads are in the cloud, optimise them:

Rightsize resources based on actual utilisation data (not the initial estimates)
Implement reserved instances or savings plans for steady-state workloads
Enable auto-scaling for variable workloads
Review architecture for opportunities to replatform or refactor
Establish ongoing cost management practices

Assessment checklist

Use this checklist to evaluate your migration readiness:

Start your migration on solid ground

A well-planned migration takes longer to start but finishes faster, costs less, and delivers the results the business expected. The organisations that stumble are almost always the ones that rushed the planning.

Contact us to discuss your migration objectives. We will help you assess your environment, build a practical migration plan, and execute it with the rigour and expertise your business deserves.