How to Build the Business Case for a DXP Migration (Template Included)

Why a DXP Migration Business Case Matters Now

Three pressures are forcing DXP decisions onto enterprise roadmaps in 2026. First, Sitecore is pushing customers off on-prem XP and XM toward the Sitecore AI bundle, which means anyone on Sitecore 9 or 10 is in a forced architecture conversation. Second, license renewals are landing at the same time as composable alternatives — Contentful, Storyblok, Optimizely SaaS, Kentico Xperience — are mature enough for enterprise workloads. Third, CFOs are scrutinizing every SaaS line item for consolidation, and DXP is one of the largest.

In other words, the days of getting a DXP migration approved on a vendor demo and a budget estimate are over. Therefore, you need a structured DXP migration business case that quantifies what you spend today, what you would spend in each scenario, what you risk, and what you gain. Without that document, the project either stalls indefinitely or ships on hope.

The Stakeholders Your DXP Migration Business Case Must Convince

A DXP migration business case is not one document for one reader. It is one document that has to land with five different audiences at the same time. Specifically:

• The CFO wants total cost of ownership across five years, broken into license, hosting, implementation, and run cost. They want a payback period and a cash-flow profile.
• The CMO wants velocity. How long is the feature freeze? When can the marketing team launch new campaigns again? What does authoring look like on day one after cutover?
• The CIO or CTO wants risk. Vendor lock-in, integration breakage, security posture, and the recovery plan if the migration runs late.
• The Enterprise Architect wants the technical decision matrix. What replaces what. Where do APIs land. How does identity flow. What happens to Coveo, search, personalization, and analytics.
• The Board or Steering Committee wants two paragraphs and one chart. They want to know that someone responsible has thought about this end to end.

If your business case speaks to only one of these five, it will get challenged in the room and sent back for rework. Build it for all five from the start.

Step 1: Quantify the Cost of Staying Put

The first mistake most teams make is comparing the new platform to a free baseline. Staying on your current DXP is not free. As a result, the first section of any honest DXP migration business case is the run-rate cost of doing nothing.

For a typical Sitecore XP estate running on Azure with Coveo, that number lands between $700K and $2.2M annually, all-in. The breakdown: Sitecore license ($200K to $600K), Coveo license ($150K to $400K), Azure infrastructure ($100K to $400K), partner support and managed services ($150K to $500K), and internal team allocation ($100K to $300K). On top of that, add the deferred-cost backlog: end-of-life modules, security patches you skipped, and integrations duct-taped to keep the lights on.

Project that line forward five years with vendor price increases, end-of-support penalties, and the inevitable infrastructure refresh. The number gets uncomfortable fast. That uncomfortable number is what your DXP migration business case is competing against — not zero.

Step 2: Model Total Cost of Ownership for the New DXP

Now model the same five-year cost line for each candidate platform. For example, if you are weighing Sitecore AI against Contentful and Optimizely, build three side-by-side TCO columns. Each column needs the same six rows: platform license, hosting and CDN, implementation, integration rework, training and change management, and ongoing run cost.

Two warnings here. First, vendors lead with year-one license savings. The five-year line tells a different story once you add hosting (Vercel, Netlify, or your own infrastructure), front-end developer cost, personalization tooling that is no longer in the bundle, and the analytics layer you used to get for free. Second, do not ignore migration cost. A realistic enterprise migration runs $400K to $1.5M depending on integration count, and content modeling alone consumes 70 percent of that. Our companion article on the Sitecore to headless CMS migration decision framework walks the cost ranges for each composable alternative.

The TCO comparison is the single most quoted slide in any DXP business case. Make sure yours is defensible line by line, with sources and assumptions written down. Do not hand the CFO a number you cannot defend in a follow-up meeting.

Step 3: Build the Risk and Compliance Matrix

The risk matrix is where most business cases get thin. Vendors do not ship risk matrices because risk is what they want you to forget. However, your CIO will not approve a multi-million-dollar migration without one. Therefore, build it yourself.

List eight risk categories: vendor lock-in, integration breakage, content loss, security and compliance, performance regression, accessibility regression, bilingual support gaps, and team capability. For each one, score the current state, score each candidate scenario, and write a one-line mitigation plan. Bilingual support deserves its own line for any Quebec or Canadian enterprise — a SaaS-first DXP that handles English well but struggles with French Canadian routing, dictionaries, and SEO will surface during user acceptance testing, not before.

Compliance gets its own line too. If you handle personal data under Quebec Law 25, payment data under PCI, or health data under provincial frameworks, the DXP must support data residency, retention policies, and audit logging. Some SaaS DXPs do this well. Some do not. Your business case must say which.

Step 4: Calculate Revenue and Productivity Upside

Cost and risk get you to neutral. Upside gets you to approved. The fourth section of your DXP migration business case quantifies what the new platform unlocks that the old one does not.

Three upside lines tend to land with executives. First, content velocity: how many pages per week can your authors ship after the migration versus before. A modern composable DXP typically doubles authoring throughput once authors are trained. Second, feature time-to-market: integrations, personalization experiments, and new microsites that previously took quarters now take weeks. Third, marketing experimentation: an integrated experimentation layer (Optimizely, Ninetailed, or Sitecore Personalize) generates measurable revenue lift when used consistently — typically 2 to 8 percent of digital revenue.

Be conservative on the upside lines. CFOs discount marketing forecasts hard, and rightly so. A DXP migration business case that promises 30 percent revenue growth from a platform swap does not get approved; one that promises measurable authoring productivity and a defensible 2 percent lift in conversion rate does.

Step 5: Phase the Migration with Quick Wins

The fifth section of the business case is the phasing plan. A DXP migration that takes 18 months to deliver a single visible win is a political risk, regardless of how strong the TCO numbers are. Specifically, executive sponsors need to point to outcomes every quarter, not at the end.

The pattern that works for enterprise DXP migrations is the strangler approach. You launch the new platform on a single property — a microsite, a campaign hub, or a documentation portal — within 90 days. From there, you migrate sections quarter by quarter. The business case should plot four quarters of measurable wins: a launched microsite by Q1, a migrated campaign hub by Q2, the first major property migrated by Q3, and the legacy estate sunset plan kicked off by Q4. Reference the iA Financial Group and CCQ engagements as proof that this phasing actually works in regulated bilingual enterprises.

Avoid the big-bang plan. We have not seen one succeed in the mid-market enterprise range. If a vendor or integrator is pitching you a single 12-month cutover, ask them for three references in your size band who shipped on time. Most cannot produce them.

The DXP Migration Business Case Template (Section by Section)

Here is the structure we use. Copy this into a Google Doc, a Confluence page, or a slide deck — whichever your executive team reads. Eight sections, in order:

1. Executive summary (1 page). The recommendation, the ask, the timeline, and the headline number. If a board member reads only this page, they should know what you want and why.
2. Current state assessment (2 pages). Run-rate cost, deferred-cost backlog, integration count, content volume, team allocation. Include the cost-of-staying-put number from Step 1.
3. Options considered (1 page per option). Sitecore AI, two or three composable alternatives, hybrid, and “do nothing.” Each option gets a paragraph and a red-yellow-green scorecard against your decision criteria.
4. Five-year TCO comparison (1 page, table). The six-row, three-column-or-more table from Step 2. Footnoted with sources.
5. Risk and compliance matrix (1 page). The eight-row matrix from Step 3, with mitigation lines.
6. Upside and benefits (1 page). The three upside lines from Step 4, with conservative dollar estimates and confidence intervals.
7. Phasing and roadmap (1 page). The four-quarter strangler plan from Step 5, with milestones, owners, and dependencies.
8. Recommendation and ask (1 page). The platform pick, the budget request, the team request, the timeline, and the decision deadline.

Eight pages total. If your DXP migration business case runs longer than that, you are losing the board. If it runs shorter, you have not done the work. Aim for the middle.

Mistakes That Sink a DXP Migration Business Case

Four mistakes show up repeatedly when business cases get sent back for rework. First, comparing to a zero baseline — pretending the current DXP is free. Second, taking vendor TCO numbers at face value without pricing the front-end, hosting, and personalization layers that used to be bundled. Third, ignoring opportunity cost — the 12 months of feature freeze that happens during any serious DXP migration. Fourth, building the case around the platform you already prefer instead of the platform that wins on the matrix.

The fix for all four is the same: write down your assumptions, source every number, and let the matrix do the recommending. A DXP migration business case that survives a hostile board meeting is one where the recommendation falls out of the data, not the other way around. For deeper context on the underlying decision, see Gartner’s DXP definition and the Sitecore Technology MVP directory for vendor-credentialed perspectives.

How Sengo Pressure-Tests Your DXP Migration Business Case

Sengo is one of the few partners in Canada that holds 2× Sitecore Technology MVP credentials and is also an official implementation partner for Contentful, Storyblok, Optimizely, Kentico, Netlify, ai12z, and Coveo. We have ex-Coveo backend developers on the team. We are bilingual (EN and FR) and based in Quebec. That combination is why our DXP migration business case reviews do not depend on which logo we are paid to push.

Most enterprises engage us in one of two ways: a focused two-week review where we pressure-test an existing business case before it goes to the board, or a four-to-six week build where we develop the case from current-state assessment through final recommendation. Either path includes the TCO model, the risk matrix, and the phasing plan. If you want to anchor on the audit before the architecture conversation, our Sitecore audit surfaces the integration footprint and content-model debt that drive the cost-of-staying-put number. For broader strategic context, the Sitecore platform page and our platform evaluation solution cover the wider DXP practice.