VMware Migration Services: How to Scope, Price and Run a VCF Move

VMWARE MIGRATION SERVICES

A Consult Circle guide to what a VCF migration engagement actually contains, what drives the cost, and how to tell a good proposal from a thin one.

Every organisation still on the VMware platform is now having a version of the same conversation. Perpetual licensing has gone, the subscription model has changed the cost base, and VMware Cloud Foundation is the destination whether or not anybody planned for it this year. The technical question of how to move workloads has a well understood answer. The harder question, and the one that actually determines whether the project lands on time, is how much work it is and who does it.

This guide is about that second question. It covers what a genuine VMware Migration Services engagement contains, how the phases break down, what makes one estate cost three times another of the same size, how the common pricing models behave when things go sideways, and what to look for in a proposal before you sign it. It is written from the delivery side, which means it includes the parts that are inconvenient to admit in a sales conversation.

If you are looking for the technical walkthrough of the HCX build itself, that is a separate guide. This one is for the person who has to scope the work, defend the number internally, and pick who runs it.

What This Guide Covers

• What is actually inside a VCF migration engagement
• The five phases and what each one produces
• What drives cost, and why estate size is only half the story
• Pricing models compared, and how each behaves under change
• Splitting the work between your team and a partner
• How to read a proposal, with the questions that expose a thin one
• A scoping checklist you can complete before you talk to anyone

What a VCF Migration Engagement Actually Contains

The word migration does a lot of work in these conversations, and it means different things to different vendors. Some proposals cover the movement of virtual machines and nothing else. Others include the design and build of the destination platform. The gap between those two interpretations is frequently larger than the price difference, so it is worth being precise about scope before comparing numbers.

A complete engagement usually covers five distinct bodies of work, and it is entirely reasonable to buy some of them and not others. What is not reasonable is to buy the middle three and assume the first and last are included.

• Assessment and discovery. A full inventory of the estate, dependency mapping between applications, eligibility analysis against the migration mechanisms available, and a gap analysis covering networking, storage, licensing and backup.
• Target platform design and build. Designing and standing up the VCF environment itself: management domain, workload domains, NSX topology, storage design, identity, monitoring and backup integration. This is often a separate engagement and often the larger of the two.
• Migration tooling design and deployment. HCX design and build, Service Mesh topology, network profiles, appliance sizing and placement, and validation against a pilot group.
• Wave execution. The migration itself, run against a runbook, with per-wave validation and rollback procedures.
• Transition and decommissioning. Un-extending stretched networks, removing migration infrastructure, handing over operational documentation, and reclaiming the source environment.

The last item is the one most likely to be missing from a proposal, and its absence is easy to miss when you are comparing prices. An engagement that finishes when the last workload lands leaves you owning the cleanup, and cleanup on a migration platform is not work an internal team can safely improvise.

The Five Phases and What Each One Produces

A well structured engagement has a deliverable at the end of every phase that you could hand to a different supplier and have them continue. If a proposal does not describe what you receive at each gate, you have no way to measure progress until the end.

Phase	Typical duration	What you should receive
Discovery and assessment	3 to 10 consultancy days	Inventory, dependency map, eligibility report, remediation list, gap analysis
Target design	5 to 15 days depending on scope	Low level design for the VCF environment, signed off before build
Migration design and build	3 to 5 days	HCX design document, deployed and validated Service Mesh, pilot migration report
Runbook and wave planning	2 to 4 days	Wave schedule, per-wave runbook, rollback procedures, communications plan
Execution and transition	Variable, scales with workload count	Per-wave completion records, validation sign-offs, as-built documentation, decommissioning report

Discovery is the phase to spend money on. It is comparatively cheap, it happens before any deadline pressure exists, and everything downstream is priced off what it finds. A partner who proposes two days of discovery for an eight hundred workload estate is either going to come back for more budget later or is planning to find the problems during execution.

What Actually Drives the Cost

Workload count is the number everyone quotes and it is the weakest predictor in the set. It scales execution effort reasonably well and almost nothing else. Two estates of six hundred virtual machines can differ by a factor of three in total effort, and the difference is always in these categories.

Application interdependency

A collection of six hundred independent web servers is a straightforward project. Six hundred workloads representing forty applications with cross-tier dependencies, shared databases and hardcoded addressing is a different exercise entirely. Dependency complexity drives wave count, wave count drives change windows, and change windows drive calendar duration more than anything else.

Remediation debt

Older estates carry workloads that cannot move as they stand: virtual hardware below the minimum for live migration, Fault Tolerance still enabled on a handful of finance systems, shared SCSI configurations under clustered databases, ISOs mounted from datastores that were retired years ago. Each of these needs remediating before the workload is eligible, and remediation usually needs its own change window. This is the category most likely to be discovered late and it is the single most common cause of overrun.

Network constraints

Bandwidth between source and destination sets the ceiling on how fast waves can run. Beyond raw capacity, the questions that drive effort are whether workloads can be re-IPed, how many Layer 2 segments need extending during the transition, and whether the routing design allows migrated workloads to communicate with what they left behind. Re-IPing is cheaper technically and vastly more expensive organisationally, because it needs every application owner to confirm what breaks.

Change control and organisational friction

This is the cost driver nobody puts in a proposal. In a regulated environment with a weekly change advisory board and a two week lead time, a migration that represents thirty days of technical effort will span five months of calendar time, and every one of those months carries project management overhead. Ask about it during scoping, because it is the difference between a quote and a plan.

Destination readiness

If the VCF environment is already built, licensed and validated, migration can start immediately. If it does not exist yet, that build is the critical path and the migration schedule hangs off it. Proposals that quote a migration timeline without confirming the destination is ready are quoting the second half of a project.

Pricing Models and How Each One Behaves

Three models dominate. None of them is dishonest and each fails in a specific and predictable way, so choose based on how much you know about your estate rather than on which number looks smaller.

Model	Works well when	Fails when
Time and materials	The estate is poorly documented and discovery has not run yet	Nobody is incentivised to be efficient and the budget has no ceiling
Fixed price on a defined scope	Discovery is complete and the workload list is agreed	Anything outside the scope line becomes a change request, including problems the discovery missed
Per workload or per wave	Workloads are homogeneous and interdependency is low	A complex application counts the same as a standalone file server, so the pricing stops reflecting the work

The pattern that works most reliably is to buy discovery on time and materials as a small, self-contained piece of work, then price the rest on a fixed scope built from what discovery found. That way the fixed price is anchored to reality instead of to an assumption, and you own a deliverable that is useful even if you then choose a different partner for delivery.

Whichever model you use, agree in writing what happens to remediation work. Remediating a workload so it becomes eligible to migrate is a genuinely separate activity from migrating it, and if that boundary is not defined before execution starts it will be argued about during it.

Splitting the Work Between Your Team and a Partner

Very few organisations should outsource the whole thing, and very few should attempt all of it in-house. The split that works is based on who holds the knowledge rather than who holds the skills.

• Your team owns application context. Which workloads matter, who owns them, what the dependencies are, what a successful smoke test looks like, and which business dates are immovable. No partner can supply this and any partner who claims not to need it is going to get it wrong.
• Your team owns change and communications. Change control, application owner engagement and the internal politics of moving a system somebody is nervous about. Partners can support this but should not be leading it.
• The partner owns migration mechanics. HCX design, Service Mesh topology, wave execution, throughput management and the failure modes that only become familiar after running this repeatedly.
• The partner owns the runbook. Written procedures for each wave including rollback triggers, produced before execution rather than assembled during it.
• Shared: the eligibility audit. The partner runs the technical scan; your team confirms which findings are real and which are artefacts of stale documentation.

The most common failure of this split is the assumption that a partner running execution also owns application validation. They do not and they cannot. Infrastructure confirms the workload is running; only the application owner can confirm it is working. Build that sign-off into the wave definition or you will discover the gap after the source environment has been decommissioned.

How to Read a Proposal

Most weak proposals are not misleading, they are just vague in the places where precision is expensive. These are the questions that separate a plan from a brochure, and the answers tell you a great deal about whether the supplier has done this before.

• How many consultancy days are allocated to discovery specifically, and what is the deliverable at the end of it?
• Who is responsible for remediating workloads found to be ineligible, and is that inside or outside the quoted price?
• Is the destination VCF environment in scope, or is it assumed to exist?
• What happens to the price if the workload count moves by fifteen percent in either direction?
• Is decommissioning included, specifically the un-extension of stretched networks and removal of migration infrastructure?
• Who signs off a completed wave, and what evidence is produced?
• What is the rollback procedure, and has it been tested rather than documented?
• Which named individuals are delivering, and are they the same people who attended the scoping call?
• How is application owner validation captured, and what happens to a wave when validation fails?
• What does the handover pack contain and who is trained on it?

The last question is worth more weight than it usually gets. A migration ends with an operational platform that your team runs from that point onwards. If the engagement produces no documentation and no knowledge transfer, you have bought a completed project and an operational gap.

What a Properly Resourced Engagement Looks Like

For a mid-sized estate of roughly 300 to 800 workloads across several clusters, the team shape that works looks like this.

• Solution architect. Heavily engaged during discovery and design, tapering to oversight during execution. Owns the design decisions that are expensive to reverse.
• Migration engineer. The day to day operator. Runs waves, manages throughput, handles the failures that occur mid-migration. This is the role that scales with workload count.
• Project lead. Coordinates application owners, change windows and communications. Underestimated constantly, and the reason projects with good engineers still miss dates.
• Network and security input. Engaged intensively around the pre-check and any Layer 2 extension design, then intermittently. Does not need to be full time but does need to be responsive.
• Application owners. A few hours per wave, for validation. Their availability, not the technology, is frequently the constraint on how fast waves can run.

A smaller estate collapses the architect and engineer into one person. A larger one adds engineers rather than architects. What does not change is the need for someone whose job is the coordination, because the technical work is not the part that slips.

A Worked Example: What 600 Workloads Looks Like

Abstractions are hard to budget against, so here is a shape drawn from the kind of estate we see most often. Six hundred virtual machines across four clusters and two vCenters, a mix of vSphere 7 and 8, roughly 220 terabytes provisioned, no NSX on the source side, and a destination VCF environment that is being built in parallel by the same programme.

Discovery runs for six days. It produces an inventory that differs from the customer spreadsheet by around eleven percent, which is normal, and identifies forty three workloads needing remediation before they can move using the preferred mechanism. Nineteen are on virtual hardware below the minimum. Fourteen have ISOs mounted from a decommissioned datastore. Six sit behind a clustered database configuration that rules out live migration. Four are appliances that will be rebuilt on the destination rather than migrated at all. That list is the single most valuable output of the engagement, because every item on it is a change window that has now been scheduled deliberately instead of discovered at midnight.

Design and build takes four days for the migration tooling, on top of the separate workstream building the destination platform. Runbook development takes three, and produces a wave plan of twenty two waves grouped by application rather than by cluster, sequenced so that the least critical systems go first and the team builds confidence on workloads nobody will escalate about.

Execution runs across fourteen weeks, constrained not by throughput but by the two change windows available each week and by how many application owners can be persuaded to validate on a Thursday evening. Total execution effort is roughly twenty six days spread across those fourteen weeks. Decommissioning and handover takes a further three days.

The total is around forty two consultancy days across five months. The number that moves it most is not the workload count, it is that forty three item remediation list. On an estate with four remediation items instead of forty three, the same six hundred workloads would come in nearer thirty days and three months.

Building the Internal Business Case

Most infrastructure teams reading this already know the migration has to happen. The task is getting the budget approved, which means translating a technical necessity into a financial argument. Four lines tend to do most of the work.

• Cost of the overlap period. Every month spent running both the legacy estate and the new platform carries duplicated licensing, support, power and operational attention. This is the strongest argument for adequate resourcing, because it shows that a slow migration is more expensive than a properly staffed one rather than cheaper.
• Cost of delay against support deadlines. Where a support boundary is approaching, quantify what extended support or accepted risk costs per month past it. That figure converts an abstract deadline into a number a finance director can weigh.
• Cost of the alternative discovery. Remediation found during execution costs a change window, a wave slot and the goodwill of an application owner. Estimate what one of those costs in your organisation and multiply by the number of surprises a thin discovery is likely to leave behind.
• Decommissioning return. The saving from switching off the source environment is real and is usually the largest single line, but it only arrives when the environment is actually switched off. Tie it explicitly to the decommissioning phase so that phase does not get cut when the project runs late.

What tends not to persuade anyone is a list of technical benefits. Simplified lifecycle management and improved operational consistency are genuine outcomes and they are difficult to price. Lead with the cost of not doing it and use the technical benefits as support.

Scoping Checklist: Complete This Before You Talk to Anyone

Every item here makes a quote more accurate and cheaper. Arriving at a scoping call with these answers typically shortens the process by two weeks and improves the number you get.

Estate

• Total workload count, with a breakdown by cluster and by vCenter
• Current vSphere and ESXi versions across the estate, including anything not on the standard build
• Total provisioned and used storage, with the storage platform behind it
• Rough split between production, test and development
• Any workloads already known to be unusual: clustered databases, Fault Tolerance, licensing dongles, physical device dependencies

Destination

• Whether the VCF environment exists, is being built, or has not been started
• Target VCF version and which workload domains are planned
• Hardware position: reusing existing servers, refreshing, or a mix
• Storage design on the destination and whether policies have been defined

Constraints

• Bandwidth between source and destination, and whether it is dedicated or shared
• Whether workloads can be re-IPed, decided per application rather than as a blanket answer
• Change control process and typical lead time for a change window
• Immovable business dates: financial period ends, seasonal peaks, audit windows
• Any contractual or licensing deadline driving the timeline

Ownership

• Named application owners for each significant system, and confirmation they know this is coming
• Who signs off a completed wave
• Who owns backup, monitoring and security integration on the destination
• Who will operate the platform after handover, and what their current VCF experience is

Where These Engagements Go Wrong

Buying execution without buying discovery. It looks like a saving because discovery is a visible line item and remediation is not. The work does not disappear, it simply moves from a planned phase into an unplanned one, at a worse time and a higher rate.

Quoting from a spreadsheet nobody has validated. Inventory exports age badly. A workload list that is six months old will be wrong in both directions, and both directions cost money.

Treating the destination build as out of scope without saying so. If the VCF platform is not ready, the migration cannot start, and the migration partner is not usually the one who can fix that.

No definition of done at the wave level. Without written validation criteria and a named signatory, waves accumulate in a state of nearly finished and the project has no reliable measure of progress.

Underestimating application owner availability. The technology can run four waves a week. The business can absorb one. Plan against the smaller number.

Leaving the source environment running indefinitely. Every month the legacy estate stays powered on is a month of licensing, support, power and risk that the business case assumed would stop. Decommissioning is part of the return, not an afterthought.

Frequently Asked Questions

How long does a VCF migration take?

For a mid-sized estate of a few hundred workloads, expect roughly thirty to sixty days of effort spread across three to five months of calendar time. The gap between those two figures is change windows and application owner availability, not technical throughput.

Can we do this ourselves?

Technically yes, and some teams do it well. The realistic question is repetition: most internal teams will run one VCF migration ever, which is not enough to build instinct for the failure modes. Where in-house delivery usually works is with external design and audit support and internal execution, which keeps the knowledge inside the organisation and puts the expensive decisions in experienced hands.

What is the single biggest cause of overrun?

Remediation work discovered during execution rather than during discovery. Every workload that turns out to be ineligible mid-wave costs a change window and a stakeholder conversation, and those compound quickly across a large estate.

Should the destination platform build and the migration be one engagement or two?

Either can work, but they should be one commercial relationship or have an explicitly defined interface between them. The failure mode with two suppliers is that the migration partner inherits a platform built to assumptions they would not have made, and neither party owns the gap.

How do we handle workloads that cannot tolerate downtime?

Live migration mechanisms exist and handle this well, at the cost of higher licensing tiers and more bandwidth. The scoping question is not whether it is possible but how many workloads genuinely need it, because using near zero downtime migration on systems that could tolerate ten minutes consumes capacity that the truly sensitive systems need.

What should we do first if we have a deadline approaching?

Discovery, immediately, even before the commercial conversation is settled. It is the smallest piece of work with the largest effect on everything downstream, and its output is useful regardless of who ultimately delivers the migration.

Does Consult Circle deliver the destination platform as well as the migration?

Yes. We design and build VCF environments and we run the workload migration into them, as one engagement rather than a handover between teams. We are equally happy to migrate into a platform somebody else built, provided we can review it first.

Where Consult Circle Fits

We run VMware migrations into VCF as continuous work rather than as an occasional project. That matters mostly at the discovery stage, because the value of an audit is proportional to how many previous estates the person running it has seen. We know what tends to be hiding in a ten year old vSphere environment, and we would rather find it in week two than in wave six.

Engagements run from a fixed discovery piece through to full lifecycle delivery including decommissioning and handover. If you already have a plan and want it stress tested before you commit budget to it, we do design reviews as a standalone piece of work as well.

Related Guides in This Series

• How to Migrate to VCF Using HCX: A Step by Step Walkthrough from Site Pairing to Cutover
• vSphere to VCF Migration and Upgrade Paths: In-Place, Side-by-Side or Greenfield
• VCF Migration Services for vSphere 7 and 8 Estates: What Changes After End of Support
• The Complete VMware HCX Migration Checklist: 70 Checks Before, During and After Cutover
• VMware HCX Migration Problems and How to Fix Them: Service Mesh, Network Extension and Failed Transfers
• VMware Cloud Foundation 5.x vs VCF 9.x: Key Differences, Architecture Changes and Upgrade Considerations
• Migrating from Legacy vSphere to VMware Cloud Foundation (VCF) Using HCX