Cloud Migration and Optimization

A cloud migration is a sequence of decisions rather than one event: every workload gets a strategy, a wave and a rollback point before anything moves. This page sets out the six phases we work in, the seven AWS migration strategies and what each one buys, a readiness self assessment you can run before asking anyone for a quote, and the cost optimisation practices that hold after the move.

On this page

• How a migration runs, phase by phase
• The seven migration strategies, and what each one buys
• A migration readiness self assessment
• Cost optimisation, practice by practice
• More about cloud
• Cloud consulting services
• Talk to our engineers

How a migration runs, phase by phase

A migration is not one event. It is a sequence with a decision at the end of each phase, and the whole design exists so that no single failure can take the business down. The phases below are the order we work in. If a vendor cannot tell you which phase they are in, they are improvising.

1. AssessA workload inventory with dependencies and a risk rating per workload.
2. PlanA migration plan with waves, a target architecture and a landing zone design.
3. PilotA tested runbook and a set of corrections to the plan.
4. Migrate in wavesThe workloads themselves, plus a cutover record per wave.
5. ValidateFunctional, performance, restore and security checks against the agreed criteria.
6. Optimise and operateRightsizing, lifecycling and scheduling, then the operating model and the runbooks.

1. Assess

Build the inventory before touching anything: every application, server, database and scheduled job, what each one talks to, how much data sits behind it, who owns it, and which of them nobody owns. Dependency mapping is the part that decides the timeline, because the expensive discovery is a job on a forgotten machine that three other systems quietly depend on. This phase also records the compliance surface: where data may live, which framework the contract names, and what evidence the eventual audit will ask for. What lands at the end of it is a workload inventory with dependencies and a risk rating per workload.

2. Plan

Every workload gets a strategy from the set below, a target design, and a place in a wave. The plan names the downtime window each wave may use, the rollback point for each workload, and the success criteria that decide whether a wave is finished. The landing zone is designed here as well: identity, network boundaries, logging, guardrails and the tagging standard that will later make the bill attributable. What lands is a migration plan with waves, a target architecture and a landing zone design.

3. Pilot

One workload, real but low risk, taken end to end. The point is not the workload. The point is to prove the landing zone, the tooling, the cutover runbook, the rollback and the monitoring, while the cost of being wrong is small. Our AWS services page states the same rule for AWS work: migrations run in waves rather than a single cutover, starting with a low-risk workload to prove the landing zone and the runbook before anything critical moves. What lands is a tested runbook and a set of corrections to the plan.

4. Migrate in waves

The remaining workloads move in the grouping the plan set, dependency clusters together so that two systems which talk to each other do not end up on opposite sides of a network boundary for a week. Each wave carries its own cutover window, its own rollback point and its own go or no-go decision. Data migration is rehearsed rather than attempted, and the rehearsal is what produces a realistic cutover duration. What lands is the workloads themselves, plus a cutover record per wave.

5. Validate

Correct is not the same as working. Validation covers functional testing against the criteria agreed in phase two, performance under a load that resembles the real one rather than a smoke test, a restore actually performed into a clean environment, and a security review of the new configuration. Our production readiness checklist is the same standard we apply here: a backup that has never been restored is not a backup, and a health check that touches the database, the queue and the downstream APIs will lie to you during an incident.

6. Optimise and operate

Optimisation belongs after the move and not instead of it, because until the workload is running in its new home there is nothing real to measure. Rightsizing against observed usage, storage lifecycling, scheduling for non-production, and commitment pricing only where usage has proved steady. Then the operating model: monitoring, alert routing, patching and the runbooks handed to whoever will own it. Our managed services cover incident, problem, change and release management, service level management, an L1 and L2 help desk and L3 application support if you want us to keep running it.

We work in two week sprints throughout, so progress is visible at a fixed cadence rather than at the end, and a wave plan can change at a sprint boundary. That cadence is published on our about us page and it is the same one we use on every engagement.

The seven migration strategies, and what each one buys

Before anything moves, every workload needs a decision about how it moves. AWS publishes seven strategies, known as the 7 Rs, in its prescriptive guidance for large migrations, and the definitions below are theirs. An estate can warrant a mix, decided per workload rather than adopted as a policy.

Retire

The strategy for applications you decommission or archive instead of moving. AWS lists the usual signals: no business value in keeping it, no inbound connection for a long period, and very low average CPU and memory usage, which it calls zombie and idle applications. Every workload retired is one that never has to be migrated, tested, secured or paid for again, which is why the inventory phase earns its cost.

Retain

The strategy for applications you keep where they are, for now. AWS names data residency requirements, high risk systems that need a detailed assessment first, unresolved dependencies on other applications, recently upgraded systems, applications with a vendor SaaS version on the way, physical dependencies with no cloud equivalent, and mainframe or mid-range systems. Retain is a decision, not a failure, and it should be written down with a review date.

Rehost

"Also known as lift and shift", in AWS's words: the application moves without being changed. It is the fastest route and it carries the least design risk, and AWS notes it "helps you to scale your applications without implementing any cloud optimizations that could save you time or money". Applications are easier to optimise once they are already running in the cloud, which is the argument for rehosting first and modernising after.

Relocate

Moving a large number of servers, or an instance between accounts, regions or virtual private clouds, without buying new hardware, rewriting the application or changing operations. AWS describes it as the quickest way to migrate and operate a workload in the cloud "because it does not impact the overall architecture of your application".

Repurchase

"Also known as drop and shop": you replace the application with a different product. AWS lists moving from a traditional licence to SaaS as a common use case for it. AWS points out what follows the purchase, and it is the part that is easy to underestimate: training, data migration, integration with your authentication services, and network configuration.

Replatform

"Also known as lift, tinker, and shift". The application moves and picks up some optimisation on the way, for example a self-managed database becoming a managed one. AWS describes the benefit directly: replatform "reduces cost and improves performance by migrating to a managed or serverless service, moving virtual machines to container, and avoiding licensing expenses".

Refactor or re-architect

The application is redesigned to use cloud-native features. AWS calls this "the most complex and costly of the migration strategies" and recommends, for large migrations, modernising after the move rather than during it. The cases where it is still right are the ones AWS lists: a monolith that is already slowing releases, a legacy system nobody can maintain, low test coverage, or a data model that has to be split for security or compliance reasons.

How to choose

Three questions frame the decision. How long can this be unavailable, which sets whether you rehearse a cutover or take one. How much will it cost to run unchanged, which is what makes replatforming pay for itself. And how long will you keep it, because refactoring a system you already plan to replace is a cost with no return. Anything still undecided after those three is waiting on an owner rather than on an analysis.

A migration readiness self assessment

Run this before you ask anyone for a quote, including us. Every item is something you can check yourself, and every unchecked item is either work to add to the plan or a question a vendor should be asked to answer.

• There is a written inventory of applications, servers, databases and scheduled jobs, and it was produced from the environment rather than from memory.
• Every item on that inventory has a named owner who is still at the organisation.
• The dependencies between them are mapped, and somebody other than the author has checked the map.
• You know where your data is allowed to live, and whether any of it is subject to a residency rule.
• You know which control framework your contracts name, and what evidence an assessor would ask for.
• A restore has actually been performed into a clean environment, not just a backup taken.
• Each system has an agreed maximum downtime window, agreed with the business rather than assumed by IT.
• There is a rollback point defined for each workload, and a written decision about what happens if a cutover window overruns.
• Licensing terms have been read for anything moving, because some of them change price or validity on different infrastructure.
• The current run cost is known per system, not just as one invoice, so that after can be compared with before.
• Somebody owns the environment after go live, with the time and the access to do it.
• There is a first workload chosen for the pilot, and a reason it was chosen.

If you cannot check the first three, start there. An assessment that produces an inventory, a dependency map and an owner per system is worth more than a migration plan built on guesses, and it is the cheapest phase to get right.

Cost optimisation, practice by practice

Cloud spend is not reduced by a negotiation. It is reduced by a sequence of small, boring, measurable changes, and they only work in order: make the bill legible, then remove waste, then commit to what is left.

1. Make the bill legibleA tagging standard applied consistently, and showback to the people who create the spend.
2. Remove wasteRightsizing against observed usage, scheduling, and storage tiering and lifecycle.
3. Commit to what is leftReserved capacity and savings plans, once usage has proved steady.

Tagging and showback

A tagging standard applied consistently is what turns one invoice into a bill per team, per environment and per product. Showback is the practice of putting that attributed cost in front of the people who create it. Nothing else on this list can be prioritised without it, because until spend has an owner, every optimisation is somebody else's job.

Rightsizing

Matching the instance, database tier or storage class to observed usage rather than to what was provisioned on day one. Capacity gets chosen for a launch peak and then never revisited, which is what makes it the first place to look. Our AWS and Azure pages both name rightsizing as part of ongoing optimisation.

Scheduling

Non-production environments do not have to run outside working hours, and neither do batch platforms between runs. Scheduling them off touches nothing user-facing, which is what makes it the low-risk change on this list.

Storage tiering and lifecycle

Data gets colder with age and storage classes are priced accordingly. A lifecycle policy moves it down the tiers automatically and deletes what has passed its retention period. The place to look is not only the live data: it is orphaned volumes, old snapshots and backups of systems that were decommissioned and never cleaned up.

Commitment pricing, once usage is proved

Reserved Instances "are not physical instances, but rather a billing discount applied to the use of On-Demand Instances in your account", and the discount applies only where the instance matches attributes such as type and Region (AWS documentation). Savings Plans "provide savings beyond On-Demand rates in exchange for a commitment of using a specified amount of compute power (measured per hour) for a one or three year period" (AWS documentation). Both are a bet on your own steady state, so they belong after rightsizing and scheduling rather than before, and the commitment should cover the floor of your usage rather than its average.

Architecture level changes

The reductions that outlast a cost review are design decisions rather than settings: replacing a self-run service with a managed equivalent, removing a licence by changing the database engine, moving traffic so that it stops crossing a chargeable boundary, or archiving a system that retire would have covered in the first place. These belong in a roadmap, not in a cost review, because each one is a project.

Measure before, so after means something

What optimisation is worth depends entirely on how an estate was built and how recently anyone looked at it, which is why we measure the current run cost per system before changing anything. A saving only means something against a baseline that existed before we arrived, and a baseline taken afterwards is not one. Our guide to cloud cost optimisation covers the specifics, and what cloud migration costs covers the project side.

More about cloud

Start here

• Cloud consulting services, the deeper page on cloud strategy, definitions, governance and compliance
• DevOps services
• Managed services
• Infrastructure management

Platforms and sectors

• AWS services
• Azure services
• Google Cloud services
• Public sector
• Cybersecurity services

Reading

• Cloud cost optimisation strategies
• What cloud migration costs
• Production readiness checklist
• Talk to our engineers

Ready to move? Tell us what you are running now and what is forcing the move, and we will tell you which phase to start in and what we would want to see before quoting. Talk to our engineers.