Most cloud migrations fail not on technology but on assumptions — that lift-and-shift is cheap, that latency to a distant region won't matter, that a regulator will accept a data-residency arrangement it hasn't been asked about. We plan the move against the actual workload, the actual dependencies, and the actual rules the business operates under, then execute in waves that keep the lights on.
What it does
We take on-premises and co-located estates — Windows and Linux VMs, Oracle and SQL Server databases, WebLogic and JBoss application servers, file shares, batch job schedulers, legacy .NET and Java stacks — and move them to AWS, Azure or GCP. The move is planned against the six Rs (retire, retain, rehost, replatform, repurchase, refactor) applied per workload, not per estate. A quiet reporting server that will be decommissioned next year is retired; a heavily-used core system with a licensing cliff is replatformed; a bespoke customer-facing app that needs elastic scale is refactored.
For BFSI clients, the plan is written to be shown to a regulator. RBI's storage-of-payment-system-data directive, IRDAI's outsourcing and cloud guidelines, CBK's guidance notes on ICT risk, IRA's data localisation posture, FCA's outsourcing and third-party risk expectations, and NAICOM's operational guidelines all shape which workloads can go where, which regions are acceptable, and what evidence the CISO will need at audit.
Discovery and the six Rs
Before we write a runbook, we build a workload inventory that a CIO can defend. Agent-based and agentless discovery (Azure Migrate, AWS Application Discovery Service, GCP Migration Center, or CloudPhysics / RVTools where those aren't a fit) gives us the raw catalogue — hostnames, CPU and memory utilisation curves over a working month, disk IO, network in/out, running services, listening ports. On top of that we run dependency mapping so we know which chatty pair of servers must move together, which batch job reads from a file share that nobody documented, which integration touches a partner network over a fixed IP.
Each workload then gets a six-Rs classification with a written rationale and a rough cost envelope. Retire and retain are as important as the other four — the cheapest migration is the one you didn't do. Rehost is honest lift-and-shift for workloads that will be replaced later or where the licence terms make replatforming pointless. Replatform is the sweet spot for most Oracle-to-managed-Postgres, SQL-Server-to-Azure-SQL-MI, and IIS-to-App-Service moves. Repurchase is the SaaS conversation — sometimes the right answer for CRM, HRMS, ITSM or email is to stop hosting it, and our CRM & ERP implementation practice picks that thread up. Refactor is reserved for workloads where the business case pays for the engineering — usually customer-facing apps that need elasticity, event-driven pipelines, or a monolith that has become the bottleneck.
Regulator-aware data movement
Data is where migrations get expensive and where compliance gets nervous. We separate the plan into cold bulk (databases, file shares, object stores that can be seeded once) and warm delta (transactions and changes that must be caught up at cutover). Cold data moves over AWS Snowball / Azure Data Box / GCP Transfer Appliance where volumes justify it, or over Direct Connect / ExpressRoute / Interconnect where the pipe exists. Warm delta uses native replication — Oracle Data Guard, SQL Server AlwaysOn, Postgres logical replication, MySQL GTID — or DMS / Database Migration Service where the source and target diverge.
For regulated workloads the data movement plan is written with region, encryption, key ownership and evidence in mind. KMS with customer-managed keys, HSM-backed key stores where the regulator asks for it, TLS in transit, immutable audit logging of every bulk transfer, and a documented chain of custody for physical appliances. Where data must remain in-country — India, Kenya, Nigeria, Saudi Arabia, UAE — we design landing zones in the local region and constrain replication targets accordingly.
Landing zone and cutover
The target environment isn't a blank subscription. We stand up a landing zone before the first workload moves — organisation and account structure, network topology with hub-and-spoke or transit gateway, private connectivity back to on-prem and to partner networks, identity federation with the existing directory, guardrails via SCPs / Azure Policy / Organization Policies, centralised logging into a security account, and cost controls with budgets and tag enforcement.
Cutover is rehearsed. Every wave has a runbook with pre-checks, freeze windows, cutover steps, validation queries, business sign-off checkpoints and a rollback that has been tested — not just documented. For core systems the first cutover is a dress rehearsal into an isolated environment; production cutover only happens once the rehearsal has run clean end-to-end. Application, database and integration teams are all on the bridge, and the business owner signs off on functional validation before we release the change.
Beyond cutover
A workload that runs in the cloud the way it ran on-prem is a workload that costs more than it should. After cutover we right-size against real utilisation, move steady-state compute onto savings plans or reserved instances, shift storage tiers, and turn on the platform services the customer paid for — managed backups, native monitoring, autoscaling, patching windows. Where we've refactored, the CI/CD pipeline and observability stack land alongside the workload so the platform team can operate it without a runbook printout.
Migration is where our cloud and DevOps practice usually starts a customer relationship, and it rarely ends there. FinOps reviews, DR posture, container adoption, and application modernisation are the natural next conversations. See /case-studies for examples across banking, insurance and enterprise IT, or reach us on /contact to talk through your estate.
