Cloud Migration Consultants: Comparing Discovery, Migration and Ongoing Support Fees

Cloud migration consultants can quote very different amounts because they assume different starting points and different definitions of completion. Moving a workload is only part of making it operable, secure and supportable in a new environment. This guide helps UK organisations compare consulting proposals. It does not recommend a cloud platform or claim that migration will automatically reduce costs. The useful comparison connects discovery, technical changes, business acceptance and ongoing responsibility to the actual services the organisation needs to run.

Start with discovery and dependencies

Inventory applications, data, infrastructure, interfaces and the people responsible for them. Identify business criticality, known constraints and existing licences or contracts. Ask the consultant what discovery it will perform and what information you must supply. A quote based only on server count may miss dependencies that determine migration effort. Discovery should produce a usable map and explicit assumptions, rather than a presentation that repeats the original inventory without identifying what could block or complicate the proposed move.

Questions to ask about Cloud Migration Consultants

Ask how the team evaluates different approaches: retaining, replacing, restructuring or moving a workload with limited change. The NCSC notes that treating cloud simply like another data centre can leave important responsibilities unresolved. A lift-and-shift approach may be appropriate in some circumstances, but it should have a stated purpose and known limitations. Have the consultant explain why its recommendation fits each workload, including the cost and operational consequences of leaving technical changes for a later project.

Define the target environment and responsibilities

Request a design covering identity, access, networking, logging, backup and other required foundations. Ask which controls the platform supplies and which the customer or consultant must configure and operate. The cloud shared responsibility model varies with the chosen service. A provider running infrastructure does not automatically take responsibility for every application or data decision. Put ownership into the proposal so the business knows who will maintain the environment after the migration team has completed its agreed work.

Consider data location, contractual obligations and sector requirements with appropriate advisers. Ask how the consultant handles sensitive information, privileged access and subcontractors. If the proposal relies on existing cloud subscriptions or partner arrangements, identify the contracting party and billing relationship. The organisation should retain access and records needed to operate independently. Convenience during deployment should not lead to an unclear ownership structure in which critical accounts, configuration or documentation can only be reached through one departing consultant.

Compare migration, testing and cutover scope

Ask for a plan covering pilot moves, data transfer, validation, business acceptance and rollback. Identify permissible downtime and the conditions that trigger a decision to stop or reverse a cutover. A copied server is not proof that the business service works. Test integrations, permissions, performance and recovery using agreed criteria. Ask who supplies test cases, who signs off results and how unresolved defects affect completion. Those responsibilities should be priced rather than left as assumptions about what customer staff will do.

Discuss how changing data is handled between trial and final migration, and how completeness is checked. Identify transfer costs, temporary duplicate environments and any limits on migration tooling. Where software licensing changes in the target environment, obtain appropriate confirmation instead of assuming existing rights transfer. A technically successful move can still be commercially unsatisfactory if licences, support or operating costs are unresolved. Include these dependencies in the plan and make important approvals visible before the final production date is committed.

Four-part decision guide: Cloud Migration Consultants

Budget for the service after migration

Separate consulting fees from cloud consumption, licences, network charges and support. Request a cost model using realistic workload and storage assumptions, with a plan for monitoring usage after launch. Do not accept a saving forecast that compares a fully supported existing service with an incomplete cloud estimate. Ask which optimisation tasks are included and when they occur. Some costs only become clear from operation, so agree who reviews actual usage and how changes are authorised.

Compare proposals on deliverables, staffing, assumptions, acceptance and handover. Request documentation, operational training and a defined period of post-cutover support. Ask about the cost of unresolved issues and work beyond the original scope. A good engagement leaves the organisation with a functioning service and clear ownership of its continuing obligations. The success measure is a supported business outcome with understandable costs and recovery arrangements, rather than a migration counter showing that every original server has been moved to a different address.

Is lift and shift always the cheapest approach?

It may reduce some initial changes while preserving operational or cost problems. Ask for a workload-specific explanation and a complete cost model. Compare the immediate migration effort with the continuing requirements of the resulting environment.

Does the cloud provider manage application security?

Responsibilities depend on the service model and configuration. Identify which tasks belong to the provider, customer and consultant. Record ownership explicitly instead of assuming that moving infrastructure transfers every security and availability obligation.

What should handover include?

Request access arrangements, architecture records, configuration, monitoring, recovery procedures and staff training, with named owners. A completed data transfer is not a sufficient handover if the organisation cannot operate or troubleshoot its own service afterwards.