The Website Replatform RFP: A Scope Template and Scoring Rubric for Enterprise Buyers

If your replatform RFP reads like most of them, it can end up rewarding the agency with the best proposal writer rather than the partner best equipped to deliver the project. That is the core failure. A weak RFP asks broad questions, receives polished narrative answers, and leaves an evaluation committee comparing vendors partly on tone, presentation, and assumptions that may not match. A stronger RFP puts every respondent against the same scope, requirements, architecture constraints, and scoring framework, so meaningful differences in methodology, technical approach, and delivery experience are easier to see. The principle underneath everything below is simple: define the work and the evaluation framework before responses arrive, then require every vendor to show how its approach holds up against both. 

This is not another “questions to ask an agency” list. It is the artifact itself: what belongs in the RFP document, a scope-of-work template broken into the six workstreams a replatform actually runs on, and a weighted scoring rubric your committee can use without arguing about what “strong” means. Use it as a starting structure and cut what does not apply. The point is to standardize the inputs so you can trust the comparison.

Build the RFP around scope and scoring, not open-ended questions

Two choices do more than almost anything else to make an RFP comparison defensible: putting every respondent against the same defined scope, and agreeing on the evaluation criteria and their relative importance before responses are reviewed. Those decisions do not replace good technical diligence, but they keep the evaluation from drifting toward whichever proposal is cheapest, most polished, or closest to what individual evaluators already preferred. 

Enterprise RFPs often start too loosely: “migrate our website to a modern platform.” That leaves each agency free to solve a different problem. One proposal may assume 2,000 pages while another prices 6,000. One may treat the CMS as the center of the new stack, while another separates content, presentation, search, personalization, DAM, and other services behind APIs. A third may exclude integrations entirely. By evaluation time, the committee is comparing different architectures, different scopes, and different assumptions under a single price column. Price still matters, but it is difficult to interpret until the underlying scope and technical assumptions are comparable. 

The fix is to do enough of your own scoping first that the RFP defines the work, and to publish the scoring weights inside the RFP so respondents know what you actually value. What follows is the structure that makes both possible.

What the RFP document should contain

A useful enterprise replatform RFP can be organized into seven core sections. Together, they reduce the number of material assumptions vendors have to make independently. 

1. Current-state context. Current-state context. Give respondents the facts they need to price and architect accurately: current platform and version, approximate page count after a rough content audit, number of brands and locales, front-end framework and hosting model where relevant, the integrations in scope (CRM, marketing automation, analytics, search, identity, commerce, DAM), and any hard compliance requirements such as accessibility, data-residency, or security expectations. Also describe where content is currently coupled to templates, page layouts, or platform-specific functionality. Vague inputs produce broader assumptions and less comparable bids. If you do not know the real page count or the extent of those dependencies, say so and make discovery part of the scope rather than letting each vendor make a different private assumption. 

2. Scope of work, by workstream. This is the section that most RFPs shortchange. A replatform is not simply “move content and rebuild templates.” A useful way to scope the program is across six interdependent workstreams, each with different owners, dependencies, and effort. Define them explicitly (the template is in the next section) and state which you expect the partner to lead, which you will keep in-house, and which are jointly owned.

3. Mandatory requirements. Mandatory requirements. Separate non-negotiables from scored criteria. A mandatory requirement is pass/fail: able to start within the required window, willing to name the proposed delivery team, able to meet your accessibility and security requirements, and able to demonstrate appropriate platform expertise. If the CMS has already been selected, this may include relevant certifications or formal partner status; if it has not, require respondents to explain and defend the architecture they recommend. Use these requirements as an initial screen before applying the weighted evaluation. Certification can establish baseline familiarity, but it should not substitute for evidence of comparable production migrations. 

4. Evaluation criteria and weights. Publish the rubric. Tell respondents exactly how you will score (the categories and the weight on each) so they invest their response effort where it matters to you rather than where their marketing team defaults. This single move discourages the glossy-portfolio-thin-methodology response, because respondents can see that portfolio is worth less than method.

5. Commercial model. Ask for more than a number. Require pricing against the defined scope, the rate and approval process for out-of-scope work, the assumptions the price depends on (page count, integration count, locale count), and what is explicitly excluded. For work that cannot responsibly be fixed before discovery, ask the vendor to identify the uncertainty rather than burying contingency inside the bid. A price without stated assumptions may look precise while leaving the actual commercial exposure unresolved. 

6. Timeline and constraints. State whether your launch date is externally driven (a license expiry, an end-of-life, an acquisition, a campaign) or internally chosen and movable. A hard external deadline materially changes how a migration should be scoped, sequenced, staffed, and governed. Respondents should show which parts of the program can run in parallel, which dependencies sit on the critical path, and how they will protect the launch date if discovery changes the scope. 

7. Response format. Constrain it. A page limit per section, a required structure that mirrors your scoring categories, and named required artifacts (a draft project plan, a sample content model, a named team roster). When you dictate the format, you can compare responses side by side instead of hunting for each answer inside a differently organized deck.

The scope-of-work template: six workstreams

Break the scope section into these six workstreams. For each, state the deliverable, the owner (partner / in-house / joint), and the acceptance criteria. This is the frame that stops a replatform from being scoped as a two-line summary.

1. Discovery, content modeling, and architecture. Content audit, content-type definition, modeling workshops with editorial, marketing, design, and engineering, plus an architecture recommendation with the major trade-offs documented. Require the proposed model to distinguish reusable content from page-specific presentation and show how the content will be consumed by the front end and other channels. The deliverable is a validated content and architecture model, not a screenshot of the current sitemap rebuilt in a new CMS. 
2. Design and front-end build. Design system, component library, responsive templates, and front-end implementation against the new content architecture. State whether this is a visual refresh or a like-for-like rebuild; they are very different scopes. If the proposed architecture separates the presentation layer from the CMS, require respondents to define the boundary clearly: what belongs in the content model, what belongs in the component system, how preview works, and how either layer can evolve without unnecessarily forcing changes in the other. 
3. Content migration. Extraction, transformation, mapping to the new model, loading, validation, and redirect strategy. Name who owns content cleanup and define what “migration complete” means. Source estates frequently contain duplicates, stale pages, locale variants, PDFs, redirects, and structures that do not map cleanly into the new model. Those conditions can change both scope and cost materially, so content cleanup should be assigned explicitly rather than treated as an invisible part of migration. 
4. Integrations. Rebuilding CRM, marketing automation, analytics, search, identity, and any commerce or DAM connections. Do not use page count as a proxy for total migration complexity: a smaller site with a dense integration landscape can require considerably more architecture, testing, and coordination than a much larger publishing-only site. Ask respondents to inventory each integration, identify its owner and data flow, state whether it will be rebuilt, replaced, or retired, and explain how the new CMS participates in that ecosystem. Scope this workstream in its own right; do not fold it into “build.” 
5. Governance and workflow. Define the role and permission matrix, environment-promotion flow, editorial approval workflow, localization governance, and ownership of content-model changes. Ask respondents when these decisions enter the project. If governance is postponed until the end, the team may discover that permissions, workflows, and publishing controls no longer match the architecture that has already been built. Strong responses treat governance as a design input, not a launch-week configuration task. 
6. Training and ownership transfer. Require hands-on editor training segmented by role and workflow, developer documentation of architecture decisions and integrations, operating documentation for releases and environments, and a defined post-launch support window. Before launch, name who owns the CMS, front end, integrations, content model, and release process once the implementation team steps back. 

A useful test of any response: does the vendor’s proposed team and timeline account for all six workstreams, or does the plan quietly assume three of them will handle themselves?

The scoring rubric

Fix these weights before responses arrive, and score each category independently before you look at price. The weights below are a defensible default for an enterprise replatform; adjust to your context, but adjust before you read a single response, not after.

Category	Weight	What a strong response demonstrates
Methodology and approach	20%	A defined, repeatable process for discovery, content modeling, architecture decisions, migration, testing, and scope change. Shows the sequence and decision gates, not merely the deliverables.
Architecture and content model	20%	A clear separation of content, presentation, and integrated services where appropriate; reusable structured content; documented API and integration boundaries; preview and editorial experience; and explicit architectural trade-offs rather than a generic platform diagram.
Relevant delivery experience	15%	Comparable migrations by platform complexity, content scale, locale count, integration landscape, and operating model, supported by named references or detailed case evidence.
Team and continuity	15%	Named delivery roles and a clear staffing model from discovery through launch, including who owns architecture, migration, front end, QA, and program management.
Scope and change management	10%	A defined process for surfacing assumptions, handling discoveries, approving scope changes, and protecting critical-path work.
Commercial clarity	10%	Pricing tied to stated assumptions, transparent treatment of out-of-scope work, and explicit exclusions and dependencies.
Post-launch and ownership	10%	Training, documentation, support, governance, and a clear transfer of ownership across content, code, integrations, and releases.

Two practices make this rubric more useful. First, keep technical and commercial evaluation distinct enough that a low number cannot compensate for an unclear or high-risk technical approach without scrutiny. Depending on your procurement rules, that may mean separate technical and commercial evaluators, staged review, or simply requiring technical scores and rationales to be recorded before commercial moderation. Second, require evidence for every high score. A 5 out of 5 on methodology should point to a described process, artifact, or comparable example, not to an assertion that the agency is thorough.

How to read the responses against the rubric

The scores surface signal, but a few patterns are worth reading for directly:

• Methodology described as deliverables is a red flag. “We will deliver a content model, a design system, and a migration plan” tells you what, not how. You want the how: the sequence, the workshop format, who is in the room, what decision each step produces.
• A content model that merely reproduces today’s page layouts is a structural warning. Design and content modeling should inform each other, but they should not collapse into the same thing. If every hero, card, CTA, and page section becomes a CMS object defined primarily by how it looks on today’s website, the new platform can inherit the same coupling the replatform was meant to reduce. Ask which content is reusable independent of presentation, which structures are intentionally page-specific, and why. 
• “Resources to be assigned” creates a delivery risk the buyer cannot evaluate. The people presenting the work are not necessarily the people who will execute it, so require respondents to identify the roles they are committing, which individuals are confirmed, where substitutions are permitted, and how continuity will be maintained from discovery through launch. A named team with clear allocation gives the evaluation committee something concrete to assess. 
• A price with no assumptions hides the variables that can later change it. Require respondents to state the page, locale, integration, migration, and environment assumptions behind the commercial model, along with the process for handling variance. The goal is not to eliminate change; it is to make the triggers, decision rights, and commercial consequences visible before the project starts.

Make vendors show you the architecture, not name it 

Do not award points simply because a respondent uses words like “headless,” “composable,” or “API-first.” Those labels describe architectural patterns, not implementation quality. Ask the vendor to show where content lives, where presentation logic lives, how the front end retrieves and previews content, how search, personalization, DAM, translation, forms, and analytics connect, and which parts of the stack can be changed without rebuilding the rest.

Then look at the content model itself. A modern architecture should make deliberate choices about which content is reusable independently of a page, which structures are tied to a particular experience, how relationships are modeled, and how those decisions affect editors. That distinction matters more than whether the CMS appears on someone’s preferred-vendor list.

This is especially important in a headless or composable replatform. Decoupling creates useful flexibility, but it also moves responsibility into architecture, integration, front-end engineering, preview, deployment, and governance. The RFP should therefore test whether the implementation partner knows how to operate that model in production, not merely whether the proposed CMS supports APIs.

What a genuinely strong response looks like

That distinction is also why implementation experience matters more in a composable stack than a platform badge alone: the CMS may be one product, but the delivered experience spans content architecture, front end, integrations, infrastructure, governance, and the team’s operating model. 

The strongest responses make their delivery model visible rather than asking the buyer to trust adjectives about it. In eight25’s own enterprise replatform work, that has meant treating discovery, content architecture, migration planning, and ownership transfer as part of the implementation rather than setup around it. NetApp’s migration from SAP/RWS Tridion to Contentstack moved an estate of roughly 14,000 pages across 10 languages through a January-to-June program, using a co-development model that brought NetApp’s internal developers into the delivery. Sophos consolidated two Sitecore estates onto a single Contentstack platform against a fixed December 11, 2025 launch, with scope and ecosystem integrations managed as explicit parts of the program. These are useful signals to ask any finalist to demonstrate: how internal teams participate during delivery, how the content and integration architecture is governed, and what the client is genuinely able to own after launch. 

That is what to listen for in a response: a partner describing how internal capability gets built during the project, not promised for after it. A response that treats training and ownership as a closing line rather than a workstream is telling you what happens to your team the day after go-live.

When not to run a formal RFP

A formal RFP becomes more valuable as the number of parties, dependencies, architectural decisions, locales, brands, integrations, and commercial variables increases. For a smaller single-brand implementation with limited integrations and a flexible launch date, a lighter selection process may be sufficient: for example, a shortlisting exercise followed by structured workshops or a paid discovery with finalists. The procurement process should be proportionate to the uncertainty and risk in the decision rather than formal for its own sake. 

There is also a limit to what an RFP can surface on paper. Some of the most useful signals appear when a team has to work through a real problem: how it turns business requirements into a content model, where it draws the boundary between CMS and front end, how it handles an integration dependency, and what happens when discovery changes an assumption in the scope. Use the RFP to standardize the comparison and narrow the field. Then use a structured working session, technical deep dive, or short paid discovery to test how the finalist actually makes decisions. The written response tells you what the partner says its methodology is; the working session lets you see it operate. 

The best replatform partner is rarely the one who wrote the best proposal. It is the one whose method holds up when you score it against a scope you defined, force it onto the same rubric as everyone else, and ask it to show the work instead of describe it. Build the RFP to make that visible, and the choice makes itself.