# Building the Replatforming Business Case

> Source: https://agilitycms.com/docs/overview/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](/docs/overview/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](/docs/overview/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](/docs/overview/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](/docs/developers/migrating-content-with-an-ai-agent) describes importing a sample to Staging and reviewing it before scaling up, and [Legacy Content Migration](/docs/developers/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](/docs/overview/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](/docs/overview/data-portability-and-exit). |

## Make it faster with AI

AI coding tools and the [Agility CMS MCP Server](/docs/developers/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](/docs/developers/vibe-coding-with-agility) describes the approach and its limits.

## Related

- [What Your Team Builds vs What Agility Provides](/docs/overview/what-your-team-builds-vs-what-agility-provides)
- [Website Deployment Checklist](/docs/developers/website-deployment-checklist)
- [Is Agility Right for Your Project?](/docs/overview/is-agility-right-for-your-project)

---

## Related pages

- [Evaluating Agility](https://agilitycms.com/docs/overview/evaluating-agility.md)
- [What Your Team Builds vs What Agility Provides](https://agilitycms.com/docs/overview/what-your-team-builds-vs-what-agility-provides.md)
- [How Agility Works: A 10-Minute Architecture Tour](https://agilitycms.com/docs/overview/how-agility-works.md)
- [Is Agility Right for Your Project? When It Fits and When It Doesn't](https://agilitycms.com/docs/overview/is-agility-right-for-your-project.md)
- [Choosing a Headless CMS: A Capability Checklist and Questions to Ask Any Vendor](https://agilitycms.com/docs/overview/choosing-a-headless-cms.md)
- [Run a Two-Week Proof of Concept](https://agilitycms.com/docs/overview/run-a-two-week-proof-of-concept.md)
- [Headless, Hybrid or Traditional: Choose Your Delivery Model](https://agilitycms.com/docs/overview/choose-your-delivery-model.md)
- [Getting Your Content Out: Data Portability and Exit](https://agilitycms.com/docs/overview/data-portability-and-exit.md)
- [Evaluate Agility with an AI Agent in 30 Minutes](https://agilitycms.com/docs/overview/evaluate-agility-with-an-ai-agent.md)

Index of every docs page: https://agilitycms.com/docs/llms.txt