A cloud migration RFP is the document that decides whether you receive comparable, honestly priced proposals or eleven glossy PDFs that cannot be scored against one another. It is the single highest-leverage artefact in the whole procurement, and it is usually written last, in a hurry, by whoever has capacity.
That is backwards. The quality of the responses you get back is almost entirely determined by the quality of the information you put in. Suppliers price risk, and every question you leave unanswered becomes a contingency line in their number. A vague cloud migration RFP produces vague bids, wide price ranges, and a shortlist you cannot defend to a finance director.
This guide is a working cloud migration RFP template. It walks the document section by section — company context, measurable objectives, current-state inventory, technical and security requirements, commercial questions, scoring weights and timeline — and explains what each section is actually for. It is written for UK businesses running a competitive tender without a dedicated procurement function, alongside our wider cloud adoption work and the cloud migration business case that should already be approved before you issue anything.
Table of contents
- What a cloud migration RFP is and what it actually buys you
- When to issue a cloud migration RFP — and when not to
- The cloud migration RFP template: section by section
- Company context, objectives and success criteria
- Scope and current state: the cloud migration RFP section that decides bid quality
- Technical requirements to put in your cloud migration RFP
- Security, compliance and data protection requirements
- Cloud migration RFP commercial questions that stop surprise bills
- Scoring and evaluation: how to compare cloud migration RFP responses
- Timeline and running the process
- Red flags in cloud migration RFP responses
- Frequently asked questions about the cloud migration RFP
- References
What a cloud migration RFP is and what it actually buys you
A request for proposal is a structured invitation to bid. You describe the problem, the constraints and how you will judge the answers; suppliers describe their solution, their team and their price. That is the mechanical definition, and it undersells what the document does.
The RFP is a filter, not a formality
The real function of a cloud migration RFP is to make suppliers who have not understood your estate visibly unable to answer. A generic capability deck can survive a sales meeting. It cannot survive a question that asks how the bidder will migrate a specific 800GB SQL Server database with a four-hour maximum outage window and a dependency on an on-premises licence server.
What a good response tells you that a sales call never will
Written responses are comparable, attributable and durable. Six months into delivery, when a supplier claims something was out of scope, the cloud migration RFP and its response are what you both read. A recorded demo and a warm relationship with an account manager give you none of that.
Where the RFP sits in the wider procurement process
Sequence matters. The business case establishes that migrating is worth doing; the current-state assessment establishes what you actually own; the cloud migration RFP asks the market to price the work. Skipping straight to the RFP without the first two produces a document full of “to be confirmed”, which suppliers price defensively.
The cost of getting it wrong
A poorly specified tender does not usually fail loudly. It produces a plausible winner, a signed statement of work, and then a series of change requests through delivery as the assumptions that were never written down turn out to be wrong. That is the failure mode this cloud migration RFP template is designed to prevent.
When to issue a cloud migration RFP — and when not to
Not every piece of work deserves a full tender. Running one costs your team perhaps four to six weeks of effort, and it costs each bidder considerably more, which is why serious suppliers decline invitations they judge to be poorly run.
The threshold that justifies the effort
As a rough rule, a competitive cloud migration RFP earns its keep above roughly £50,000 of professional services, or wherever the decision is strategically irreversible for three years or more. Below that, a scoped request for quotation against a clear specification is faster and gets you the same answer.
When a shorter instrument is the better choice
If you do not yet know what good looks like, issue a request for information first. An RFI is cheap, non-binding, and tells you what the market thinks is possible. Issuing a cloud migration RFP to discover your own requirements wastes everyone’s time and teaches bidders that your process is unstructured.
Regulated and public sector buyers
Public bodies and regulated firms have procurement rules that override any cloud migration RFP template — thresholds, mandatory notices, standstill periods and published evaluation criteria. Financial services firms also carry outsourcing obligations that require exit planning and audit rights to be addressed in the tender itself, not negotiated afterwards.
Signs you are not ready to issue yet
If nobody can produce an application inventory, if the budget has not been approved, or if the executive sponsor is not identified, stop. A cloud migration RFP issued into that vacuum produces responses priced for maximum uncertainty, and you will not be able to explain the variance between them.
The cloud migration RFP template: section by section
The document below has eleven sections. Keep it to twenty-five pages or fewer. Every page you add reduces the number of good suppliers who will bid, and long tenders correlate strongly with padded, boilerplate responses.
The eleven sections every template needs
The structure matters less than the completeness. What follows is the section list we use, what each must contain, and the specific failure it prevents.
| Section | What it must contain | Failure it prevents |
|---|---|---|
| 1. Introduction and context | Who you are, sector, size, why now | Bidders pitching the wrong size of solution |
| 2. Objectives and success criteria | Measurable outcomes with target figures | Delivery that finishes without anyone agreeing it worked |
| 3. Scope and current state | Application inventory, infrastructure, data volumes | Contingency padding and mid-project change requests |
| 4. Technical requirements | Target platform, migration strategy, non-functionals | Incomparable solutions you cannot score side by side |
| 5. Security and compliance | Data residency, certifications, testing, shared responsibility | Security bolted on after the design is fixed |
| 6. Service and support model | Run-state responsibilities, hours, escalation | A migration that lands with nobody owning it |
| 7. Commercial requirements | Pricing model, rate card, assumptions register | Headline prices that are not comparable |
| 8. Delivery approach and team | Method, named roles, CVs, location, availability | Being sold the A-team and delivered the B-team |
| 9. Exit and handover | Documentation, knowledge transfer, exit assistance | Lock-in to the implementation partner |
| 10. Evaluation criteria | Published weightings and scoring scale | Unchallengeable, subjective decisions |
| 11. Process and timetable | Dates, question window, format, contact | Late, non-compliant or malformed bids |
How prescriptive the document should be
Specify the problem tightly and the solution loosely. Fixing the outcome, the constraints and the evaluation method gives you comparability; fixing the architecture in advance removes the reason for asking experienced suppliers in the first place. The best cloud migration RFP responses tell you something you did not know about your own estate.
Give bidders a response template
Issue your cloud migration RFP with a response form, a word limit per question, and a requirement to answer in that order. Free-format submissions are unscoreable at any volume, and the discipline of a limit reveals which bidders can actually be concise about your specific problem.
Company context, objectives and success criteria
The opening sections cost you a page and are the most commonly wasted part of any cloud migration RFP. Written well, they tell a supplier what kind of engagement this is before they read a single requirement.
Write the business objective, not the technology
“Migrate 42 servers to Azure” is an activity. “Exit the Manchester data centre before the lease expires in September, without extending the co-location contract” is an objective — and it immediately tells a bidder which dates are immovable and which trade-offs are acceptable.
Define success in numbers
Every objective in a cloud migration RFP needs a target and a measurement method. Reduce infrastructure run cost by 25% within twelve months of cutover. Achieve a four-hour recovery time objective for tier-one applications. Cut deployment lead time from three weeks to two days. Suppliers can design against numbers; they cannot design against “improve performance”, and your digital strategy should already contain most of them.
Disclose your constraints up front
Budget envelope, immovable dates, headcount, existing licence agreements, change freezes, union or works-council consultation, sites you cannot take offline. Every constraint you hide surfaces during delivery as a change request. Publishing a budget range is not weakness — it stops suppliers designing a solution you were never going to buy.
Name the decision-makers and the process
State who evaluates, who signs, and how many stages there are. Bidders allocate their best people to tenders that look decisive. An anonymous cloud migration RFP with no named sponsor reads like an information-gathering exercise, and the strongest suppliers will treat it as one.
Scope and current state: the cloud migration RFP section that decides bid quality
If you read one section of this cloud migration RFP template twice, read this one. The current-state annex is where accurate pricing comes from, and it is the section buyers most often skip because assembling it is genuine work.
The application inventory
Your cloud migration RFP needs this for every application in scope: name, business owner, criticality tier, user count, technology stack and version, hosting location, licensing model, integrations, data classification, acceptable outage window, and whether the vendor supports it in cloud. Even a partially complete inventory beats none, provided you say clearly which fields are unverified.
Infrastructure and the data estate
Server counts, operating system versions, CPU and memory allocations, actual utilisation rather than provisioned capacity, storage volumes, database engines and sizes, backup regime, and network topology including any circuits with notice periods. Data volume drives migration duration more than any other single figure, so measure it rather than estimating.
Integrations and dependencies
The dependency map is what turns a straightforward migration into a difficult one, so give it an annex of its own in the cloud migration RFP. Document every interface to a third party, every scheduled job, every hard-coded IP address or hostname, every on-premises licence server, and every system that authenticates against your directory. This is where the unpleasant surprises live.
What happens when you leave this vague
Suppliers cannot price what they cannot see, so they do one of two things: pad the estimate heavily, or exclude the unknowns and raise change requests later. The first costs you money immediately, the second costs you more later. Both are rational responses to a thin cloud migration RFP.
Technical requirements to put in your cloud migration RFP
This is the longest section and the one where buyers most often over-specify. Ask for the target state, the route to it, and the evidence that the route works. Leave the detailed architecture to the response.
Target platform and landing zone
State your platform preference in the cloud migration RFP and say whether it is negotiable. Ask how the bidder will build the landing zone: subscription or account structure, network design, identity integration, policy guardrails, logging and monitoring baseline. A migration into an unstructured environment creates governance debt that takes years to repay, which is exactly what an Azure landing zone implementation checklist exists to prevent.
Migration strategy per application
Require a proposed strategy for every application in the inventory, with a justification. The recognised options are usually described as the six Rs, and a credible cloud migration RFP response will use a mix rather than proposing one approach for everything.
| Strategy | What it means | Effort | Cloud benefit realised | Best for |
|---|---|---|---|---|
| Rehost | Lift and shift to virtual machines | Low | Low | Date-driven data centre exits |
| Replatform | Move to managed database or app service | Medium | Medium | Databases and web tiers |
| Refactor | Re-architect for cloud-native services | High | High | Strategic, actively developed apps |
| Repurchase | Replace with a SaaS product | Medium | High | Commodity functions such as email or CRM |
| Retire | Switch off and archive the data | Low | Cost avoided entirely | Duplicated or unused systems |
| Retain | Leave in place for now | None | None | Regulatory or latency-bound workloads |
Non-functional requirements
Availability targets, recovery time and recovery point objectives per tier, performance baselines, capacity headroom, retention periods and supported browser or client versions. If you have never set these, our guide to RTO and RPO is the place to start, because a resilience target invented during a tender is usually wrong in both directions.
Cutover, testing and rollback
Your cloud migration RFP should ask for the cutover plan shape, not the finished runbook: wave sequencing, rehearsal approach, data synchronisation method, the acceptance tests that gate each wave, the rollback trigger and the rollback mechanism. A bidder who cannot describe how they would reverse a failed cutover has not done many of them.
Automation and infrastructure as code
Require that the target environment be built as code and handed to you in your own repository. Manually clicked infrastructure is undocumented by definition, and it is the fastest route to being unable to change anything without the implementation partner. Ask which tooling, which state-management approach, and what the DevOps handover looks like.
Security, compliance and data protection requirements
Security requirements belong in the cloud migration RFP itself, not in a separate review after the architecture is fixed. Retrofitting controls is expensive, and a supplier who was never asked will not have priced them.
Make shared responsibility explicit
Cloud providers secure the platform; you remain responsible for configuration, identity, data and access. Have the cloud migration RFP require a responsibility matrix from each bidder covering patching, backup, identity administration, key management, logging and incident response, with an owner named for every line — you or them, during migration and afterwards.
Data residency and UK GDPR
State where data may be stored and processed, whether any transfers outside the UK are permitted, and on what safeguards. Require the bidder to confirm their processor obligations and to name every sub-processor. This is a contractual matter, so it needs to be visible during evaluation rather than discovered in legal review.
Certifications and evidence
A cloud migration RFP should ask for Cyber Essentials Plus as a minimum, and ISO 27001 or equivalent where the engagement touches sensitive data. Ask for the certificate scope, not just the badge — a certification covering only the supplier’s head office tells you nothing about the delivery team working in your environment.
Security testing and hardening
Specify who performs penetration testing after migration, who pays for it, and how findings are remediated and re-tested. Require a hardening baseline for the new environment and ask how it will be monitored for drift, which is precisely what a cloud security posture assessment measures once you are live.
Access management during the engagement
Third-party engineers will hold privileged access to your environment for months. Set out the joiners and leavers process, multi-factor requirements, whether access is time-bound and just-in-time, how sessions are logged, and how access is revoked at the end. This belongs in the tender because it constrains how the supplier staffs the work.
Cloud migration RFP commercial questions that stop surprise bills
The commercial section is where comparability is won or lost. Two bidders can quote identical totals for completely different scopes, and only a structured pricing schedule reveals it.
Ask for a breakdown, never a single number
Every cloud migration RFP should require pricing split by workstream — discovery, landing zone build, migration waves, testing, cutover, hypercare, run — plus a day-rate card by role, an assumptions register, and a change-control mechanism with agreed rates. A single figure is not a price, it is a negotiating position.
The pricing models compared
Which model your cloud migration RFP requests materially changes who bids and how they behave. Most substantial migrations are best served by a hybrid: fixed price for the well-understood phases, capped time and materials for the parts that depend on discovery.
| Pricing model | Buyer risk | Supplier behaviour it encourages | Use when |
|---|---|---|---|
| Fixed price | Low on cost, high on change | Defends scope tightly, prices contingency in | Scope is genuinely well understood |
| Time and materials | High on cost, low on change | Flexible, but no incentive to finish early | Discovery and genuinely unknown work |
| Capped time and materials | Moderate, shared | Balanced; cap tends to become the price | Most migration waves |
| Milestone-based | Low, tied to acceptance | Focus on demonstrable completion | Wave-structured delivery |
| Outcome-based | Low if measurable | Aligned, but disputes over measurement | Cost-reduction targets you can audit |
The migration bill is not the cloud bill
Ask separately for a twelve-month projected consumption forecast for the target platform, with the assumptions behind it. The professional services cost is finite; the run cost is forever, and the two are frequently quoted by different teams who have not spoken. Whoever wins should also explain how they will handle cloud cost allocation and chargeback once workloads land.
Where migration budgets actually overrun
Ask about the categories below explicitly and you remove most of the variance between bids. The pattern is consistent: overruns come from work that was real but unpriced, not from work that was priced badly.
Exit rights belong in the tender
Ask what happens at the end: documentation standards, credential handover, repository ownership, exit-assistance rates, and the notice period. A supplier who negotiates this cheerfully at bid stage will be straightforward to leave. One who defers it to contract negotiation is telling you something, and our cloud exit strategy guide covers the platform-level version of the same problem.
Scoring and evaluation: how to compare cloud migration RFP responses
Publish your evaluation method inside the cloud migration RFP itself. It disciplines your own panel, it improves the responses you get, and in a regulated or public procurement it is usually mandatory.
Publish the weightings
A defensible split for a substantial migration is roughly 40% technical solution, 25% delivery approach and team, 25% price, 10% security and compliance — adjusted for context. Weighting price above 30% reliably selects the supplier who understood the least, because the cheapest bid is usually the one that missed the most scope.
Use a scale with written descriptors
A zero-to-four scale with a written definition per point stops evaluators drifting apart. Zero means no response, one means significant concerns, two means meets the requirement, three means exceeds it with evidence, four means exceptional with directly comparable proof. Without descriptors, one evaluator’s “3” is another’s “1” and moderation becomes an argument.
Score independently, then moderate
Every evaluator scores alone before the panel meets. Group scoring converges on whoever speaks first and produces a consensus nobody can later reconstruct. In moderation, record the rationale for each agreed score — that record is your audit trail and your feedback to unsuccessful bidders.
Score the demonstration and the references too
Reserve marks for the clarification session and for reference calls with organisations of similar size and sector. Ask referees what went wrong and how it was handled; every project has problems, and the answer to that question tells you more than the entire written response.
Normalise price before you score it
Convert every bid to the same basis — same duration, same assumptions, same inclusions — before applying the price weighting. Bids that exclude hypercare, testing or run cost look cheaper only because they are incomplete, and the normalisation step is where a good cloud migration RFP evaluation earns its keep.
Timeline and running the process
A tender that drifts loses the good bidders first, because they have other opportunities. Publish dates and hold them.
A realistic cloud migration RFP timeline
Six to eight weeks from issue to award is achievable for a mid-size migration if the current-state pack is ready before you start. Anything faster produces thin responses; much slower and the market assumes the project is not real.
Run the clarification window properly
Set a deadline for questions, answer them in writing, and circulate every question and answer to all bidders anonymously. Answering privately advantages one supplier and invites a challenge. The clarification log also becomes part of the contract, so write the answers as carefully as the original document.
Keep the bidder list short
Three to five serious bidders is right. More than five and your evaluation panel cuts corners; fewer than three and you have no competitive tension. Sending a cloud migration RFP to twelve suppliers is not thoroughness, it is a way of guaranteeing that the best ones decline.
Debrief the losers
Give unsuccessful bidders a short written debrief against the published criteria. It costs an hour, it is required in regulated procurements, and it is why good suppliers bid for your next tender. Treat vendor management as a long game rather than a series of transactions.
Red flags in cloud migration RFP responses
Some warning signs are visible before you shortlist. These are the ones worth scoring down explicitly.
Boilerplate that never mentions your estate
If a response could be sent to any buyer with the name changed, that is your answer. A serious bidder quotes your application names, your outage windows and your data volumes back at you, and asks pointed questions about the parts of your inventory you marked unverified.
No named team, or a team that vanishes after award
Have the cloud migration RFP require CVs, roles, allocation percentages and start dates for the actual individuals. Then put a key-personnel clause in the contract. The gap between the people who present at the demonstration and the people who show up on day one is the most common complaint in post-migration reviews.
A price well below the field
If one bid is 40% under the others, the difference is almost always scope. Find the missing scope before you get excited, and ask directly which of the numbered requirements are excluded. An honest supplier will tell you; a change-request business model will not.
Vague answers on exit and handover
Hesitation here predicts the whole relationship. So does a refusal to commit to infrastructure as code, to hand over repositories, or to document to an agreed standard. All three are how a supplier converts a project into an annuity, whether or not that is the stated intention.
No assumptions register and no questions asked
A bidder who submits no clarification questions has either done this exact migration before or has not read the document. It is nearly always the second. Similarly, a response with no assumptions register is not simpler than its competitors — it has simply moved the assumptions somewhere you cannot see them.
An answer that ignores the run state
The migration ends; the estate does not. Responses that stop at cutover, with nothing on hypercare, monitoring, cost governance or the operating model, are pricing the fun part only. Ask what happens in month four, and compare it against what managed IT services would cost you as a permanent arrangement.
Frequently asked questions about the cloud migration RFP
How long should a cloud migration RFP document be?
Fifteen to twenty-five pages for the main document, with the current-state inventory as a separate annex or spreadsheet. The annex can be as long as it needs to be — that is data, not prose. Long narrative sections do not improve responses, they just get skimmed.
Should we tell bidders our budget?
Publish a range. Suppliers spend their effort on tenders where the budget is realistic, and hiding it produces two failure modes: proposals you cannot afford, and proposals scoped down to a number you never stated. A range costs you very little negotiating position and materially improves the bids.
Can we run a cloud migration RFP without knowing our full application inventory?
You can, but state clearly what is unverified and require bidders to price a discovery phase separately from delivery. What you must not do is present incomplete data as though it were complete — that is the single most reliable way to produce an unenforceable fixed price.
How many suppliers should we invite?
Three to five. Invite the ones whose references you can actually check in your sector and size band. A cloud migration RFP sent widely produces more paperwork, worse responses, and a panel that runs out of attention before it reaches the last submission.
Should the incumbent be invited?
Usually yes, and they should be evaluated on exactly the same criteria as everyone else. Incumbent knowledge is a genuine advantage worth scoring, but it is not a reason to skip the process — and a competitive tender is the cleanest way to find out whether your current rates are still market rates.
What if all the responses are disappointing?
That is usually a signal about the document rather than the market. Reissue with a better current-state pack, a tighter scope and a clearer decision process rather than picking the least bad option. Awarding a weak cloud migration RFP costs far more than restarting one.
Do we still need an RFP if we are buying through a framework?
Frameworks simplify contracting, not specification. You still need to describe scope, requirements and evaluation criteria to run a compliant further competition — the framework saves you the procurement notice and the terms negotiation, not the thinking.
References
GDS Service Manual: Moving Away from Legacy Systems
CMA Cloud Services Market Investigation
NIST SP 800-145: The NIST Definition of Cloud Computing
NIST SP 800-161r1: Cybersecurity Supply Chain Risk Management
NCSC: Using Cloud Services Securely
NCSC Supply Chain Security Collection
NCSC Cyber Essentials Overview
ICO Guidance on Controllers and Processors
Microsoft Cloud Adoption Framework for Azure
Azure Well-Architected Framework
AWS Well-Architected Framework
Google Cloud Architecture Framework
FinOps Foundation: What is FinOps?
DORA: DevOps Research and Assessment
