Cloud Migration and Infrastructure
Cloud migration is sold as a cost saving and frequently delivers the opposite, because workloads get moved as they are rather than assessed first. Some things belong in the cloud, some are cheaper where they are, and a few should be retired instead of migrated. We establish which is which before anything moves, then schedule the work around your reporting calendar rather than through it.
1
Assess
What should move at all
2
Model
Honest running cost
3
Design
Target architecture
4
Migrate
In waves, reversibly
5
Optimise
Tune once it is live
How We Deliver
01
Cloud Readiness Assessment
We inventory the estate and assess each workload separately. Applications with licensing tied to physical hardware, systems with latency sensitive local dependencies and platforms approaching end of life all warrant different decisions.
- Workload inventory with dependency mapping
- Suitability assessment per application
- Licensing implications of moving
- Identification of workloads to retire rather than migrate
02
Cost Modelling
Cloud cost is consumption based, which makes it easy to underestimate. We model the running cost against actual usage rather than nominal capacity, and include the items people forget: egress, backup storage, and the non production environments.
- Running cost modelled from actual utilisation
- Data egress and inter region transfer costs
- Backup, snapshot and archive storage
- Comparison against the true cost of staying put
03
Target Architecture Design
We design the destination before moving anything, covering environment separation, network design, identity and the backup arrangement. Access control designed after migration is access control that will produce an audit finding.
- Environment separation for development, test and production
- Network design and connectivity to remaining on premise systems
- Identity, access control and privileged access model
- Backup, retention and recovery arrangement
04
Phased Migration
Migration runs in waves, lowest risk first, with each wave verified before the next begins. Timing is planned around month end and year end rather than into them, and each wave keeps a defined rollback route.
- Wave plan sequenced by risk and dependency
- Scheduling around reporting and operational peaks
- Rollback route maintained per wave
- Verification and sign off before proceeding
05
Optimisation and Handover
Consumption based infrastructure sized on day one is almost always wrong by month three. We right size against observed usage, then hand over documentation and the cost monitoring your team needs.
- Right sizing against observed consumption
- Reserved capacity where usage is predictable
- Cost alerting and budget thresholds
- Documentation, runbooks and team handover
What You Receive
- Workload inventory with dependency mapping
- Suitability assessment and recommendation per workload
- Cost model comparing cloud against staying put
- Target architecture and access control design
- Wave based migration plan with rollback routes
- Post migration optimisation and cost monitoring
Indicative Timeline
Assessment and cost modelling take two to four weeks. Migration itself depends entirely on the estate, from a few weeks for a handful of workloads to several months for a full data centre exit delivered in waves.
- Readiness assessment and inventory: two weeks
- Cost modelling and business case: one to two weeks
- Architecture design and approval: two weeks
- Migration: delivered in waves around your calendar
What We Address
Migration is judged on cost, risk and auditability together, because improving one at the expense of the others is not a saving.
Workload Suitability
Whether each application benefits from moving, stays put, or should be retired instead.
Cost Transparency
Modelled running cost including the storage, transfer and non production items usually omitted.
Environment Separation
Development, test and production kept genuinely separate, which is a standing audit expectation.
Identity and Access
Access designed in rather than retrofitted, including privileged access and multi factor authentication.
Backup and Recovery
Recovery objectives agreed and configured, not inherited by accident from a provider default.
Exit Position
What it would take to leave, documented up front so the decision stays reversible.
Frequently Asked Questions
Will moving to the cloud save us money?
Sometimes, and not automatically. Lifting a workload unchanged usually costs more than the server it replaced. Savings come from right sizing, retiring what is unused and moving from capital to operating expenditure. The cost model tells you before you commit rather than after.
Is our data safe in the cloud?
The infrastructure is generally more secure than most on premise environments. The risk shifts to configuration: exposed storage, over privileged accounts and absent multi factor authentication. That is why access design happens before migration, not after.
Does POPIA allow us to host data offshore?
POPIA permits cross border transfer under specific conditions, including where the destination has comparable protection. Region selection is a design decision we raise at architecture stage, and the compliance position should be confirmed with your legal advisors.
What about systems that cannot move?
Hybrid is a legitimate destination rather than a failure. Some workloads stay on premise for licensing, latency or cost reasons, and the architecture covers connectivity between the two rather than pretending everything moved.
Can we reverse it if it does not work?
Each wave keeps a rollback route until it is verified. Longer term, we document the exit position up front so leaving remains a commercial decision instead of a technical impossibility.
Who manages it afterwards?
Your team, with the documentation and runbooks handed over, or ourselves under a managed arrangement quoted separately. Cost monitoring matters either way, because consumption billing punishes inattention.
Related Services
This sits inside our Systems Development practice. Related work: Managed ICT Services to run the environment afterwards, and Disaster Recovery and Continuity Review to verify recovery independently once migrated.
