Building the Replatforming Business Case

A replatforming business case has to answer three questions for the people who approve it: why change, what will it take, and what do we get. This guide gives you a structure, a way to estimate effort from your own inventory, and the risks to plan for. It deliberately contains no stock numbers. Estimates built from your own content, team and proof of concept are the ones decision-makers trust.

The structure

A business case that gets approved usually has these sections:

1. The problem today, in measurable terms.
2. The options, including doing nothing and improving the current platform.
3. The effort and cost of the recommended option, estimated from an inventory.
4. The benefits, tied to the measurements in section 1.
5. The risks and how you'll manage them.
6. The plan: phases, roles and decision points.

Start with a baseline

You can't show improvement without a starting point. Measure before you change anything. The "Measuring Website Performance" section of Building a Website suggests combining leading and lagging measures:

Measure	Type	Where it comes from
Lighthouse score, desktop and mobile	Leading	Lighthouse, on your key page types
Engagement: bounce rate, time on page, time on site	Leading	Your analytics tool
Conversion rate	Lagging	Your analytics or CRM
Online revenue, if relevant	Lagging	Your commerce or finance systems

Add measures of how your team works, because that's where a CMS change shows first:

• Time to publish: how long a typical new page or campaign takes from request to live.
• Developer requests for content changes: how many tickets a month are really content or layout changes that editors could make themselves with page management.
• Duplicated content: how many places the same content is maintained by hand across sites or channels.
• Platform effort: time spent patching, upgrading and hosting the current CMS.

Estimate effort from an inventory

Effort comes from a handful of drivers. Count each one for your project; the counts, not a rule of thumb, are the basis of your estimate.

Driver	How to count it	What makes it bigger
Content types	Distinct kinds of content (articles, products, people, events)	Inconsistent structure in the source, heavy rich-text formatting
Content volume	Items per type, per locale	Many locales, content that needs cleaning or rewriting
Page types and components	Distinct page layouts and building blocks in the design	Many one-off designs; components that behave differently per page
Assets	Number of images and files, and where they live today	Missing alt text, assets spread across several systems
Integrations	Search, forms, analytics, CRM, commerce, sign-on, translation	Custom or legacy integrations without a modern API
URLs and SEO	Indexed URLs, redirects needed, URL changes planned	A new URL structure, many inbound links
Sites and channels	Websites, apps and other destinations	Different structures per site
People	Editors to train, teams with different workflows	Many teams, approval rules that differ by team

Two things sharpen the estimate more than anything else:

• A proof of concept. Building your riskiest use cases with real content shows how long your components, model and integrations actually take. See Run a Two-Week Proof of Concept.
• A migration sample. Migrating one representative content type end to end shows the real cost of cleaning and mapping. Migrating Content into Agility with an AI Agent describes importing a sample to Staging and reviewing it before scaling up, and Legacy Content Migration covers the wider approach.

Phases and roles

Agility recommends a phased, iterative approach: launch a first phase as a minimum viable product, then improve in smaller releases (Building a Website). A typical plan:

Phase	What happens	Main roles
Discovery and proof of concept	Inventory, fit check, POC, business case	Sponsor, lead developer, content architect, editors
Content architecture	Content, component and page models; workflow and roles	Content architect, editors, admin
Build	Front end, preview, Web Studio, integrations, environments	Developers
Migration	Map, clean, import and verify content; redirects	Developers, editors
Training and governance	Editor training, roles, approval workflows	Admin, editor leads
Launch	Content freeze, cutover, DNS, monitoring	Developers, admin, sponsor
Iterate	Improvements in small releases against the baseline	Everyone

Content work can start before the front end is finished. Agility recommends that editors enter content early, so developers build against real content instead of placeholders.

Benefits to quantify

Tie each benefit to a baseline measure, and estimate it from your own numbers:

• Fewer developer hours on content changes, from the ticket count above, once editors manage pages themselves.
• Faster publishing, from the time-to-publish measure.
• Less duplicated effort, where content is reused across sites, apps and channels instead of copied.
• Less platform maintenance, because Agility hosts and maintains the CMS.
• Performance and conversion, from the Lighthouse and conversion baselines, once the new front end is live.

Risks and how to manage them

Risk	How to manage it
Losing search rankings	Inventory URLs early, build a redirect map, and test redirects before launch.
A content model that doesn't fit	Model with real content and review it with editors in the POC.
Migration taking longer than planned	Migrate a sample first; budget for cleaning, not just copying.
Integration surprises	Build the riskiest integration in the POC.
Editors not adopting the new platform	Involve editors in the POC and train before launch.
Being locked in	Confirm how you would export everything. See Data Portability and Exit.

Make it faster with AI

AI coding tools and the Agility CMS MCP Server can shorten the build and migration phases: the AI tool can create models and seed content as well as write the front end. If you plan to rely on that, test it in the POC and estimate from what you measure. Vibe Coding with Agility describes the approach and its limits.

Related

• What Your Team Builds vs What Agility Provides
• Website Deployment Checklist
• Is Agility Right for Your Project?