Unlocking Cloud Migration

Dependencies are where migrations fail — the application nobody mentioned that turns out to feed the finance system.

What cloud migration is, and what it saves

Cloud migration means moving applications, data and workloads off on-premises infrastructure and onto cloud platforms. The headline benefit is usually cost: savings of 15–40% on infrastructure, and for some organisations more.

That range is wide for a reason. The saving depends almost entirely on how the migration is done — a workload lifted unchanged onto cloud infrastructure saves at the lower end, and sometimes costs more than it did before.

The last is where most of the long-term value sits, and it is the one that a straight lift-and-shift forgoes entirely.

The advantages beyond cost

• Elasticity, so capacity matches demand instead of peak
• Resilience and recovery that would be prohibitive to build yourself
• Security patching and compliance handled at platform level
• Speed, because provisioning an environment stops being a procurement exercise
• Access to managed services — analytics, AI, integration — without running them

The last is where most of the long-term value sits, and it is the one that a straight lift-and-shift forgoes entirely.

Choosing a strategy

The standard options, in rising order of effort and reward:

• Rehost ("lift and shift") — fastest, lowest risk, smallest saving
• Replatform — modest changes, such as moving to a managed database
• Refactor — rework the application for cloud-native services
• Repurchase — replace it with SaaS
• Retire — a serious number of workloads turn out not to be needed
• Retain — some things should stay where they are, and saying so is a decision, not a failure

Most estates need a mix. Applying one strategy to everything is the usual cause of disappointing results.

Planning the project

A migration plan that works starts with discovery: what you actually use, what depends on what, and what each workload costs today. Dependencies are where migrations fail — the application nobody mentioned that turns out to feed the finance system.

From there: sequence by risk and value, migrate a low-risk workload first to prove the approach, and keep a rollback path until each move is confirmed.

What it looks like in practice

Notting Hill Genesis needed to move off a legacy on-premises Dynamics CRM before Microsoft discontinued the version they were running, without disrupting the banking and customer-facing services that depended on it. The migration ran on Azure, kept Dynamics 365 as the platform NHG's teams already knew, and completed with minimal planned disruption to live services — the standard this kind of migration should be judged against, not just cost saved.

Why a delivery partner tends to pay for itself

The economics are straightforward. Migration is a temporary need for a specialist skill set, and building that team internally means recruiting for work that ends. A partner brings the pattern from previous migrations — including the failure modes — and hands over an estate the internal team can run.

The measure of a good one is what you are left holding afterwards.