Edited by us
Cloud migration RFP — why vendors can't quote yours
An RFP that says 'migrate everything' with no inventory comes back as padded quotes and change orders. What a quotable migration RFP actually contains.
By Mephify (operator)2 min read
What happens on the receiving end
The request as it usually goes out
RFP for cloud migration consulting. All on-premise systems in scope, target completion first half of next year.
The direction is fine. The problem is that no vendor can price this.
Three things are missing for anyone trying to bid. Scale: twenty servers or three hundred, which databases, what calls what. Constraints: how long each system can be down, whether any data carries regulatory weight. The finish line: what has to be verified before you sign off.
Those blanks come back in one of two shapes: a padded quote wrapped in assumptions, or a low bid followed by change orders once the real scope surfaces. Either way, the buyer pays for the missing paragraph.
What a quotable RFP contains
1. An inventory table
- Server and VM counts with rough specs. If you only have estimates, label them as estimates and include them anyway
- Databases: engine, version, size — the migration method changes with each
- Dependencies: what calls what. Without this no one can sequence a cutover
- The invisible work: overnight batch jobs, backups, scheduled exports
2. Constraints as numbers
'Zero downtime preferred' can't be priced. Downtime tolerance per system and allowed cutover windows can. If regulated data is in scope, name the regime, whether that is HIPAA for patient data, PCI for card data or your data-residency requirement, and let bidders state how they meet it, rather than writing your own interpretation into the document.
3. Published scoring weights
An RFP without scoring weights collects brochures. Publish how you'll weigh technical approach, migration track record, and price, and the proposals reorganize themselves around exactly that.
4. The undecided, marked as undecided
If budget ceiling or start date isn't settled, don't fill it with a plausible number. Route it to the Q&A round. Handling open items in an RFP is its own topic, covered in our guide on the not-yet-decided.
Checklist before it goes out
- 1Is there a table a vendor can price from — servers, databases, dependencies?
- 2Are downtime tolerance and cutover windows written as numbers?
- 3Is every regulatory regime named rather than interpreted?
- 4Are scoring weights published?
- 5Are open items routed to Q&A instead of filled with guesses?
If assembling this every time is the tedious part, that is what the RFP studio does. It takes these items as inputs and expands them into a procurement-ready document. The library holds worked migration RFP specimens: healthcare, contact center, a full data-center exit.
Reading helps; trying is faster.