Cloud Migration
Cloud migration at OMAV assesses each workload individually and gives it a disposition: move it, re-platform it, or leave it where it is. A migration plan that recommends moving everything has not been done.
A disposition per workload, with the arithmetic
The question is never whether to move to cloud. It is which workloads, in what order, changed how much, and which should stay exactly where they are. Answering it requires an inventory with dependencies and owners, which most estates cannot produce on request.
Some workloads cost more in cloud and always will. Latency-bound applications, workloads with licensing that penalises virtualised cores, and end-of-life systems awaiting replacement are the recurring three. A plan that does not name yours has not examined them.
The other half of the work is rehearsal. Every cutover with a rollback window gets executed in advance and timed, because a runbook that has never been run is a document rather than a plan.
What a migration engagement covers
Six workstreams, sequenced so nothing moves before it is understood.
Application inventory
Every application catalogued with its dependencies, data volumes, integration points, licensing position and a named business owner — the workstream most often skipped and most often regretted.
Disposition per workload
Rehost, re-platform, refactor, retain or retire decided per workload with the cost of each option stated, so the decision is arithmetic rather than preference.
Wave planning
Migration sequenced by risk and dependency, with the lowest-risk wave first to prove the process and the tooling before anything critical moves.
Cutover runbooks
Step-by-step runbooks with timings, decision points and a rollback position, rehearsed in advance for anything with a rollback window.
Landing zone readiness
Networking, identity, security baseline and monitoring in place in the target before the first workload arrives, rather than assembled around it afterwards.
Post-migration validation
Cost and performance measured against the pre-migration baseline, because a migration that quietly doubled the run rate has not succeeded.
How a migration runs
Inventory
Applications, dependencies, data volumes, licensing and owners catalogued, with anything nobody can account for flagged for a decision.
Decide dispositions
Each workload assigned a disposition with the cost of every option shown, including the cost of leaving it alone.
Prepare the target
Landing zone, identity, networking, security baseline and monitoring readied before the first wave, not alongside it.
Rehearse and move
Waves migrated against rehearsed and timed runbooks, lowest risk first, with rollback available where it matters.
Validate
Cost and performance compared against the dated pre-migration baseline, with anything worse investigated rather than accepted.
The five dispositions
What each means and when it is right.
| Disposition | What changes | Effort | Right when |
|---|---|---|---|
| Rehost | Infrastructure only | Low | Exiting a data centre under time pressure |
| Re-platform | Managed services adopted | Moderate | Databases and middleware, mainly |
| Refactor | Application architecture | High | The application is strategic and constrained |
| Retain | Nothing | None | Latency, licensing or end-of-life reasons |
| Retire | It is switched off | Low | Nobody could name a user |
What the report will tell you
Some workloads should not move, and the report names them with the reasoning. Latency-bound applications, workloads whose licensing penalises cloud cores, and systems already scheduled for replacement frequently cost more in cloud with no offsetting benefit. Presenting a plan without those exceptions is how migrations get paused halfway through.
Rehosting also does not modernise anything. Lift and shift moves the problem to a different data centre with a different billing model, and that is sometimes exactly the right answer under a data-centre exit deadline. It should just be chosen knowingly rather than described as transformation.
- A plan that moves everything has not examined anything.
- You cannot sequence a migration without a dependency-mapped inventory.
- Rehearse and time every cutover that has a rollback window.
- Validate cost and performance against a dated pre-migration baseline.
Questions buyers ask about this
What if some workloads should not move?
Then the report says so, with the reasoning and the cost comparison. Latency-bound, licence-penalised and end-of-life workloads frequently cost more in cloud. Naming them early is what keeps a migration from stalling at sixty percent when the exceptions are discovered one at a time.
Do you rehearse cutover?
Always, for anything with a rollback window. The rehearsal establishes how long each step actually takes, which is usually different from the estimate, and it surfaces the dependency nobody documented. A runbook that has never been executed is a document, not a plan.
How long does a migration take?
Eight to twenty-six weeks for most mid-sized estates, staged in waves. The inventory and disposition work is four to six weeks of that and it determines everything after it. Estates where nobody can produce a dependency map take longer, and that is worth knowing before a date is promised to the board.
Will cloud be cheaper?
For some workloads yes, for others no, and the honest answer is per workload rather than per estate. Where the business case rests on cost alone we will show you which workloads support it and which undermine it. Migrations justified on agility and resilience are often sounder than those justified purely on run rate.
Can you migrate SAP to cloud?
Yes, and it is assessed as its own workstream because sizing, certified instance types, backup and the SAP support position all differ from general workloads. It is frequently sequenced separately from the rest of the estate for that reason.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.