Cloud Migration Services
Move workloads with a controlled dependency and recovery plan.
Assess, prepare, migrate and validate enterprise workloads without reducing migration to a hosting exercise.
Discuss this requirement →Start with the environment, risk and required outcome.
Assess, prepare, migrate and validate enterprise workloads without reducing migration to a hosting exercise. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
The six cloud migration approaches
Every workload gets one of these. Choosing at the estate level rather than per workload is the most common and most expensive planning error.
| Approach | What happens | Effort | When it fits |
|---|---|---|---|
| Rehost | Lift and shift the virtual machine as it is | Low | Time pressure, a data centre exit or a workload with no appetite for change |
| Replatform | Move it and change one thing, usually the database to a managed service | Low to medium | Where a managed service removes real operational burden |
| Refactor | Rework the application for cloud-native services | High | Where the application is strategic and the current architecture constrains it |
| Repurchase | Replace it with a SaaS product | Medium | Commodity functions: email, CRM, HR, service desk |
| Retire | Switch it off | Low | Genuinely more common than expected once someone asks who uses it |
| Retain | Leave it where it is | None | Licensing, latency, regulation or no functional reason to move |
Retire and retain deserve more attention than they get. A cloud migration assessment that recommends moving every workload has not been done properly. In most estates a handful of systems turn out to have no current users, and several more have a good reason to stay.
Rehost is not a failure. Lift and shift gets criticised for delivering cloud costs without cloud benefits, and that criticism holds where the migration stops there. As a first step in a staged move, with optimisation following once the workload is stable and measurable, it is a sound approach and it lowers project risk considerably.
Assessing a workload for cloud migration
Six questions per workload. A server to cloud migration decision that skips these is a guess with a project plan attached.
Residency and regulation
Personal information or regulated data sets the region before anything else. This is where South African cloud migration differs from the generic version and it is dealt with in its own section below.
Demand profile
Variable and unpredictable demand is where cloud economics work. Steady, high-utilisation workloads are frequently cheaper on owned hardware over three to five years.
Licensing
Some licence models behave very differently on cloud infrastructure, particularly core-based database licensing. This is the factor most often missed and it can move the cost substantially in either direction. Establish it before the business case, not after.
Latency and data movement
Applications with heavy client-server interaction, or that move large volumes of data, carry latency and egress costs that an architecture diagram does not reveal.
Dependencies
A workload with dependencies on on-premises systems does not move cleanly alone. Moving it in isolation produces a hybrid arrangement nobody designed, with traffic crossing the boundary constantly.
Functional reason
If a stable application on serviceable hardware has no functional reason to move, moving it spends money and adds risk for nothing.
Cloud migration in South Africa
Three local factors shape the plan.
Regions
AWS operates the Africa (Cape Town) region. Azure operates South Africa North in Johannesburg and South Africa West in Cape Town. In-country hosting gives better latency for South African users and a simpler residency position. Local region pricing generally sits above the largest global regions, so where a workload has no residency or latency constraint, the difference is worth weighing.
POPIA
Transfers of personal information outside South Africa are restricted unless specific conditions are met. Hosting locally removes the question for data that stays there, and it is not automatic, because backups, logging and managed-service control planes can still move data offshore. Any cloud migration involving personal information should map where data actually ends up rather than assuming the region setting covers it.
Bandwidth for the migration itself
Moving several terabytes over a business internet connection takes days and consumes the connection while it runs. Options are a dedicated migration window, a temporary uplift, a direct connect service or physical data transfer appliances. This is routinely underestimated and it is usually the item that moves the schedule.
AWS migration and Azure migration
The platform choice is usually settled by the existing licensing position and the team’s familiarity rather than by capability, because both handle mainstream workloads well.
Azure migration tends to suit Windows-dominant estates. Hybrid identity carries across cleanly through directory synchronisation, existing Windows Server and SQL Server licensing can bring cost benefits under hybrid use rights, and management tooling is familiar to teams already running Microsoft infrastructure. Two in-country regions also gives a genuine local pairing option for resilience.
AWS migration offers a broader service catalogue and a longer track record in several areas. For estates that are Linux-weighted, application-led or already running something on AWS, it is the natural direction.
We work with both. Where an organisation has no existing position, we make a recommendation with the reasoning written down rather than defaulting to one.
How a migration runs
1. Discovery and assessment
Full workload inventory with dependencies mapped, utilisation measured rather than estimated, licensing position established and an approach recommended per workload. Output is a written migration plan with a cost model and an explicit retain and retire list.
2. Landing zone
Account and subscription structure, identity, network topology, security baseline, logging and policy guardrails, built before anything moves. Migrating into an unstructured environment creates a cleanup project that costs more than doing it in order.
3. Pilot
One low-risk workload group, migrated end to end including cutover and rollback. This is where the plan meets reality and where the estimates get corrected.
4. Wave migration
Workload groups moved in dependency order, each with a defined cutover window, a verification checklist and a fallback. Systems that depend on each other move together.
5. Optimisation
Right-sizing from observed use, commitment purchasing, storage tiering and architecture refinement. This happens after workloads are stable and measurable, not during the move.
6. Decommission
The old environment switched off, licences reclaimed, hardware disposed of. This step gets deferred and forgotten, and running both environments in parallel indefinitely is a common and expensive outcome.
What goes wrong
No fallback. A cutover with no way back is a decision made once, under pressure, with incomplete information. Every wave should be reversible until it is verified.
Dependencies discovered during cutover. The licence server, the scheduled task on a workstation, the integration through a service account nobody owns. Discovery finds these. Skipping discovery finds them at 02:00 on a Sunday.
Cost modelled on list price and steady state. Real bills include data transfer, storage tiers, backup, support plans and the period when both environments run in parallel. Model that period explicitly, because it is not free.
Optimisation never happens. Workloads land at the size they were on premises, sized for a peak estimated years ago, and stay there. Without a scheduled optimisation phase the cloud bill reflects an on-premises sizing decision indefinitely.
Nobody owns the bill afterwards. Covered on cloud managed services. Without tagging and attribution, spend cannot be assigned to a team or project and nobody manages a number they cannot see.
What Namandla delivers
Cloud migration assessment. Workload inventory, dependency mapping, utilisation measurement, licensing analysis, approach recommendation per workload and a cost model including the parallel-running period.
Landing zone design and build on AWS or Azure.
Migration execution. Pilot, waves, cutover, verification and fallback at every stage.
Data migration, including the bandwidth and transfer method decision.
Optimisation after stabilisation: right-sizing, commitments, storage tiering.
Decommission of the source environment, with licence reclamation.
Managed operation afterwards, or handover to your team with documentation, whichever you prefer.
Remote delivery nationally. Onsite in Gauteng for discovery, cutover support and decommission.
Common questions about Cloud Migration
How long does a cloud migration take?
For a mid-market estate, three to nine months end to end. Discovery and assessment is three to six weeks, landing zone two to four weeks, then waves at roughly two to four weeks each depending on complexity.
The variables that move the timeline are dependency complexity, how much bandwidth is available for data transfer and how many cutover windows the business will tolerate. Estates with clean dependencies and generous windows move quickly. Estates with a tangled application landscape and one permitted window a month do not.
What does a cloud migration cost?
Two separate numbers: the migration project and the ongoing run cost. Both should be modelled before you commit, and the second one matters more over any reasonable horizon.
The costs most often missed are the parallel-running period when both environments are live, data transfer during migration and the fact that workloads landing at their on-premises sizing cost more than optimised ones. We model all three explicitly rather than presenting a steady-state figure that arrives eighteen months later.
Should we lift and shift or refactor?
Per workload. Rehost for speed and lower risk, replatform where a managed service removes real operational burden, refactor only where the application is strategic and its current architecture genuinely constrains it.
Refactoring everything is how migrations become multi-year programmes that get cancelled. Rehosting everything and stopping there is how organisations end up with cloud costs and no cloud benefits. The workable pattern for most estates is rehost or replatform the majority, refactor a small number deliberately, and schedule optimisation as a follow-on phase.
Can we migrate to a South African cloud region?
Yes. AWS operates the Africa (Cape Town) region and Azure operates South Africa North in Johannesburg and South Africa West in Cape Town.
In-country hosting gives better latency for South African users and simplifies the POPIA residency position. Local region pricing generally sits above the largest global regions and the service catalogue is narrower, so check that the specific services your architecture needs are available locally before committing to a cloud migration into a South African region.
What about our data during migration?
Bandwidth is usually the constraint. Several terabytes over a business internet connection takes days and consumes the link while it runs.
The options are a dedicated migration window, a temporary bandwidth uplift, a direct connect service to the provider, or physical data transfer appliances for very large volumes. This is the item most often underestimated and it is frequently what sets the schedule, so it gets established during assessment rather than discovered during the first wave.
What happens if a migration wave fails?
You roll back to the source environment, which is still running and still current because we do not decommission until a wave is verified.
Every wave has a defined fallback, a verification checklist and a decision point. That is what makes cutover low risk. A cutover with no way back is a single irreversible decision taken under time pressure, and it is how migrations acquire their reputation.
Will our applications work the same in the cloud?
Mostly, and the differences that bite are latency-related. An application designed for a local network that makes many small round trips will feel slower across a wider path, even where raw bandwidth is ample.
That is why the assessment measures how chatty an application is rather than only its resource use. Where an application is latency-sensitive, the answer is either an in-country region, keeping it on premises or reworking the interaction pattern, and knowing which before you migrate is considerably cheaper than after.
Do we need to migrate everything at once?
No, and you should not. Wave migration by dependency group, with verification between waves, is lower risk and it lets the estimates correct themselves as you go.
A hybrid state during migration is normal and it needs designing rather than tolerating: identity spanning both environments, connectivity between them and consistent management. Covered on hybrid cloud. Some organisations discover during the process that the hybrid state suits them and stop deliberately, which is a legitimate outcome.
What should we not migrate?
Latency-sensitive production systems, anything with a licence model that penalises virtual cores or cloud infrastructure, workloads with hard residency constraints that cannot be met, and stable applications on hardware with life left in it.
We produce an explicit retain list as part of the assessment, with the reasoning for each. A cloud migration plan that moves everything is a plan that has not looked closely. Telling you which of your systems should stay is part of the work rather than a failure to sell the project.