The Replatforming RFP Template

A replatforming RFP that produces genuinely comparable vendor responses needs to specify integration count, data volume, and customization requirements explicitly. A vague RFP produces vague quotes that look comparable on price and aren't actually scoped against the same requirements — which is how the cheapest bid turns into the most expensive project.

Last verified: September 6, 2026.

Why most RFPs fail at their one job

An RFP exists to make vendor responses comparable. A vague one — "we need to migrate to Shopify Plus" with no further detail — gets back quotes that all look reasonable and aren't actually scoped against the same requirements. The lowest number isn't necessarily the best value; it might just be the vendor who assumed the least complexity.

That failure has a predictable second act. The vendor who assumed the least complexity discovers it during the project, and the difference arrives as change orders. The team that chose on price has now paid more than the second-lowest bid and lost the schedule as well.

What a real RFP specifies

• Integration count and type — every system the new platform needs to connect to, named specifically. Which ERP, which OMS, which CRM, which subscription platform — not "our tech stack."
• Data volume and complexity — approximate SKU count, customer record count, order history depth, and an honest note on data cleanliness.
• Customization requirements — what needs rebuilding versus what can use native platform capability, based on an honest feature-parity audit rather than "replicate everything."
• Timeline constraints — any hard dates such as a lease expiration, a fiscal year boundary, or a peak season to avoid, stated explicitly rather than left for vendors to guess at.
• Evaluation criteria, stated up front — how responses will actually be scored, so vendors aren't guessing what matters most to you.

The customization section is the one worth the most preparation time, because it's the largest source of quote variance. Doing a feature-parity audit before the RFP goes out — deciding which current features are real customer needs and which are workarounds for an old platform limitation — is what turns that section from a wish list into a scope.

What to ask every vendor, regardless of their quote

1. What's your average client relationship length after launch? A partner whose engagements end at go-live is priced for a different kind of project than one that stays.
2. Who specifically will do the work — the team in the pitch, or a handoff to a different team after signing?
3. What's your process for data migration parity testing, specifically? The answer tells you quickly whether they reconcile field by field or check record counts. See what real parity testing involves.
4. What's your rollback plan if cutover doesn't go as planned? A vendor who hasn't thought about this before you asked hasn't planned a cutover, only a launch.
5. How do you handle SEO preservation? Ask specifically about redirect mapping coverage and whether it's tested before launch — the five-step process is a reasonable standard to hold responses against.

How to score responses so the comparison holds

Decide the weighting before the responses arrive, and write it into the RFP. Scoring criteria invented after reading the bids will bend, unconsciously, toward whichever bid you already liked. Publishing them in advance also improves the responses themselves, because vendors write to what's being measured.

Keep price as one criterion among several rather than a tiebreaker applied at the end. A quote is only meaningful relative to the scope behind it, and the whole purpose of specifying the RFP properly was to make those scopes the same.

A workable RFP structure

Six sections, in this order. The order matters: vendors read top to bottom, and the sections that shape a quote should come before the sections that describe your company.

1. Context and objective — what the business is, what's driving the move, and what "success" means twelve months after launch. Two paragraphs, not two pages.
2. Current state — the platform being left, the integrations in place, catalog and customer volumes, order history depth, and an honest note on data quality.
3. Scope — what's in, and explicitly what's out. The out-of-scope list is the more useful half and the one most RFPs omit.
4. Requirements — functional requirements grouped by area, each marked as must-have or nice-to-have, with the must-haves genuinely limited to things that would block launch.
5. Constraints — hard dates, budget range if you're willing to state one, compliance obligations, and any technology decisions already made.
6. Process — the timeline for the RFP itself, the format responses should take, the evaluation criteria and their weighting, and who to ask questions.

Stating a budget range is contentious and usually worth doing. Withholding it doesn't get you a lower price; it gets you a wider spread of quotes scoped against different assumptions, which is the exact problem the RFP exists to solve.

The RFP process has its own timeline

Build it into the project schedule rather than treating it as a preamble. A realistic shape for an enterprise replatform:

• 1–2 weeks writing the RFP, which mostly means gathering the current-state detail from people who are busy
• 2–3 weeks for vendors to respond, with a written question window in the first week and answers circulated to every respondent
• 1–2 weeks to evaluate, including presentations from a shortlist
• 2–4 weeks for reference calls, contracting and legal review — reliably the phase that gets underestimated

That's six to eleven weeks before anyone writes code. A plan that doesn't account for it will show a slipping schedule before the project has begun, and the slip will be attributed to the vendor.

Red flags in a response

• A quote with no assumptions listed. Every honest quote rests on assumptions. A response that states none has either not thought about them or has decided not to show you them.
• A timeline noticeably shorter than everyone else's, with no explanation of what's being done differently to achieve it.
• No named team. "A senior team will be assigned" means the people in the room aren't necessarily the people on the project.
• A data migration section that describes moving data but not verifying it. Parity testing is where migrations actually fail, and its absence from a response is informative.
• No mention of what happens after launch. A response that ends at go-live is priced for a project, not for an outcome.

What not to put in an RFP

A solution design. If the RFP specifies the architecture, you've removed the main thing you were buying — the vendor's judgment — and you've made the responses comparable on price alone by making them identical in approach.

An unfiltered feature list from the current site. This is the feature-parity trap arriving in document form. Run the audit first and put the conclusions in the RFP, not the inventory.

Boilerplate legal that nobody has read. Terms copied from an unrelated procurement template are the most common cause of a contracting phase running weeks longer than planned, because they surface as objections only after a vendor has been selected.

Why an under-specified RFP costs more than the RFP process itself

A vendor quoting against incomplete information will either underbid and issue change orders once real complexity surfaces, or pad the quote defensively to cover unknowns. Neither serves you. The time spent specifying a real RFP is returned many times over in the accuracy of what comes back — and in the scope conversations it forces you to have internally before a contract exists, rather than after.

An under-scoped RFP is one of the four consistent causes in why replatforms go over budget, and it's the one that's cheapest to prevent.

Reference calls, and what to ask on them

References are the part of the process most likely to be treated as a formality, and the part most likely to change a decision if taken seriously. Ask for two references matching your own profile — similar integration count, similar catalog scale — rather than whichever two clients are happiest.

Questions that produce useful answers:

• What went wrong, and how did they handle it? Every project has something. A reference who can't name one either had an unusually small project or is being careful.
• Did the people in the pitch do the work? The single most predictive question, and the one vendors are least able to influence.
• How did the estimate compare to the final number? Ask for the direction and rough size of the variance, and what caused it.
• What happened after launch? How long the vendor stayed, what the handover looked like, and whether the internal team could operate the result.
• What would you do differently? Usually the most candid answer of the call, because it lets the reference talk about their own decisions rather than the vendor's.

After the RFP: turning a response into a contract

The response is a proposal, not a scope. What protects both sides is a statement of work that names deliverables, acceptance criteria, and the change-order process, plus a few specifics that RFP responses routinely leave implicit: who owns the code and the data at the end, what the post-launch support window covers and for how long, and what the escalation path is when something goes wrong at an inconvenient hour.

Carry the RFP's own requirements into that document rather than treating it as a separate exercise. The most common way a well-run RFP process still produces a mis-scoped project is that the detail everyone worked through in the RFP never made it into the contract.

Where this fits

The RFP follows the business case and precedes the build. Both sit inside Anatta's replatforming method. If you're evaluating agencies more broadly rather than writing a formal RFP, how to choose a Shopify agency covers the selection criteria in more depth. Anatta's own success stories are a reasonable reference point for the kind of evidence worth asking every responding vendor to provide.

Frequently Asked Questions

What should a replatforming RFP include beyond basic requirements?

Specific integration count and type, data volume and complexity, an honest customization scope based on a feature-parity audit, explicit timeline constraints, and stated evaluation criteria — the detail that makes vendor responses genuinely comparable.

Why do vague RFPs lead to bad vendor selection?

Because vendors quote against their own assumptions when detail is missing. The lowest number often just reflects the vendor who assumed the least complexity, and that gap comes back as change orders once the real scope surfaces.

Should evaluation criteria be shared with vendors up front?

Yes. It improves the responses, because vendors write to what's being measured, and it protects the comparison from criteria that get invented after the bids arrive and bend toward whichever one you already liked.

What single question tells you the most about a responding vendor?

Ask what their process for data migration parity testing is, specifically. The answer separates vendors who reconcile field by field from those who compare record counts, and that difference predicts a lot about the rest of their delivery.

How long does the RFP process itself take?

For an enterprise replatform, six to eleven weeks before anyone writes code: one to two weeks writing it, two to three for responses, one to two to evaluate, and two to four for references, contracting and legal. That last phase is the one reliably underestimated.

Should the RFP state a budget range?

Usually yes. Withholding it doesn't produce lower prices; it produces a wider spread of quotes scoped against different assumptions, which is precisely the problem the RFP exists to solve.

What are the clearest red flags in a vendor response?

A quote listing no assumptions, a timeline much shorter than everyone else's with no explanation, no named team, a data migration section that describes moving data but not verifying it, and no mention of what happens after launch.