Your procurement team thinks it bought control. That's the lie RFQs tell when the scope isn't fixed. I've seen IT Directors smile at the lowest quote in a sealed room, then spend the next six months untangling broken metadata, half-migrated SharePoint structures, and compliance questions they should've seen coming on day one.

For Microsoft 365 and SharePoint work, what is RFQ is not a simple definition exercise. It's a decision point. Use it badly and you lock the programme into a price race on a job that needs discovery, engineering judgement, and migration discipline. Use it correctly and you get a clean comparison on a fixed requirement. Use it against a complex tenant-to-tenant migration and you're buying the cheapest way to create a mess.

The Monday Morning Your RFQ Comes Back to Bite You

The room always looks calm on award day. The IT Director has three sealed quotes, finance likes the spread, and the cheapest bidder has polished answers about migration “efficiency”. Everyone nods. Everyone wants the pain to stop. That's usually the moment the organisation stops thinking like an operator and starts thinking like a buyer of stationery.

Six months later, the tone changes. Document IDs collide, lists over five thousand items behave badly, permissions drift across libraries, and somebody in legal asks why regulated content landed in places nobody approved. The vendor points to the spec. Procurement points to the award memo. The business points at IT. That's the cost of an RFQ used as a substitute for design.

Fixed scope feels safe until it isn't

An RFQ gives people the comforting illusion of discipline. The paperwork looks orderly, the quotes are comparable, and the price is easy to explain to a CFO. The problem is that Microsoft 365 and SharePoint migrations aren't neat commodities. They contain content weirdness, legacy permissions, third-party dependencies, and governance landmines that don't fit into a price-only form.

Practical rule: if your team can't describe the source tenant, target tenant, data classes, and rollback rules in plain English, you're not ready for an RFQ. You're ready for discovery.

That's why the strongest procurement teams separate “buying” from “solving”. If the job still needs technical investigation, the RFQ becomes a trap. If the scope is already fixed, the RFQ can work, but only if the specification is precise enough to force comparable quotes and expose delivery risk early.

The rest of this article cuts through the jargon and shows you the difference between a proper RFQ and a procurement shortcut that will come back to hit your programme later.

What an RFQ Actually Means in Real Procurement

RFQ usually means Request for Quotation. In procurement, that means the buyer has already fixed the requirement and wants suppliers to quote against the same scope, with price, delivery, and commercial terms doing most of the work. The U.S. General Services Administration draws that line clearly in its guidance on RFIs, RFQs, and RFPs, and that logic maps cleanly to regulated buying in Ireland and the UK (GSA procurement guidance on RFIs, RFQs, and RFPs).

In the Republic of Ireland, that meaning sits inside the EU-aligned public procurement regime. The European Union (Award of Public Authority Contracts) Regulations 2016 were enacted through S.I. No. 284/2016, so public-sector buying isn't casual purchasing, it's regulated tendering governance (Irish public procurement context for RFQs). The UK Crown Commercial Service logic is the same, RFQ is for a requirement that's already defined, not for designing the solution from scratch (UK procurement guidance context).

The three meanings that cause avoidable confusion

Procurement teams get sloppy with acronyms, and that's where mistakes start. RFQ can mean three different things depending on the room you're in.

The prequalification version matters in construction and some public-sector tenders, because it filters vendors before price comes into play (RFQ as Request for Qualifications context). The technical engineering meaning can also surface in mixed enterprise environments, which is why internal stakeholders sometimes misread an email or tender portal note and assume the wrong process is in play (radio-frequency quadrupole context).

If your team uses “RFQ” loosely in emails, ERP fields, or procurement portals, lock the meaning down before anyone writes a requirement line. Once the wrong definition enters the process, every downstream decision inherits it. For a broader look at where RFQs sit in formal buying, compare this with what a tender actually is.

RFI vs RFQ vs RFP and When Each One Applies to IT

Most bad procurements start with the wrong document. Teams try to force a price-only process onto a problem they haven't even understood yet. That's how you end up with a quote that looks clean and a delivery plan that falls apart as soon as reality touches it.

How RFPs differ from other procurement documents matters here because the instrument has to match the maturity of the requirement.

RFI vs RFQ vs RFP at a Glance

An RFI is for learning. It helps you understand capabilities, market patterns, and what's even possible before you commit to a shape. Use it when the question is still fuzzy.

An RFP is for design. It asks vendors to propose an approach, not just a price, which makes sense when the solution space is open and the execution path matters. Use it when the work involves architecture choices, migration method, governance, or trade-offs between competing technical options.

An RFQ is for pricing a known thing. It works when the requirement is already nailed down and the only sensible competition is on commercial terms. That's fine for standardised buying. It's a bad fit for most Microsoft 365 and SharePoint migrations, because those programmes are rarely fixed like-for-like commodities.

We often see clients fail when they treat RFQ as a shortcut for a complex migration. The documentation says compare quotes, but reality is that throttling, permission drift, path-length issues, and GUID conflicts make execution risk the primary cost driver. If you haven't used an upstream RFI and RFP to burn down uncertainty, you shouldn't be forcing a migration into an RFQ just because procurement likes the headline simplicity.

Bottom line: use RFI to shape the problem, RFP to design the solution, and RFQ only when the job already behaves like a commodity. For Microsoft 365 and SharePoint, that's the exception, not the rule.

Why an RFQ Is Structurally Wrong for Microsoft 365 Migrations

An RFQ only works when every bidder quotes the same specification. The buyer defines the quantities, deadlines, and constraints, then the vendors price the same thing. That is why formal procurement guidance for request quotations treats it as a pricing exercise for a fixed requirement, where bids can be compared on a like-for-like basis and pushed into a purchase order once accepted. Microsoft's own procurement model for request quotations follows that pattern, and it fits commodity buying, not a live migration with unknowns.

That model breaks as soon as you point it at Microsoft 365 work. SharePoint and tenant-to-tenant migrations are full of variables you cannot freeze at the start. Site topology shifts when you discover what lives in the source tenant. Custom solutions and Power Apps dependencies do not behave like catalogue items. Permissions inheritance breaks in ugly ways. External sharing rules vary by business unit, by site, and by regulator.

The scope you think you know is rarely the scope you have

The moment you flatten that moving target into an RFQ, you do not remove uncertainty. You push it downstream into delivery, where every surprise costs more and gets blamed on someone else. The lowest bidder wins by underpricing discovery, underestimating remediation, or assuming the client will waive problems later.

The risk starts before a single file moves. Broken inheritance, odd metadata, legacy workflows, and business-owned content sprawl change the shape of the job after the quote is already out. If the team bidding has not done proper discovery, the number you received was never a real quote. It was a guess dressed up as procurement.

The UK position on RFQs is useful here. An RFQ belongs where the requirement is already sufficiently defined and the contest is mostly about price and commercial terms, not redesigning the solution (UK RFQ meaning and use). That works for repeatable buying. It fails when the migration itself contains unknowns that only a proper technical discovery can expose.

If your migration can still surprise you, it is not RFQ-ready.

The compliance problem is harsher than the procurement problem. In regulated environments, missing compliance items in a fixed-scope migration does not just create a delivery miss. It breaks legal compliance, triggers rework, and can force a second migration under business pressure. That is how a controlled buying exercise turns into an avoidable incident.

What an RFQ Must Contain If You Are Forced to Use One

Some organisations won't let you avoid an RFQ. Internal policy, procurement habit, or governance theatre can force the issue even when the work clearly needs discovery. If that's your reality, then the RFQ has to act like a risk-control document, not a price-comparison form.

Build the document to expose technical depth

Start with tenant and source environment scoping questions. Demand clarity on the source estate, target estate, content classes, business owners, and anything that can change the shape of the job. Then force the bidder to address data classification and compliance requirements, because regulated data cannot be treated as just another payload.

Add explicit references to documented limits, because vague promises are where bad migrations hide. Require pre-migration discovery outputs as a mandatory deliverable, not a suggestion. If the bidder can't show you what they learned before cutover, they haven't earned the award.

Use mandatory proof-of-concept milestones to validate the hard bits before the contract hardens. Insert time-and-materials escape clauses for unknowns that only discovery can surface. Define exit and rollback responsibilities so nobody can vanish when cutover fails. Require named-consultant clauses so you don't get sold a senior architect and staffed with junior labour.

Ollo verdict: use SPMT for under 50GB. For anything else, you need custom scripting.

That line matters because tool choice follows risk, not sales brochures. If you're using a migration tool without acknowledging where it breaks, your RFQ is already lying to you.

A procurement handoff your team can actually use

Give procurement a checklist, not a vague brief.

• Detailed scope and exclusions, so bidders can't hide assumptions.
• Technical requirements, so the quote reflects the actual environment.
• Methodology expectations, so you can compare delivery discipline.
• SLAs and reporting, so the business knows how issues get escalated.
• Assumptions and risk acknowledgement, so hidden scope gets surfaced.
• Pricing breakdown structure, so you can see what's being charged.
• Post-migration support terms, so cutover doesn't become abandonment.

That is the difference between a procurement document and a future incident report. If the RFQ can't force the vendor to talk about discovery, controls, and failure modes, it's not fit for Microsoft 365.

The Hidden Technical Risks That Quietly Invalidate Your RFQ

A clean RFQ doesn't produce a clean migration. It produces a cleanly priced guess. The hidden risk lives in the execution details that the quote rarely captures because they don't show up in a neat line item.

Microsoft Learn confirms the ugly parts. API throttling can slow or block bulk operations. The list view threshold can break work around lists over five thousand items. Broken inheritance can expose content to the wrong people. GUID conflicts can collide when source and target environments both carry active IDs. Long path and file-name limits surface only when scale hits the limits. Those aren't theoretical edge cases, they're official platform constraints that rescue teams deal with every week (Microsoft Learn on RFQ-style transfer mechanics in Dynamics 365).

The quote never prices the failure path

The documentation says compare quotes, but reality is that these technical constraints change the cost of delivery in ways procurement can't see. A vendor can be cheap on paper and disastrous in motion if they don't account for throttling retries, permission remediation, path restructuring, or ID reconciliation.

We often see clients fail when they assume the migration vendor will “just handle it”. That attitude works until the first blocked batch job or the first content audit. Then the remediation cost lands on the business, not the bidder.

One resource that teams often overlook when defining content governance is Digital Passport for Product, because structured metadata and traceability thinking make it easier to spot where migration controls will fail before cutover. It's not a migration tool, but it does reinforce the discipline that complex data needs provenance, not hand-waving.

Microsoft 365 tenant migration risk patterns become especially ugly when you combine regulated content with legacy collaboration sprawl. In that environment, a fixed-scope RFQ usually prices the visible work and ignores the failure modes that trigger rework, audit findings, and business disruption.

Ollo verdict: SPMT is fine for a one-off mailbox. For tenant-to-tenant with regulated data, it is a liability.

That's not a marketing line. It's a risk statement. If your migration plan doesn't account for the constraints above, the lowest quote gives you the cheapest path to a second migration.

Why Hiring a Specialist Is the Real Risk-Reduction Strategy

The cheapest RFQ bid isn't the lowest-risk bid. RFQs price the visible work, not the hidden failure modes, and enterprise migration work lives in the hidden parts. That's why specialist consultancy matters more than a tidy template.

A real Microsoft 365 migration specialist doesn't pretend the environment is simple. They use tools like ShareGate and custom PowerShell PnP scripts because enterprise work needs inspection, exception handling, and controlled remediation. They don't lean on basic tools like SPMT for jobs that involve tenant consolidation, zero-trust redesign, or rescue work. That's not elitism. That's operational realism.

Admin roles versus consultant capability is the gap most IT teams underestimate. Your internal admin team knows the tenant. A specialist knows how migrations fail under regulatory pressure, and that difference matters when the business has already run out of patience.

Multiple procurement references describe RFQs as formal requests sent to a limited, prequalified group of vendors rather than the open market, and that's exactly how specialist work should be handled (RFQ supplier selection guidance). If the work is a true commodity with no compliance scope, fine, run the RFQ and buy the cheapest compliant option. If it's a tenant-to-tenant consolidation, Entra ID zero-trust redesign, or rescue migration, prequalify the specialists first and weight technical discovery above price.

Your CFO doesn't need a speech. Give them this line instead. The cost of a failed migration is not the consultant fee. It's the regulatory fine, the lost productivity, and the second migration you have to fund.

If you're planning a Microsoft 365 or SharePoint migration and the RFQ looks tidy only because nobody has asked the hard questions yet, speak to Ollo before procurement locks in the wrong path. Visit Ollo and get a specialist view on scoping, discovery, and the controls that keep regulated migrations from turning into rescue work.