Cloud migration and infrastructure evaluation: the complete guide

Few infrastructure decisions are discussed as often, or as loosely, as moving to the cloud. For some organisations it has cut costs, removed ageing hardware and made recovery from failures far easier. For others it has produced a larger monthly bill, slower applications and a team stretched between old and new environments. The technology is the same in both cases. The difference is the planning.

This guide brings together the briefings in our cloud series. It covers how to assess what you run today, how to choose between public, private and hybrid models, how to plan and run the migration, and how to keep costs predictable afterwards. It is written for IT leaders and the finance and operations colleagues who share the decision.

Know why you are moving

Start by stating the goal, because it shapes every later choice. Common reasons include lower or more predictable cost, better resilience and recovery, faster delivery of new services, retiring hardware that is near the end of its life, or exiting a data centre contract. Each goal favours different decisions: a resilience goal justifies spending on redundancy, while a cost goal may argue for leaving some systems where they are.

Write the goal down with two or three measures you will check after the move, such as monthly run cost, recovery time for key systems or time taken to provision a new environment. Without them, nobody can say whether the migration succeeded, and debates about its value continue for years.

Assess what you run today

A migration goes well when you know what you run, what depends on what and what must not break. Most organisations discover systems during the assessment that nobody had listed: a reporting server under a desk, a scheduled job that feeds the finance system overnight, a licence tied to a specific physical machine.

Not everything should move. Some systems are cheaper or safer where they are, such as specialist equipment controllers on a factory floor, applications due to be retired within a year, or workloads with steady, predictable demand on hardware already paid for. Decide workload by workload rather than setting a target of moving everything.

Choose the right cloud model

The right model depends on data rules, performance needs and the skills you have. There is no universally correct answer, and many organisations end up with a mix.

• Public cloud offers speed, scale and a wide range of managed services, with security shared between you and the provider. It suits variable workloads and teams that want to stop managing hardware.
• Private cloud gives more control and fits strict data requirements, but leaves more for you to manage and usually costs more per unit of capacity.
• Hybrid combines both. It suits organisations moving in stages, or those with some workloads that must stay on premises.

Data location matters. Regulation and customer contracts may restrict where personal or sensitive data is stored and who can access it. Check these requirements before you choose a provider or region; moving data again later is costly and disruptive.

Connectivity is part of the design. When applications move to the cloud but users stay in offices and warehouses, every request crosses the network. Poor links between sites and the cloud cause slow screens and complaints that wrongly blame the move. Size and test connectivity before migrating systems people use all day.

Plan the migration in waves

Sequence workloads in waves, each with a clear scope, test plan, cut-over approach and rollback plan. Move low-risk systems first, such as development environments, internal tools or file archives, to build the team’s experience before tackling systems the business depends on every day.

Lift and shift is not a strategy

Moving applications unchanged, often called lift and shift, is quick and sometimes the right first step, especially when a data centre exit has a fixed date. But it often leaves cost and complexity untouched: an oversized server in your own building becomes an oversized and more expensive server in the cloud. Plan the second step from the start. Identify the few applications that cause most pain and modernise those, by moving databases to managed services, for example, or adjusting applications to scale with demand.

Planning a migration weekend

For systems that cannot be moved gradually, a planned cut-over, often over a weekend, is common. A calm cut-over is built on rehearsal, clear roles and a tested way back.

1. Rehearse the full sequence in advance, timing each step, and repeat until the timing is reliable.
2. Assign roles: everyone should know their task, who they report to and who decides whether to proceed.
3. Define checkpoints with go or no-go decisions at each stage.
4. Agree the point of no return and the rollback steps before you start, and test the rollback.
5. Prepare business users to test key transactions as soon as systems are back.
6. Plan communications for users before, during and after the weekend.

Control cloud cost after the move

Cost can rise after migration. Cloud bills grow quietly: test environments left running, storage that is never cleared, resources sized generously at launch and never reviewed. Unmanaged spend can quickly erase the savings in the business case. A few habits keep it visible and predictable.

• Tag everything by owner, project and environment, so each cost can be attributed and questioned.
• Right-size regularly, reducing oversized resources and switching off idle ones, especially outside working hours.
• Set budgets and alerts that warn owners before they overspend, not after the invoice arrives.
• Use commitment discounts for steady workloads once usage patterns are clear.
• Review the bill monthly with a named owner from IT and one from finance.

The migration itself went smoothly. The surprise came three months later, when we found a dozen test servers nobody had switched off. Tagging and a monthly review fixed it.

IT manager, professional services client

Verify and improve

After each wave, confirm performance, security and cost against the plan and the goals you set at the start. Check that backups run and restores work in the new environment, that monitoring covers the moved systems and that access controls match what was agreed. Record lessons from each wave and apply them to the next.

Done well, a migration delivers lower and clearer costs, backup and recovery designed in, capacity when you need it and fewer surprises along the way. A practical first step is the application inventory: list your twenty most important systems with their owners and dependencies this month. It will tell you which ones are ready to move, which need work and which should stay where they are.

Source: Intelliversal analysis, drawing on the briefings in this series.

Frequently asked questions

Will moving to the cloud save money?

It can, but not automatically. Savings come from right-sizing, switching off idle resources and retiring hardware. Moving unchanged systems without cost controls often increases spend.

Should we move everything at once?

Rarely. Moving in waves, starting with low-risk systems, builds experience and limits the impact of problems. Some systems may be better left where they are.

Is the cloud less secure than our own data centre?

Not inherently. Major providers secure their infrastructure well, but you remain responsible for access, configuration and data. Most cloud incidents stem from misconfiguration rather than provider failures.

Explore Cloud migration and infrastructure evaluation