VMware Cloud Director Migration Services: Scoping and Pricing a VCD to VCF Automation Programme

VMWARE CLOUD DIRECTOR MIGRATION SERVICES

What a provider migration engagement actually contains, why tenant count predicts cost better than workload count, and how to read a proposal before you sign it.

Migrating a service provider off Cloud Director is priced differently from migrating an enterprise off vSphere, and proposals that fail to reflect that are usually the cheap ones. The reason is straightforward. In an enterprise migration, the constraint is change windows. In a provider migration, the constraint is other companies: their availability, their engineering capacity, their contracts and their willingness to be moved.

This guide sets out what a complete engagement contains, what actually drives cost, how the common pricing models behave when a programme runs long, how to split the work between your team and a partner, and the questions that separate a plan from a brochure. It is written from the delivery side, which means it includes the parts that are awkward to raise in a sales meeting.

If you want the technical picture rather than the commercial one, the construct mapping and migration tooling are covered separately. This guide is for the person who has to build the business case and choose who delivers it.

What this guide covers

• What a complete engagement contains
• The phases and what each one produces
• What actually drives cost in a provider migration
• Pricing models, and how each fails
• Splitting the work between your team and a partner
• The parallel running cost nobody budgets for
• How to read a proposal, and a scoping checklist

1. What a Complete Engagement Contains

Migration means different things to different suppliers, and the gap between the narrowest and broadest reading is usually larger than the price difference between two proposals. Six bodies of work make up a complete programme, and it is reasonable to buy some and not others provided you know which ones you are not buying.

• Assessment and tenant discovery. The Environment Assessment Tool run and interpreted, plus a tenant inventory covering organisation and workload counts, API integration usage, contractual constraints and addressing requirements.
• Construct mapping and design. How organisation virtual data centres, networking, storage and RBAC are expressed in VCF Automation. This is design work and it is where most of the intellectual effort of the programme sits.
• Platform build. Standing up VCF Automation, integrating identity, monitoring, backup and metering, and validating it before a single tenant depends on it.
• Tenant migration execution. The per-tenant work: scheduling, migration, validation, sign-off and the conversations around each.
• Tenant transition support. Communication planning, documentation rewriting, service desk enablement and support for customers whose integrations need rework. Frequently omitted and frequently the difference between a smooth programme and a fraught one.
• Decommissioning. Cloud Director retired, capacity reclaimed, parallel metering wound down, documentation handed over.

The fifth item is the one to check for specifically. An engagement that covers everything except tenant transition leaves you owning the hardest conversations without support, at exactly the point when your team is busiest.

2. Phases and Deliverables

Table 1 - Phases, typical effort and expected deliverables.

The design phase is the one to protect. It is comparatively cheap, it happens before customer commitments have been made, and every shortcut taken in it becomes a pattern replicated across every tenant in the estate.

3. What Actually Drives Cost

Tenant count, and tenant concentration

Tenant count scales the execution phase almost linearly, because each tenant needs its own scheduling, migration, validation and sign-off regardless of size. Twenty tenants is a programme. Two hundred is a different programme with identical technology. Concentration matters as much: if three customers represent most of your revenue, their timelines effectively become the programme timeline.

Integration depth

This is the strongest single predictor and the one most often missing from a scoping conversation. A tenant who has automated against the Cloud Director tenant API cannot simply be migrated. Their integration needs rework, that work sits with them, and it competes with their own priorities. Ten such tenants can add months to a programme that would otherwise be measured in weeks.

Addressing requirements

Whether tenant addresses must be preserved changes the design and the effort substantially. Preservation is achievable with deliberate work around IP Spaces and External IP Blocks. Re-addressing is technically simpler and organisationally far more expensive, because it converts your infrastructure project into a project for each affected customer.

Contractual complexity

Notice periods, change control obligations, service credits and any commitment that references the platform by name. Some provider agreements make a platform change a formal variation requiring legal review, which adds elapsed time that no amount of engineering resource shortens.

Estate age and non-standard configuration

A Cloud Director estate that has been running for eight years contains arrangements made for customers who have left, extensions built for requirements that lapsed, and organisation virtual data centres carved around hardware that was decommissioned years ago. Each of these is a decision somebody has to make during design.

4. Pricing Models and How Each Fails

Table 2 - Pricing models and their failure modes.

The pattern that works most reliably for providers is a small time and materials assessment, then a fixed price for design and platform build scoped from what the assessment found, then per-tenant pricing banded by complexity for execution. Banding matters: a single per-tenant rate across a mixed estate is either too expensive for the simple tenants or loss-making on the complex ones, and both outcomes damage the relationship.

Whichever model you use, agree explicitly what happens when a tenant delays. Customer-driven schedule slip is the single most likely cause of a provider migration running long, and if the contract is silent on it you will be arguing about it in month five.

5. The Parallel Running Cost Nobody Budgets For

Between the first tenant migration and the last, you are running two platforms. That period is longer than most business cases assume and it carries costs that are real but rarely itemised.

• Infrastructure capacity for both platforms, at least until enough tenants have moved for reclamation to begin.
• Licensing and support for Cloud Director alongside the VCF entitlement.
• Parallel metering, including the effort of ensuring billing remains correct while tenants are split across two systems.
• Service desk overhead, because every support interaction begins with establishing which platform serves that customer.
• Operational attention, since two platforms means two sets of patches, monitoring and incidents for a team that has not doubled.
• The opportunity cost of a team occupied by migration rather than by the services you would otherwise be launching.

Quantify this monthly and put it in the business case, because it is the strongest argument for resourcing the programme properly. A migration run slowly to control cost is more expensive than one run at pace, and showing that arithmetic is usually more persuasive than any technical argument for urgency.

6. Splitting the Work

Few providers should outsource all of this and few should attempt all of it alone. The division that works follows who holds the knowledge rather than who holds the skills.

• You own the tenant relationship. Which customers matter, who to call, what they will tolerate, and what their contracts say. No partner can supply this and any partner who says they do not need it will get it wrong.
• You own commercial and contractual decisions. Pricing implications of the new construct model, contract variations, and how the migration is positioned to customers.
• The partner owns construct mapping and design. This is where prior exposure matters most, because the failure mode is faithfully recreating your old model rather than making a technical error.
• The partner owns migration mechanics. Platform build, tooling, execution and the failure modes that only become familiar with repetition.
• Shared: tenant communication. The partner drafts and structures, you send and own it. Customers should hear about a platform change from their provider, not from a consultancy.
• Shared: the pilot. Run it together on your internal tenant, because it is also the knowledge transfer.

7. How to Read a Proposal

These questions expose a thin proposal quickly, and the answers tell you whether the supplier has done a provider migration before or only an enterprise one.

• How is tenant-driven schedule delay handled commercially, and who carries that risk?
• Is tenant transition support included, specifically communication and documentation, or only infrastructure work?
• How is per-tenant pricing banded, and what puts a tenant in a higher band?
• Who identifies tenants with API integrations, and what happens to the timeline when one is found late?
• Is the 10.6.2 upgrade in scope, or assumed to be complete?
• Is parallel metering in scope, and who validates that billing is correct during the split?
• What is the rollback procedure per tenant, and has it been rehearsed rather than documented?
• Who signs off a tenant migration as complete, and what evidence is produced?
• Is Cloud Director decommissioning included, including winding down parallel metering?
• Which named individuals deliver, and are they the people who attended the scoping call?

The first question is the most revealing. A supplier who has run provider migrations will have a considered answer about customer-driven delay, because they have lived it. One who has only done enterprise work will treat the question as a contractual edge case.

8. Scoping Checklist

Platform

• Current Cloud Director version and the gap to the 10.6.2 baseline
• Provider VDC count, and whether the boundaries still reflect current reasoning
• Total workload count and provisioned storage
• Custom extensions, UI plugins and non-standard configuration catalogued
• Existing metering and billing integration documented

Tenants

• Tenant count, with organisation and virtual data centre counts per tenant
• Revenue concentration, so the tenants who set the timeline are identified
• Tenants with Cloud Director tenant API integrations, listed individually
• Per-tenant addressing requirement, established rather than assumed
• Regulatory or assurance obligations by tenant
• Contractual constraints: notice periods, change control, service credits

Constraints and capacity

• Target VCF and VCF Automation version, with the workload mobility implications understood
• Capacity available to build the target platform before reclamation begins
• How many customer-facing migrations your team can run per month alongside business as usual
• Immovable dates: contract renewals, audit periods, seasonal peaks in your tenants' businesses
• Named internal owner for the programme

9. Where These Engagements Go Wrong

Scoping on workload count. It is the number everyone quotes and it predicts almost nothing in a provider migration. Tenant count and integration depth drive the effort.

Buying execution without design. The migration tooling executes a construct mapping. Without one, the programme stalls at the first tenant and the design work happens anyway, later and under pressure.

Omitting tenant transition support. It looks like a saving because it is a soft line item. The work does not disappear, it lands on your team during the busiest phase.

No mechanism for customer-driven delay. Tenants will slip. If the contract does not anticipate it, every slip becomes a commercial conversation instead of a scheduling one.

Ignoring the parallel running cost. It is the largest hidden number in the business case and the strongest argument for adequate resourcing.

Cutting decommissioning. The benefit case depends on switching Cloud Director off. A programme that ends when the last tenant migrates has not delivered the saving it promised.

Frequently Asked Questions

How much does a Cloud Director to VCF Automation migration cost?

It scales with tenant count and integration depth rather than workload count. A provider with twenty straightforward tenants and a provider with twenty tenants where six have deep API integrations will see materially different numbers for the same infrastructure. Get an assessment before asking for a fixed price, because the assessment is what makes the price meaningful.

How long does it take?

Six to eighteen months from decision to Cloud Director decommissioning for a provider with a meaningful tenant base. The variance is explained by tenant count, integration complexity and customer engagement rather than by technology, and the execution phase does not compress by adding engineers.

Can we do this ourselves?

Some providers do, well. The realistic question is repetition: you will do this once, which is not enough to develop judgement about tenant sequencing or how much lead time an integration-heavy customer needs. A common and effective split is external design and assessment with internal execution, which keeps the knowledge in your business.

What is the biggest cause of overrun?

Tenants with Cloud Director tenant API integrations discovered late. Their remediation sits with them, competes with their own priorities, and cannot be accelerated by your programme. Identify them in week one by asking directly rather than inferring from usage data.

Should we price per tenant?

It works if the bands reflect complexity. A single flat rate across a mixed estate is either overpriced for simple tenants or loss-making on complex ones, and both damage the relationship with your supplier partway through a long programme.

What should we do before asking for quotes?

Run the Environment Assessment Tool and build a tenant inventory that records API integration usage and addressing requirements per tenant. Arriving at a scoping conversation with those answers typically shortens the process by weeks and materially improves the number you receive.

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

Yes, as one engagement rather than a handover between teams. We are also happy to migrate into a VCF Automation environment somebody else has built, provided we can review it first, since inheriting a platform built to assumptions we would not have made is the most common source of avoidable difficulty.

Where Consult Circle Fits

We work with service providers on this specific transition rather than on VMware migrations generally, and the distinction matters. The provider version of the problem is dominated by the tenant relationship, so the useful experience is knowing which customers to sequence where and how much lead time an integration-heavy tenant genuinely needs, rather than knowing how the platform installs.

Engagements run from a fixed assessment through design and execution to Cloud Director decommissioning, and we do standalone design reviews where an internal team is running the programme and wants the plan stress tested before the first tenant moves.

Related guides in this series

• VMware Cloud Director to VCF Automation Migration: The Complete Guide for Service Providers
• Using the VCF Automation Migration Tool: Environment Assessment Through to Tenant Cutover
• Mapping VMware Cloud Director Constructs to VCF Automation
• Migrating Tenants Off Cloud Director Without Losing Them
• VMware Cloud Director 10.x vs VCF Automation 9.1: A Feature Parity Comparison for Service Providers
• The Complete VCD to VCF Automation Migration Checklist: 72 Checks for Service Providers
• The VMware Cloud Director API for Day-to-Day Operations: The Calls You Will Actually Use
• VMware Cloud Director Common Errors and Known Issues: Symptoms, Causes and Workarounds