Cloud migration consulting: what you should expect for the money

Buying cloud migration consulting is hard in a specific way: the proposals look alike, the day rates cluster in a narrow band, and the outcome cannot be inspected before it is paid for. What separates engagements is which artefacts they leave behind, and whether those artefacts can be executed by someone who did not write them. This article covers what to expect and what the commercial models reward.

What a cloud migration consulting engagement sells

There are three distinct things a firm can sell under the same heading, and they have different prices and different failure modes.

A decision. Which systems move, in what form, in what order, and what the resulting run cost looks like. The output is a document. Its value depends entirely on how much evidence sits behind each line.

Execution capacity. Engineers who build the landing zone, write the automation, run the waves. The output is a working environment. This is the part that is easiest to specify and easiest to price.

Capability transfer. Your team ends the engagement able to run the next wave without the firm. The output is a change in what your people can do, which is the hardest of the three to write into a contract and the one most often assumed rather than scheduled.

Most engagements are sold as a blend of all three, with the proportions unstated. That is where disappointment originates. A firm optimising for execution capacity will happily migrate systems that should have been retired, because retiring a system is not billable work. A firm selling a decision will produce a document of real quality and then leave, at which point the document meets an internal team with no capacity to act on it. Name the proportions before the scope is written.

The cloud migration assessment and its deliverables

Nearly every engagement opens with an assessment. It is the phase with the widest quality range in the market, because the contract usually names it as a phase with a duration rather than as a set of deliverables. When time runs short, depth is what gets cut, and the shortfall is invisible until execution.

An assessment worth its fee produces these, as named artefacts:

• A disposition per system. Rehost, replatform, refactor, repurchase, retire, retain, with the reasoning recorded and a named owner who agreed to it. A single global answer for the estate is not an assessment, it is a preference.
• A dependency map with an observed source per edge. Derived from network flow capture, database connection audits and scheduled job inventories, not solely from a configuration database. The connections that break a cutover are the ones no register contains.
• A costed target model. Run cost per workload in the target, against the current cost, with the assumptions written down and the sizing basis stated. A number without its assumptions cannot be challenged, which means it also cannot be trusted.
• A wave sequence with constraints attached. Business calendar, licensing positions, data gravity, and the systems that must move together because they share a dataset.
• A register of open questions with owners and dates. The unresolved items are the most useful part of the document. An assessment with no open questions has stopped looking.

Two outputs are common and carry little weight. A maturity score positions you on a scale nobody outside the engagement uses. A generic risk register that could apply to any organisation describes the category of work rather than your estate. Neither can be executed.

We treat the disposition list and the dependency map as the inputs to everything downstream, which is why cloud migration work at DNA Solutions usually begins there rather than at tooling selection. The reasoning behind each disposition choice is set out in our article on cloud migration strategy.

Cloud migration consulting pricing models

Every pricing structure creates an incentive. None of them is dishonest. The problem arises when the incentive points away from the part of the work you most need done.

Fixed price rewards a scope that is fully known at signature. It works well for a landing zone build or a defined wave of well understood systems. Applied to discovery, it rewards finishing early, and discovery finishing early is precisely the failure you are trying to avoid. Expect a change request mechanism, and read how it is triggered.

Time and materials rewards duration. It is the honest choice when the scope genuinely cannot be specified yet, which is often true of the first assessment. It requires you to hold the scope yourself, with a cap and a review cadence, because nothing else in the structure does.

Per workload or per server rewards volume. It makes migration cheap per unit and makes retirement commercially uninteresting. If you use it, decide the disposition list before the unit price applies, so that the systems that should be switched off are removed from the count first.

Outcome or saving based sounds aligned and is difficult to instrument. The measurement baseline becomes the negotiation, and cloud cost baselines move for reasons unrelated to the engagement. It can work where the outcome is a single unambiguous event, such as a named platform decommissioned by a date.

A practical arrangement for a first engagement: time and materials with a cap for the assessment, where the unknowns live, then fixed price per wave once the dependency map exists and the scope is real.

Migration deliverables worth naming in the contract

The difference between a good engagement and an expensive one is often just specificity in the schedule of deliverables. Items worth naming explicitly:

• Infrastructure as code, in your repository, from the first day. Not delivered at the end. An environment built by hand in a console is not reproducible for the rehearsal, the cutover or the rollback, and it cannot be handed over.
• The cutover runbook, per wave, with observed timings. Timings come from a rehearsal. A runbook with estimated durations has not been tested.
• A rollback that has been executed at least once. Written rollback procedures are assumptions. State in the contract that the rollback is demonstrated, not documented.
• Reconciliation evidence. How the target is proven to hold the same data as the source, and the report from a full run.
• Operational handover artefacts. Monitoring dashboards, alert definitions with thresholds, escalation paths, and the list of things that will page someone.
• Named knowledge transfer sessions. With participants from your side listed. Osmosis is not a delivery mechanism.

Who operates the cloud estate after go-live

This is the question that most changes the total cost of a migration, and it is usually asked after the engagement is scoped rather than during.

A cloud estate operated with on-premise habits generates the overspend that a FinOps function is later hired to recover. Static sizing carried over from a purchasing cycle, environments that run overnight and at weekends because they always did, storage that stays on the tier it landed on. None of this is a migration defect. It is an operating model that was never adjusted, and it compounds monthly.

So the engagement needs a defined answer to three things: who holds the run responsibility after hyper-care ends, what they need to be able to do that was not previously part of their role, and how that gap gets closed during the project rather than after it. A firm that has no opinion here is selling execution capacity and describing it as transformation. A firm that proposes to hold the run indefinitely is selling a managed service, which may be the right answer, and should be priced and understood as one rather than arriving by default.

Where cloud migration consulting adds little

Being specific about this is a reasonable test of a firm. Some parts of a migration do not benefit from external help:

• Deciding which business processes matter and when they must not be interrupted. That knowledge is internal and cannot be acquired quickly.
• Naming system owners and getting them to answer. Authority for this does not transfer to a supplier.
• Choosing the primary cloud provider, where a group agreement, a regulatory constraint or an existing skill base has already effectively decided it. Running a formal selection to confirm a settled decision is billable work with no output.
• Long-term platform operations, where an internal team already exists and simply lacks a documented target model.

A proposal that claims value in all of these is describing a scope rather than a judgement.

Reading a cloud migration consulting proposal

A few signals separate proposals quickly, without needing to compare methodologies.

Named seniority against named workstreams. Not a team size, and not a partner biography. Which people, with what background, on which part, for what share of their time. Ask what happens if a named person becomes unavailable.

Specificity about your estate. A proposal written after a serious pre-sales conversation mentions your systems, your constraints, your calendar. One that mentions none of these has been written from a template and will meet your estate for the first time after signature.

A stated position on the hard parts. Data reconciliation, the double-run period, licensing under the target infrastructure, identity. A proposal that is confident everywhere has not looked closely anywhere. Our own view of the items that surface late is in the article on cloud migration challenges.

Exit terms. What you keep if the engagement stops after the assessment. Code, documents, environments and access should be yours by default, in your repositories and your accounts throughout, rather than transferred at the end.

Talk through your cloud migration consulting engagement

DNA Solutions starts with the assessment as a bounded, capped piece of work, and writes its outputs into the contract as artefacts rather than as a duration: dispositions, an evidenced dependency map, a costed target, a wave sequence, and an open-questions register. That document is executable by another party, which is deliberate. It is the part of the engagement that has to survive independently of who delivers the next phase.

From there the waves are priced individually, because by then the scope is known well enough for that to be honest. Our IT consulting practice covers the assessment and target design, and the delivery side runs against the runbook structure described in our article on cloud migration steps. Talk to us.