The Replatforming Business Case Template

A replatforming business case needs four things most internal proposals skip: a real total cost of ownership comparison rather than just license fees, a risk-adjusted timeline, a named owner for each phase, and a rollback plan stated up front. This is the template built from what actually gets a replatform approved and funded at the executive level.

Last verified: September 6, 2026.

Why most business cases get stuck at approval

The typical internal pitch focuses on the destination platform's features. Executives approving seven-figure technology spend care about a different set of questions: what does this cost beyond the obvious line items, what's the risk if it goes wrong, and who is accountable at each stage. A business case built around features gets questioned; one built around cost, risk, and ownership gets approved.

That's not because executives don't care about capability. It's that capability is the part they're delegating to you. The parts they can't delegate — committing budget, accepting risk, and assigning accountability — are the parts your document has to answer, and a features-led proposal answers none of them.

The four sections a real business case needs

1. True total cost of ownership. Platform licensing, migration and build cost, ongoing maintenance, and — the line most proposals omit — the cost of not migrating: technical debt accumulation, lost conversion from an aging platform, and the ongoing cost of integration workarounds that exist only because the current platform can't do something natively.

Most internal proposals price only the first two. Including the fourth changes the shape of the argument entirely, because it turns "should we spend this money" into "which of these two costs do we prefer," which is a question with a defensible answer.

2. A risk-adjusted timeline. Not a single best-case date, but a range with named risk factors — data complexity, integration count, internal team availability — and what would push the timeline in either direction. A range with named drivers is more credible than a point estimate, and it protects you later: when a named risk materializes, you're executing the plan rather than explaining a slip.

3. Named ownership per phase. Discovery, build, testing, cutover, and post-launch each need a specific accountable owner — a person, not a project team collectively responsible for everything. Collective ownership reads as unowned to anyone who has approved a project before.

4. A stated rollback plan. Executives approving risk want to see that failure has been planned for, not just hoped against. State the rollback trigger and who's authorized to pull it, before anyone asks. Volunteering this is one of the strongest credibility signals a proposal can carry, because it demonstrates the plan was written by someone who has thought about what happens when it doesn't go perfectly.

How to build the TCO comparison

The comparison that persuades is current-state versus future-state over a defined horizon, usually three years, with the same categories on both sides:

The last two lines are the ones that make the case. They're also the ones that require honest internal input rather than a vendor's pricing sheet, so gather them first — they take the longest and they're what a skeptical CFO will probe.

How to price the cost of not migrating

This is the section that separates a business case from a purchase request, and the one that takes the most work because none of the numbers arrive pre-packaged. Four categories, each of which can be estimated honestly enough to defend:

• Engineering time spent on workarounds. Ask the team what percentage of their sprint capacity goes to compensating for platform limitations rather than building anything new. Multiply by loaded cost. The figure is usually larger than anyone has said out loud.
• Release velocity foregone. Count the roadmap items deferred in the last year because the current platform made them expensive. That's not a hypothetical cost — it's a list with names on it.
• Conversion left on the table. If site speed, checkout, or mobile experience are measurably behind where the new platform starts, that gap has a revenue value at current traffic.
• Risk of the status quo. Ageing platforms accumulate end-of-life dependencies, security exposure, and a shrinking pool of people who can maintain them. This one resists precise pricing, so state it as a risk rather than dressing it as a number.

State the assumptions behind every figure inline, in the document. A number with a visible assumption invites a conversation about the assumption; a number without one invites a conversation about your credibility.

Building the risk-adjusted timeline

Give a range, not a date, and name what moves it. The four factors that actually drive a replatform timeline are integration count, custom functionality, data cleanliness, and internal decision-making speed — see replatforming timelines by complexity for how each behaves.

Present each as a named risk with a stated impact and a stated mitigation. "If catalog remediation takes longer than the two weeks assumed, the build phase moves by up to three weeks; we're mitigating by auditing the catalog in discovery rather than during migration" is a sentence an executive can approve. "Q3, roughly" is not.

The one thing worth protecting in that range is the launch window itself. If the honest range would put a cutover inside a peak season, say so in the business case rather than discovering it in the schedule — see replatforming during peak season.

The one page executives actually read

Whatever the full document's length, write a one-page summary and put it first: the ask, the three-year TCO comparison as two numbers, the timeline range, the named owners, and the rollback trigger. Everything else is supporting evidence for a reader who wants it.

A useful test of that page: if the only thing anyone reads is this page, and they approve on the strength of it, would you be comfortable with what they think they approved? If not, something material is buried in the appendix that belongs on the first page.

Objections, and how to answer them

"Can't we just fix the current platform?" Sometimes yes, and the business case is stronger for having assessed it. Answer with the specific list of things that cannot be fixed on the current platform at any reasonable cost, rather than a general argument that the platform is old.

"What if it goes wrong?" This is what the rollback plan and the named owners are for. Answer with the mechanism, not with reassurance.

"Why now?" The strongest version of this answer is a real external constraint — a platform end-of-life, a contract renewal, a season to get ahead of. The weakest is that the team is ready. If there's no external constraint, say so honestly and argue from the accumulating cost of waiting instead.

"The last big project ran over." Usually the most substantive objection in the room. Answer it by naming the four consistent causes of replatform overruns and showing which of them this plan has already addressed — see why replatforms go over budget.

What to leave out

Feature comparisons belong in a separate technical evaluation document, not the business case itself. Mixing the two dilutes the business case's actual argument — cost, risk, accountability — with platform-comparison detail an executive audience doesn't need in order to approve budget. Attach it as an appendix if it's asked for.

Also leave out the vendor's marketing framing. A business case that reads like it was assembled from a platform's sales deck invites the question of who actually did the analysis.

Evidence that helps

A comparable migration carries more weight than any projection. buybuy BABY's move from Oracle ATG to Shopify Plus — 30,000+ SKUs and 8.3 million customer records in 31 days — is useful in a business case not as a timeline to promise but as evidence that the risk being priced is a managed one. The full story is worth citing where the audience is skeptical that a migration of your scale can be executed at all.

Anatta's other success stories serve the same purpose for different profiles — subscription-heavy businesses, custom-platform migrations, and multi-brand estates.

Who to write it with

A business case assembled by one person in isolation reads like one person's opinion, and it stalls on the first question it can't answer. Three inputs are worth gathering before drafting, from people who will be in the approval conversation anyway.

Finance, for how the organization actually accounts for a project like this — what's capitalized, what's operating expense, which budget year the spend lands in. Getting this wrong doesn't just weaken the case; it can send the whole thing back for rewriting after approval in principle.

The engineering lead, for the honest version of what the current platform costs in maintenance and workarounds. That number is the backbone of the cost-of-not-migrating section and it can only come from the people doing the work.

Whoever owns the commercial roadmap, for the list of things the current platform has blocked. A roadmap item with a name and a date is far more persuasive than a general claim about velocity.

After approval

Two things worth doing immediately, while the document is fresh and everyone remembers what they agreed to.

Convert the named phase owners into actual calendar commitments rather than names on a page — an owner who first learns of their accountability three months in is not an owner. And record the assumptions the case rests on somewhere the project will keep looking at them, because the ones that turn out to be wrong are what the risk-adjusted timeline was for, and a range nobody revisits is just a wider guess.

Then move to scoping. The business case establishes that the project should happen; the RFP establishes what it will actually consist of and what it will cost.

What to build next

A funded business case leads directly to two artifacts: the replatforming checklist, which turns the approved plan into a working list, and the replatforming RFP template, which turns it into vendor responses you can actually compare. The wider method those sit inside is how to replatform without losing revenue.

Frequently Asked Questions

What should a replatforming business case include beyond cost?

A risk-adjusted timeline, named phase ownership, and a stated rollback plan — the three things that separate a fundable proposal from a features pitch.

How detailed should the TCO section be?

Detailed enough to include the cost of not migrating — technical debt, lost conversion, integration workarounds — alongside the obvious licensing and build costs. Most proposals price only the latter, which frames the decision as pure spend rather than a comparison between two costs.

Should the business case include a platform feature comparison?

No. Keep it in a separate technical evaluation document or an appendix. Mixing feature detail into the business case dilutes the argument an executive audience actually needs in order to approve budget.

Why include a rollback plan in a funding document?

Because executives are approving risk, and a plan that names its own failure condition and the person authorized to act on it is more credible than one that doesn't. Volunteering it before it's asked for is a strong signal the plan is realistic.

How do you price the cost of not migrating?

In four parts: engineering time spent on platform workarounds, roadmap items deferred because the platform made them expensive, measurable conversion gaps, and the risk of aging dependencies. State the assumption behind each figure inline — a number with a visible assumption invites a conversation about the assumption rather than about your credibility.

How long should a replatforming business case be?

However long the evidence requires, but with a one-page summary first: the ask, the three-year TCO comparison as two numbers, the timeline range, named owners, and the rollback trigger. If someone approved on that page alone, you should be comfortable with what they think they approved.