Cloud Migration: The Benefits, the Challenges, and What Decides the Outcome

What cloud migration actually means

Cloud migration is the movement of applications, data and infrastructure from on-premises or hosted environments to cloud platforms. It's a very broad term and can cover a spectrum of ambition, from simply moving a VM across to the cloud to a complete re-architecting of an application around the use of managed services. The difference between those two scenarios is what ultimately determines whether or not the promised benefits are actually achieved.

The benefits that are genuinely real

• Elasticity. Capacity that follows demand rather than peak provisioning. That's where the vast majority of the real savings come from, and it only ever happens if the architecture is actually capable of scaling down.
• Speed of change. Provisioning in minutes rather than as part of a procurement cycle changes what the teams attempt. That's probably the biggest benefit and the one most difficult to put on a spreadsheet.
• Managed services. Databases, queues and pipelines are patched and run by someone else. The saving is in staff time as much as it is in licence cost.
• Access to specialised capability. GPU and accelerator capacity and managed AI services without any capital purchase required — which is precisely why AI programmes so frequently end up depending on migration.
• Resilience made attainable. Multi-region redundancy which would be impractical to build physically becomes a configuration decision.
• Geographic reach. Serving users from regions close to them without having any facilities there.

Note that the majority of these arise from using cloud services rather than from being in the cloud. That's the very reason lift and shift is so disappointing.

The challenges that decide outcomes

Cost control

The most common post-migration shock is a bigger bill. On-premises capacity is a sunk cost, so nobody counts an idle server at all; in the cloud, every idle resource is billed hourly. The reasons are always the same and all avoidable.

• Oversized instances. Provisioned to on-premises habits rather than to measured utilisation.
• Idle and forgotten resources. Development environments, orphaned volumes and endpoints that nobody ever switched off.
• Egress charges. Data leaving the platform is billed, and architectures that are constantly moving data between clouds or back on-premises accrue this quietly.
• No ownership of spend. When no team can see the cost of what they've provisioned, consumption goes up without anyone having actually decided that it should.
• Storage tiers unused. Keeping cold data in hot storage is a continual charge for access you never make.

Data gravity and sequencing

Large datasets are expensive and time-consuming to move, and applications naturally want to be close to their data. That's why big-bang migrations fail: an application in the cloud querying a database on-premises performs poorly and costs more than either arrangement alone. The sensible approach is to sequence by data domain rather than by application.

Compliance and residency

Where data may lawfully reside, who may access it and what must be demonstrable to an auditor are design constraints. These are vastly cheaper to design for than to retrofit and can in some cases completely rule out an otherwise very attractive architecture.

Skills and operating model

Cloud infrastructure is run differently, and a team that currently manages its servers manually will manage its cloud servers manually — just replicating the same practice at a higher cost. The practices that turn the migration into a benefit are infrastructure as code, automated deployment and cost ownership.

Why AI programmes make migration urgent

A pattern worth naming is that organisations get to their AI plans and discover that migration is the actual prerequisite. Modern AI services assume that the data is accessible, queryable and governed in the cloud.

• Training needs accessible data. Data locked in systems which can't be queried at volume cannot be used to train anything, regardless of its quality.
• Accelerator capacity is a cloud service. Access to GPU and other specialised hardware without any capital commitment is one of the clearest arguments for migration today.
• Managed AI services assume cloud data. The value of a managed platform depends on your data being accessible from it.
• Lineage and governance come along. A well-run migration is an opportunity to get the definitions and lineage right — the very foundations that determine whether or not analytics and AI are trusted.

Which is why we often find that the honest answer to 'where should we start with AI?' is a scoped migration and modernisation project for one data domain.

How to run a migration that works

1. Inventory honestly, including what you're going to retire. Every system, its dependencies, its data and its owner. The cheapest win available is simply retiring the things you don't need.
2. Sequence by data domain. Move the domain and the workloads that use it as a unit, so that nothing is left querying across the boundary for any length of time.
3. Pick a first workload that will teach you something. Something meaningful but not critical, and with a real owner. The objective is to establish a repeatable process, not to do a single relocation.
4. Establish cost ownership on day one. Tagging, budgets and alerts in place before any workloads arrive, as retrofitting attribution is a pain.
5. Define infrastructure as code from the outset. Manually configured cloud infrastructure simply reproduces on-premises practice at a higher cost.
6. Modernise selectively, not universally. Refactor where elasticity or managed services are actually going to deliver; rehost where they won't and come back to them later.
7. Measure against the pre-migration baseline. Cost, performance and reliability, all recorded before migration starts — you simply can't demonstrate the value of the programme without that.

How SoftmaxAI approaches migration

We build and migrate the way we always work. We have a written, client-approved specification prior to any code. We have an agent-accelerated build led by senior engineers. And every decision that matters is owned by a human.

• Sequenced by data gravity. We plan around where the data is and what depends on it rather than in application inventory order, as that's what stops us having to build expensive cross-boundary architectures.
• Cost modelled before the move. Realistic consumption modelling throughout the specification phase, with tagging and budget alerts in place before workloads actually land.
• Modernise where it pays. We refactor where elasticity or managed services make the effort worthwhile and we rehost where they don't — and we are absolutely clear which is which.
• Foundations fixed along the way. Definitions, lineage and access control are all dealt with as part of the migration process, because that's when the data is being touched anyway. See our cloud migration practice as a Google Cloud Partner.

Related reading: data science impact on business for what good foundations enable, and ML and AI services on GCP for what becomes available afterwards.