A commerce replatform is not bought the way most software is bought. Nobody stands up a storefront on a trial account and decides in a fortnight. The purchase carries a migration behind it that runs for quarters, so it clears whatever threshold a company sets for formal process, and it reaches an approver who is signing off a project rather than a licence. What follows is the document that survives that reading, assembled from the commerce interviews in our corpus.
How do you write an ecommerce replatform RFP?
Start with the outcome, not the feature list: name the specific thing the new platform does that your current one cannot, and price the move against it.
An ecommerce replatform RFP should contain eight sections:
- Business case and desired outcome
- Current state and what must survive the migration
- B2C and B2B functional requirements
- Non-functional requirements
- Backend and channel integrations
- Migration scope and cutover
- Total cost of ownership
- Commercial terms, term length and exit
Before writing it, decide whether you are buying a platform, composing one from multiple vendors, or building internally.
When is a formal RFP required?
The trigger is a policy your company already has, not a judgment about the category. One industrial manufacturer describes a structured enterprise process requiring at least three proposals and a formal RFP for anything classed as an enterprise solution. A large consumer-goods manufacturer runs extensive requests for proposals and quotations because audit standards require it — the document exists to satisfy a control, and would exist regardless of what was being bought.
Others are looser, and the looseness is not carelessness. A subscription retailer describes an RFI or RFP handled collaboratively and often using spreadsheets, starting from leadership alignment that a third-party solution is needed at all. A regulated manufacturer sequences it the other way round: a personal assessment of the need, then IT, then a market evaluation, and an RFP only if that scan turns up viable alternatives. The scan comes first; the document is a consequence of finding something worth putting it to.
So the first question is not what to write. It is which of those you are in — because one produces a formal instrument with a response format and a minimum bidder count, and the other produces a comparison sheet.
Should you buy, compose, or build your ecommerce platform?
Buy tends to fit when time to market or internal development capacity is the constraint. Compose fits when requirements exceed what a managed platform covers. Build becomes a live option when vendor constraints are the problem and the engineering capacity exists to own the platform.
This is the section that has no equivalent in a CDP or loyalty RFP, and it belongs at the front. Across the commerce interviews, building or substantially assembling the platform is not a hypothetical — it is what several of the largest buyers say they are actively weighing, and in a few cases already doing. A B2B distributor frustrated by a monolithic incumbent names building its own platform as the primary consideration, driven by architecture flexibility and getting out from under vendor constraints. A specialty retailer running both consumer and business storefronts is deciding between deepening its existing investment, moving to a composable vendor, or an internally developed solution — three routes, one of which never reaches a vendor. A global manufacturer frames the whole exercise as capturing business requirements and then deciding build versus buy with enterprise architects, before any vendor conversation happens.
Buy the platform
The managed or suite route. Taken when the constraint is development capacity or talent, and the requirement is time to market.
What the RFP does
Everything below applies. The document is the instrument.
Compose it
Headless or composable, assembled from several vendors. Taken when the requirement genuinely exceeds what a managed platform covers.
What the RFP does
Runs several times, once per component — and the integration section becomes the hardest part of each.
Build it
In-house, on your own engineering. Taken when vendor lock-in is itself the problem being solved, and the bench exists.
What the RFP does
Nothing. The requirements work still matters; the procurement does not happen.
The reason to settle this before writing is that the requirements work is identical across all three routes and the procurement is not. Buyers who name a build option describe arriving at it through the same requirements exercise that would have produced an RFP — so the effort is not wasted if you end up buying. It is wasted if you write a vendor-facing document for a decision that was never going to reach a vendor.
What are the eight sections of an ecommerce replatform RFP?
Eight sections. The first and the last are where the interviews concentrate: buyers describe replatforms that chased a platform rather than a named outcome, and a contract term that later set their whole calendar.
The business case and the outcome you are buying
Not "we need a modern platform." The specific capability the new platform delivers that the current one cannot, and what it is worth. Buyers describe this as the section that survives contact with the approver, because the approver is funding a migration and needs the return stated in their terms rather than in engineering's.
Ask the vendor for- How comparable customers measured the outcome you have named, and over what period
- What in your stated case their platform does not address
Current state, and what has to survive the move
The inventory of what exists and what is load-bearing. Buyers consistently describe legacy complexity as the constraint that shapes everything downstream — multiple distribution channels, regional variants, and integrations accumulated over years that a replatform has to carry forward or consciously retire.
Ask the vendor for- Which of your named integrations they support natively versus through a partner or custom work
- What they would expect you to retire rather than migrate
Commerce functional requirements — B2C and B2B separately
Split them. Several buyers in the corpus run both, and the platforms diverge sharply on the business side: customer-specific pricing, contract catalogues, quoting, and purchasing workflows that consumer-first platforms treat as extensions. One buyer selling into institutional procurement rules out a major vendor on exactly this basis. If both matter to you, a single merged requirements list will hide the gap until implementation.
Ask the vendor for- Customer-specific pricing and contract catalogue handling, demonstrated rather than described
- Which B2B capabilities are native, which are partner extensions, and which are roadmap
Non-functional requirements
An easy section to omit. One B2B software buyer names it explicitly — logging, audit trails, and performance assessed alongside the functional list rather than after it. For a regulated or public company these are not preferences, and discovering a gap post-signature converts them into custom work on a platform you chose partly to avoid custom work.
Ask the vendor for- Logging and audit-trail depth, and what is retained by default versus configured
- Performance under your own traffic profile, not a reference customer's
- Compliance posture for the regimes you actually operate under
Backend and channel integration
ERP, order management, product information, tax, payments, and every storefront-adjacent tool. This is where buyers report the easy platform straining, and it is the highest-volume topic in the corpus — but almost always discussed after the platform is chosen. Moving it into the RFP forces that diligence to happen before the platform is chosen rather than after.
Ask the vendor for- Named reference integrations for your specific ERP and order-management systems
- Whether the integration is theirs, a partner's, or yours to build — and who supports it afterwards
- What happens to the integration when either side upgrades
Migration scope and cutover
Catalogue, customers, orders, content, URLs and search equity, and the parallel run. Buyers describe the migration as the part that consumes the budget and the calendar, and the part they most often under-specified. State what you expect the vendor or its partner to do, what you will do, and what "done" means — because in these interviews that boundary is usually discovered rather than agreed.
Ask the vendor for- A migration plan for your data volumes, with the division of labour stated
- Their cutover approach, and what a rollback looks like
- How redirects and search equity are handled, and by whom
Total cost of ownership, not licence
The most-named criterion in the corpus, and buyers mean something specific by it: licence plus development plus the people who can do the development. Several describe leaving platforms that were expensive to change rather than expensive to run, and one names difficulty sourcing skilled talent as a first-order cost. Ask for the number over the term, not the year.
Ask the vendor for- Licence over the full term including uplift, and what drives it
- Implementation and ongoing development, quoted alongside the licence
- The market rate and availability of people who can build on it
Commercial terms, term length, and exit
The section that sets your next replatform's calendar, which is why buyers wish they had written it. Term length, uplift caps, what happens to your data on exit, and what it costs to leave. Buyers in this corpus describe waiting out contracts to reach a platform they had already chosen — the term is the constraint, and the time to shape it is now.
Ask the vendor for- Term, renewal mechanics, and uplift caps in writing
- Data extraction on exit — format, completeness, and cost
- What the agreement commits them to during migration, not just after go-live
What criteria matter most when choosing an ecommerce platform?
The three criteria buyers name most are total cost of ownership, integration with the existing backend, and scalability or architectural flexibility.
The grouping below is by how often buyers named each one as deciding their evaluation. These are frequency tiers rather than a strict ranking — the interviews support the grouping, not a precise order within it.
Named by most buyers
Named often
Also named
Grouped by how often buyers named each criterion as deciding their evaluation. Bars show the tier, not a weight or a vendor score.
How many vendors should you include in an ecommerce RFP?
There is no standard number in these interviews. The only explicit policy requires at least three proposals; other buyers describe shortlists of three to six, often narrowing to two finalists.
The corpus is thinner here than on criteria, and worth stating plainly rather than dressing up. One industrial manufacturer describes the only explicit rule: at least three proposals for an enterprise solution, then narrowing to the two best competitors on solution fit and price, with deep dives, demos and focus groups deciding between them. Others describe shortlists of three to six without naming a policy, and one runs a proof of concept against a named incumbent rather than a field.
What generalises is not the count but the shape: a long list assembled from what is already known and what the market scan surfaces, a narrowing to two on fit and price, and then a second, more expensive round of evidence-gathering on the finalists. Budget the second round properly. It is where the demos stop being presentations.
Who decides on an ecommerce replatform?
Two groups: a recommending group that evaluates the platforms, and an approving body that funds the migration. The split between them is consistent across the interviews.
The recommending group
Assembles the requirements and runs the evaluation. Consistently ecommerce or digital product paired with IT; at larger companies extended to engineering and enterprise architecture, and at one to a formal set of centres of excellence.
They produce the shortlist and the recommendation. In several interviews the ecommerce lead starts the process personally, before IT is formally engaged.
The approving body
Signs. For a replatform this sits higher than for most software: one buyer describes escalation from themselves to a VP and then through two levels of C-suite, and another names the board as the final approver.
They are approving a multi-quarter project against a migration budget, not a licence. That is why section 01 is written for them.
The practical consequence is that one document has two readers. The recommending group is choosing a platform; the approving body is funding a programme. A requirements list that only satisfies the first can stall at the second, which is the failure mode buyers describe when they say executive management pushed the timeline back.
What role does procurement play in an ecommerce replatform?
In these interviews, procurement typically joins after the field has narrowed, handling contracting and commercial terms rather than choosing the platform. One buyer describes marketing and IT leading the evaluation before legal and procurement enter; another runs the technical evaluation and proof of concept first, then moves into procurement to settle contracts and commercial terms.
The consequence is a timeline one buyer describes with some feeling: contracting as lengthy and arduous, governed by company policy rather than by the deal. If your organisation has that reputation, the vendors will already know it, and the contracting window belongs in your plan as a real phase rather than a formality after the decision.
When should you start an ecommerce replatform RFP?
Work back from your incumbent agreement: in these interviews, contract expiry sets the replatform calendar more reliably than the business case does. Buyers describe having chosen a destination and waiting out a term to reach it, with target dates pinned to a renewal years out. One accessories brand extended its incumbent agreement specifically to create the migration window.
That inverts the usual planning question. The deadline is the renewal, the migration is the long pole, and the RFP is backward-planned from both. So the question that decides your start date is not how long the document takes — it is how long the migration needs, which is the number buyers most often get wrong in the optimistic direction.
Want this read against your own stack?
Get my read →What this RFP cannot cover
Two limits worth stating rather than papering over, because both sit where the risk actually is.
The implementation partner
No buyer in these interviews describes choosing a systems integrator, or what they asked one for. Partners appear in the corpus — one buyer notes their integrator handles all platform changes — but the selection is invisible. That leaves an important blind spot: on a replatform, implementation-partner selection can carry substantial project risk, but these interviews do not tell us how buyers evaluate it.
Whether it holds at peak
A peak-season failure is among the most common reasons buyers replatform in the first place. Yet nobody in this corpus describes load-testing a replacement before signing, extracting a peak commitment, or negotiating an availability term during the evaluation. The category is moved by an event it does not then test for. If you write one thing into your document that is not in the outline above, make it this.
And a note on the instrument itself: no buyer here describes a weighted scoring matrix or a formal rubric issued to vendors. What they describe is criteria applied in prose, comparison held in shared spreadsheets, and a narrowing decided in conversation. The outline above is a requirements structure, not a scoring model. If you want the second, build it — but do not assume the category runs on one.
Common questions
Do you need an RFP to replatform?
It depends on your company's procurement policy, not the ecommerce category itself. Some buyers are required to run a formal RFP with a minimum bidder count; others use a lighter comparison sheet, or issue an RFP only after a market scan identifies viable alternatives. Find your company's trigger before writing the document.
What goes in an ecommerce replatform RFP?
Eight sections:
- Business case and desired outcome
- Current state and what must survive the migration
- B2C and B2B functional requirements
- Non-functional requirements
- Backend and channel integrations
- Migration scope and cutover
- Total cost of ownership
- Commercial terms, term length and exit
The first and the last are where the interviews concentrate: a replatform that chased a platform rather than a named outcome, and a contract term that later set the calendar.
Should you build or buy an ecommerce platform?
Buying tends to fit when time to market or development capacity is the constraint; composing fits when requirements exceed a managed platform; building becomes a live option when vendor constraints are the problem and the engineering capacity exists to own the platform. Buyers in these interviews describe doing the requirements work before making that decision, because the same requirements inform all three routes.
What criteria matter most when evaluating an ecommerce platform?
The three criteria buyers name most are total cost of ownership, integration with the existing backend, and scalability or architectural flexibility. Development effort, out-of-the-box coverage and B2B capability form the next tier.
Who decides on an ecommerce replatform?
Two groups. A recommending group — typically ecommerce or digital product paired with IT — evaluates the platforms. A separate approving body funds the migration, sometimes at C-suite or board level. The RFP has to satisfy both audiences.
When should you start a replatform RFP?
Work back from your incumbent contract, which in these interviews sets the calendar more reliably than the business case does. Buyers describe choosing a destination and waiting out a term to reach it; one extended its incumbent agreement specifically to create the migration window. The question that sets your start date is how long the migration needs.
How should you test an ecommerce platform for peak traffic before signing?
The interviews do not establish a standard pre-signature load-testing process. That is itself a gap: peak-season failure is a recurring reason buyers replatform, yet buyers in this corpus do not describe load-testing the replacement before signing. At minimum, make peak-load performance an explicit requirement rather than assuming scalability from references.
Related reading
For the buyer-side lessons behind these requirements — why the migration rather than the licence is the budget line, and what the app ecosystem costs — see what buyers wish they'd known before replatforming. For what actually triggers the move, including the peak-season failure this page's closing section returns to, see why brands replatform. For the same document exercise in a different category, see how to write a CDP RFP.
Get this research made for your stack
How formal your process gets depends on your size, your sector and your contract value — and the requirements that matter depend on what sits behind your storefront. Do a 15-minute interview and get the version of this that applies to you: what buyers at your scale put in the document, who they had to get through, and what the move actually cost them.
Get my personalized read — 15-min interviewNo password · your interview is anonymized before it ever informs a page like this one.