For the move itself, not what happens after it lands

Cloud Migration

A migration fails at the wave plan, not at the cutover, because a badly sequenced move surfaces every hidden dependency at the worst possible time. This practice treats the assessment, the rehost-or-refactor decision and the cutover itself as one accountable sequence, closing on a runbook your team keeps.

Talk to UsScope the Work
AI augmented, human governedEvidence before estimatesYour IP from day oneOne accountable owner per engagementFounded in 2011. Part of the Vinove Group500+ full-time engineers, as of September 2026NASSCOM member
Watch · the 90-second brief

How a migration wave actually runs

Assessment, wave sequencing and a cutover with a tested rollback path, walked through.

90 secWatch without filling in a form.
A cloud migration wave plan under review before cutover.90 secSample frame · video pending

01Before a workload moves

Rehost, replatform or refactor: a real decision

Treating every workload the same way is how migrations run over budget. Four questions settle which path actually earns its cost for a given workload.

Does the workload work well where it sits today?

If the only problem is the data center lease, a straight rehost may be the cheapest path that still meets the deadline.

Is the application architecture already cloud-shaped?

An application already built loosely coupled replatforms cheaply. A tightly coupled monolith often needs deeper rework first.

What does downtime actually cost this workload?

A workload with near-zero downtime tolerance needs a slower, more carefully staged cutover than one that can pause overnight.

Is refactor solving a real constraint or a preference?

Refactoring costs the most and pays off only when the current architecture is genuinely blocking scale, cost or reliability.

Rehost, replatform and refactor compared
RehostReplatformRefactor
EffortLowestModerateHighest
Cloud-native benefitMinimal at firstPartialFull, once complete
Typical timelineFastestWeeks to monthsLongest
Best fitDeadline-driven exitsWilling to adjust configArchitecture is the constraint

02Agreed before any wave cuts over

The ledger that keeps a migration honest

Migrations drift when a wave cuts over without a clear owner for the decision. This sets the terms plainly: what you bring, what gets assessed, what comes back, and which approvals never move without you.

  1. Your side

    You bring

    • The current data center inventory
    • The lease deadline and any hard cutoff
    • Which workloads cannot tolerate downtime
  2. Our side

    We build

    • A full workload assessment against migration options
    • A wave plan sequenced by risk and dependency
    • Rehost, replatform or refactor decisions per workload
  3. Your side

    You receive

    • Every workload running on its new destination
    • A tested rollback path for each wave
    • A cutover runbook your team can repeat

Never leaves you

  • The lease negotiation and exit timeline
  • Approval of every wave before it cuts over
  • Ownership of each workload throughout the move

Where the line sitsWe plan and execute the waves. The deadline and the go decision for each cutover stay with you, because a forced move is still your call to time.

03From inventory to closed wave

Four stages, each closing on an artefact

A migration that stalls usually skipped one of these stages quietly. This system closes each one with something your team can inspect before the next begins.

  1. Assess the estate as it stands

    Workloads, dependencies and downtime tolerance get mapped before any migration path gets recommended for a single one of them.

    Every workload and its dependencies named

  2. Build the wave plan

    Waves are ordered by risk and dependency, so an early wave never depends on something a later wave has not moved yet.

    A sequence that respects real dependencies

  3. Rehearse the cutover

    Each wave's cutover and rollback gets rehearsed against a non-production copy before it ever touches a live workload.

    A rollback path proven before it is needed

  4. Cut over and hand off the runbook

    The live cutover follows the rehearsed plan, and the runbook moves to your team for any wave still ahead.

    A runbook your team can repeat

04What actually moves the number

Four drivers, priced from the assessment

Migration work is priced from the workload assessment, not a flat estimate, because these four factors change effort by multiples of the base case.

Driver 01

Number and size of workloads in scope

A handful of stateless services moves far more cheaply than a large estate carrying legacy state and integrations.

Driver 02

Mix of rehost, replatform and refactor decisions

A plan weighted toward refactor costs more upfront and pays back later. A rehost-heavy plan moves fastest for the least change.

Driver 03

Downtime tolerance across the estate

Near-zero downtime tolerance requires staged, reversible cutovers that cost more to design than a workload that can simply pause.

Driver 04

Compliance duties attached to the data moving

Regulated data adds validation and audit steps to every wave that touches it, regardless of how simple the workload itself is.

05Evidence and proof

Moves that closed on schedule, not just eventually.

Migration proof is a completed wave with no lost data, not a signed contract. Every record here waits for written client approval before production.

Explore case studies
A data center migration wave plan reaching final cutover.
Nexa Foundry · Industrial manufacturing, EU

A data center exit completed before the lease deadline.

Nexa Foundry faced a hard lease cutoff with a large legacy estate still on-premises. A waved migration moved every workload with no unplanned downtime.

Workloads migrated
Full estate
Unplanned downtime
None reported
Sample · pending client approval
Two cloud footprints consolidating into a single migrated estate.
Aster North · Product SaaS, US

Two cloud footprints became one after an acquisition.

Aster North acquired a company running on a separate cloud toolchain. A consolidation plan merged both footprints without a service collision.

Cloud footprints consolidated
Two into one
Service collisions during merge
Zero
Sample · pending client approval
Portrait of a CTO reviewing a completed migration wave.

Every wave had a rollback path we never had to use, and that was the point.

Daniel MercerCTO, Vela Ledger
Sample · pending client approval

06Read this first

When a migration engagement is the wrong spend

Commissioning a full migration programme for a workload that just needs day-to-day reliability work would waste the engagement. The exits are marked before the pitch.

  • The estate already moved and just needs running well

    If the workloads are already on the cloud, day-two reliability work fits better than another migration engagement.

    Cloud Operations

  • The real problem is application-level technical debt

    Moving a struggling legacy application without addressing its debt just relocates the same problem onto new infrastructure.

    Legacy Modernization

  • Your team should run the wave plan itself

    If your engineers understand the estate and just need capacity, hiring into the team fits better than a delivery layer.

    Hire Cloud DevOps Engineers
Engagement shapes for migration work
ShapeBest whenYou directWe carry
Scoped assessmentThe path is genuinely unclearWhich workload gets assessed firstThe recommendation and proof of concept
Phased programmeA full estate must move in wavesWave order and go decisionsPlanning, cutover and rollback design
Team extensionYour leads already run migrations wellStandards and architectureNamed engineers and continuity

07Straight answers

Asked before a wave plan is committed.

Not answered here?

Ask us directly Or scope the work first
How long does a full migration usually take?

It depends entirely on the number of workloads and how many need replatforming or refactoring rather than a straight rehost. The wave plan sets a realistic timeline once the assessment is complete.

Do you handle the cutover, or only plan it?

Both. The wave plan and the live cutover execution are part of the same accountable sequence, with a rehearsed rollback path attached to every wave.

What happens if a wave fails during cutover?

It rolls back along the rehearsed path rather than being pushed through. Every wave is rehearsed against a non-production copy before it ever touches a live workload.

Can you migrate to a specific provider we have already chosen?

Yes, the assessment and wave plan build around whichever provider you have committed to. Provider selection itself sits outside this practice's scope.

Do you also run the estate once it lands in the cloud?

That work sits with cloud operations as a separate, ongoing practice. Migration closes with a runbook your team can hand off into that day-two relationship.

How do you decide between rehost, replatform and refactor?

Against the assessment, not a default preference. Downtime tolerance, current architecture and the real constraint driving the move all weigh into the recommendation.

What does a migration engagement cost?

Pricing follows the workload count, the mix of rehost, replatform and refactor decisions, and any compliance duties attached to the data, set during scoping.

Can you consolidate two cloud accounts after an acquisition?

Yes, once the organisation has decided which toolchain survives. Consolidation runs against a decided target state rather than choosing one for you.