Start with the commercial job of the site
Your scope should begin with the buying process the website must support.
A focused company site may need a clear product story, a few proof pages, and one conversion path. A mature B2B website may serve several industries, products, regions, campaign teams, and sales motions. The second project creates more decisions even when both sitemaps contain the same number of URLs.
Write down the jobs before you compare estimates:
- Explain the offer to each priority buyer
- Move qualified visitors toward a demo, consultation, trial, or sales conversation
- Give sales teams pages they can use during active deals
- Let marketing publish campaigns and resources without developer help
- Preserve search value during the migration
- Measure the actions tied to pipeline
- Support approved segment-specific content
This list gives each technical feature a reason to exist. It also exposes features that sound useful but have no owner or commercial use.
The six workstreams that shape redesign cost
Ask every agency to price and describe these workstreams. A credible proposal may combine them, but it should not hide them.
| Workstream | Deliverables to expect | Common scope gap |
|---|---|---|
| Strategy and content | Buyer paths, sitemap, page briefs, conversion plan | Design starts before the team agrees on the message |
| Design system | Reusable components, responsive states, interaction rules | A set of polished desktop pages with no operating system |
| CMS and migration | Content models, fields, preview, migration, training | “CMS setup” with no content inventory or migration rules |
| Personalization | Segments, variants, fallbacks, preview, ownership | A tool connection with no editorial workflow |
| Analytics and consent | Measurement plan, events, consent behavior, QA | A GA4 tag installed with no useful event model |
| QA and launch | Redirects, browser checks, forms, performance, handoff | Launch support ends when the code reaches production |
The table makes proposal comparisons less theatrical. You can see which team has scoped the system and which team has priced a collection of screens.
CMS cost comes from structure and migration
CMS work has two parts: building the editorial system and moving content into it.
Content modeling
A structured CMS needs content types that match how your team publishes. A B2B site may include products, solutions, industries, case studies, resources, authors, FAQs, landing pages, and global calls to action.
Each type needs fields, relationships, validation, SEO controls, image rules, and preview behavior. Editors also need boundaries. They should control the message without inventing a new layout for every page.
Ask the agency to name:
- Content types included in scope
- Reusable modules editors can place
- Fields and validation rules
- Preview support for draft content
- Publishing roles and permissions
- SEO and social metadata controls
- Training and documentation
“Flexible CMS” means nothing until the proposal names what your team can create and change.
Content migration
Migration effort depends on content condition, not URL count alone.
A clean set of recent pages can move through a mapped process. An older site may contain duplicate posts, broken links, inconsistent categories, missing image rights, obsolete offers, and page-builder markup that resists a direct transfer.
The migration scope should state:
- Which content will move
- Which content will merge, redirect, archive, or receive a rewrite
- Whether migration uses scripts, manual entry, or both
- Who cleans source content
- How the team will validate links, images, metadata, and dates
- Who approves the migrated result
A low migration estimate may assume your team delivers clean, approved content in a strict format. That can work. Put the assumption in writing so the work does not reappear as a surprise change order.
Personalization adds a second content system
Personalization introduces variants on top of the base website. The cost comes from managing those variants without losing control.
A useful first release may change a CTA for a campaign audience, show industry-specific proof, recommend resources by topic, or route forms by company size. Each use case needs five decisions:
- Which visitor qualifies for the segment?
- Which content changes?
- Which default content appears when the rule fails?
- Who owns the variant?
- Which event confirms the visitor saw and used it?
The CMS may store variants while the front end, CRM, campaign parameters, or another system decides when to render them. Your agency should define that boundary.
Personalization scope should cover:
- Segment definitions and rule sources
- Variant content models
- Default content and failure behavior
- Preview for each segment
- Component-level tracking
- Consent and privacy constraints
- Editorial ownership and cleanup
- Performance checks for personalized pages
Avoid pricing a broad personalization program before the team can maintain one path. Start with one high-intent use case. Build the content model, rendering rule, fallback, preview, and measurement. Then review the workload before adding more variants.
Analytics implementation needs a measurement plan
Installing GA4 or a tag manager does not give your team reliable measurement.
A B2B measurement plan should connect website actions to the sales process. The useful events depend on your conversion paths, but the plan may include:
- Demo or consultation form starts and submissions
- Trial or account creation
- Pricing-page actions
- Key CTA clicks
- Resource downloads
- Webinar or event registrations
- Qualified form routing
- Personalization impressions and interactions
- Campaign and source data passed into forms
The agency should define event names, triggers, parameters, consent behavior, environments, and test cases. Someone must also decide what reaches the CRM and which reports the team will use after launch.
Ask for these deliverables:
- Written measurement plan
- Data-layer or event specification
- Tag and event implementation
- Consent-state behavior
- Cross-domain or embedded-form handling when required
- QA evidence from staging and production
- Reporting or dashboard handoff
- Ownership for future event changes
Analytics cost rises when forms live across several tools, conversion paths cross domains, consent rules vary by region, or legacy tags need cleanup. Those are integration problems. A proposal should name them before development starts.
Design and development must support the systems
CMS, personalization, and analytics change the front-end build.
Designers need states for dynamic content, missing content, long translations, variant headlines, forms, errors, and success messages. Developers need components that accept structured content, protect layout rules, emit tracking events, and preserve a usable default when another service fails.
This is why a line-by-line feature comparison can mislead buyers. Two proposals may include the same CMS and analytics tools. One team may have priced the modeling, component architecture, integration, and QA. The other may have priced account setup.
Ask each agency to show where these responsibilities live:
- CMS schema and editorial preview
- Front-end component logic
- Personalization rules
- Form and CRM integration
- Analytics events
- Consent management
- Error and fallback behavior
- Deployment and rollback
A clean system gives each tool a narrow job. The CMS manages content. The front end renders pages. Analytics records agreed actions. The CRM handles known contacts and sales workflow. Your team can replace one layer without rebuilding the rest.
How to compare redesign proposals
Normalize the scope before you compare totals.
Create a sheet with one row for each required deliverable. Add columns for included, excluded, client-owned, assumption, acceptance test, and post-launch owner. Then make each agency complete the gaps.
Pay attention to these phrases:
- “Client to provide content” without a format, deadline, or approval process
- “CMS integration” without named content types
- “Analytics setup” without events and QA
- “Personalization ready” without segments, variants, or fallback logic
- “SEO migration” without redirects and validation
- “Training included” without audience, format, or documentation
Vague scope moves risk to the buyer. It also makes the lowest estimate look more complete than it is.
A stronger proposal explains tradeoffs. It may recommend a smaller first release, defer low-value templates, limit personalization, or separate migration cleanup from implementation. That is useful scope control.
A practical phased budget
You can phase the work without building a disposable first version.
Phase 1: Foundation
Set positioning, buyer paths, sitemap, design system, core components, CMS models, base analytics, SEO migration rules, and launch QA. This phase should create a maintainable site that works for the general qualified buyer.
Phase 2: Content scale
Add deeper solution pages, case studies, resource templates, campaign components, and editorial workflows. Use what the team learned from publishing in the new system.
Phase 3: Personalization
Launch one segment-specific journey with preview, fallback, analytics, consent behavior, and an owner. Expand after the team proves it can maintain the first use case.
Phasing reduces initial scope. It does not excuse weak architecture. The first phase still needs content models and components that can support the next two.
Frequently asked questions
How much does CMS implementation add to a website redesign?
The added cost depends on content types, editor workflows, permissions, preview, integrations, and migration condition. Ask for those deliverables as separate scope instead of accepting one “CMS setup” line item.
Does website personalization require a separate platform?
No. A CMS can store variants while the front end, CRM, campaign data, or another rules layer decides which variant to show. Choose the split that your team can maintain and test.
What analytics work should a redesign proposal include?
It should include a measurement plan, event specification, implementation, consent behavior, staging and production QA, and ownership after launch. A base tag alone does not cover measurement.
Can we add personalization after launch?
Yes, if the CMS content model, front-end components, analytics events, and preview system can support variants. Plan those boundaries during the redesign, then launch personalization as a later phase.
Price the system you expect to operate
A B2B website with structured content, personalization, and pipeline measurement carries more responsibility than a brochure site. Your budget should reflect the decisions, integrations, migration work, and QA needed to keep that system useful.
Compare proposals by what each team will design, build, migrate, test, and hand over. Then choose the scope your marketing team can own after launch.
Virdis plans custom website strategy, design, development, CMS architecture, conversion paths, and measurement as one system. That gives serious B2B teams a site they can run without turning each campaign into a development project.
