Quote a cloud migration with numbers you can defend

For pre-sales and bid teams at IT services providers who have to put a unit price on an on-prem-to-cloud migration — per server, per application — and stand behind it.

Engagement type: Solo Pod
Experts: 1 lead · 2 consulted
Hours: ~60
Duration: 3 weeks

What the client needed

A services firm bidding on-prem-to-public-cloud migrations needed effort and price at unit level — per server, per application — for three use cases: workload rehost with minor remediation, application redeploy with infrastructure-as-code and a CI/CD toolchain, and web-app re-platforming to an Azure-native stack.

It also needed the characteristics that sort a migration into small, medium and large, and a view of where generative and agentic AI are now cutting effort by phase.

The brief

The questions on the table

As the client wrote them, lightly shortened. Client and respondents are not named.

Q1
For each use case — rehost, redeploy, web-app re-platform — what is the effort and price per server or per application, and which characteristics make a migration small, medium or large?
Q2
For cloud-native builds, what is the effort per unit — workflow, screen, integration, microservice, API, report, data model — and how does it split across planning, design, build, testing and hypercare? Where has Gen AI changed that split in the last twelve months?
Q3
For application decommissioning, what defines S, M, L and XL, what is the per-application effort, and which activities does it include?
Q4
For re-platforming, what scalar applies to on-prem-to-cloud compared with on-prem-to-on-prem?

The hours

What the work involved

01
Read the bid and the estate
Went through the RFP scope, the customer's application and server inventory, and the clarification questions the bid team had already received. Sorted the estate into the three use cases and marked what the inventory did not say — OS and middleware versions, integration counts, data volumes — and the assumptions we would carry for each gap. Agreed with the bid team which of those had to be confirmed with the customer before submission, and which could be priced as risk.
02
Built the estimating model
One workbook, one sheet per use case. Effort by activity — discovery, remediation, build, migration, testing, cut-over, hypercare — in person-hours per server or per application, with the S/M/L drivers that move each line: server count, integrations, OS and middleware upgrades, data volume. A staffing pyramid and an onshore/offshore mix per use case, so a change in mix re-prices the line on its own. Gen AI and agentic-AI effects entered as explicit factors per phase, where they can be seen and challenged, not buried in the rates.
03
Set the ranges and the assumptions behind them
Low, likely and high for every unit, with the assumption that drives the spread written next to it. Flagged the lines where the customer's answers would swing the total most, so the bid team knew exactly what to ask in the clarification round. Cross-checked the likely case against the expert's own delivery experience on comparable programmes, and against two further cloud-pricing experts for the Azure re-platform and the re-platform scalar.
04
Wrote the pricing notes
Which units to price fixed (rehost, redeploy) and which as T&M with a cap (re-platform where remediation is unknown). Where to hold contingency and how much, by use case. How to present per-unit prices so the customer's procurement team can compare like for like across bidders — and the questions procurement usually asks about these numbers, with the answers that hold.
05
Working sessions and the final review
Two 90-minute sessions with the bid team to walk the model, re-set the ranges with the customer's clarifications, and decide what to carry as assumption and what as exclusion. A final review of the submitted numbers against the model two days before the deadline, with the remaining risks and the sentences to put in the assumptions schedule.

Deliverables

What the client received

The estimating workbookExcel, one sheet per use case: unit effort per server and per application, S/M/L drivers, phase split, pyramid and shoring mix, all assumptions editable. Yours to keep and re-use on the next bid.
Effort and price rangesLow, likely and high per use case, with the single assumption that drives each spread named beside it.
A staffing pyramid per use caseRoles, grades and onshore/offshore mix, so the delivery team can be costed from the same sheet.
Pricing notesWhat to price fixed and what as T&M, where to carry contingency and how much, and how to lay out per-unit prices for procurement.
Gen AI phase factorsWhere effort drops, by how much, and on what basis — so the bid can claim it without over-claiming.
Open risks and clarificationsA one-page list of what still needs the customer's answer, and the sentences to carry in the assumptions schedule if it never comes.
Two working sessions and a final review90 minutes each with the bid team, then a review of the submitted numbers against the model before the deadline.

The terms

What an engagement like this costs

You buy hours in blocks and can change the expert at the end of any block, at no extra cost. Longer projects run in stages: pause after a block, pick up the next stage when you are ready.

Pricing in full →

Rate band: $65–$250 /hr; Senior specialists can be up to $500
Hour blocks: 1 · 2 · 5 · 10 · 20 · 50 · custom
This engagement: Solo Pod · ~60 hours · 3 weeks

Have a migration to price?

Describe what you need

For example: “We are bidding a 200-server move to Azure and need unit effort and price by use case, with S/M/L rules.”

We aim to come back with matched experts within 24 to 72 hours.