Most legacy migration business cases fail in the boardroom for the same reason: they compare a specific, uncomfortable number (migration cost) against a vague, hand-wavy one ("technical debt," "risk"). Boards fund specific numbers. If your cost of inaction isn't quantified as concretely as your cost of migration, the migration loses by default — even when it's clearly the right call.

This is the framework we use internally before recommending any client actually proceed past a diagnostic. It's not proprietary — use it directly, whether or not you ever work with us.

Start With the Question the Board Actually Asks

Nobody on a board asks "should we modernize?" in the abstract. They ask some version of: "why spend this money now, instead of another year of the status quo, or instead of some other investment?" Your business case has to answer that exact question, not a more comfortable version of it.

Step 1: Quantify the Cost of Inaction

This is the step most business cases skimp on, and it's the one that actually wins the argument. Break it into components you can attach real numbers to:

  • License/platform cost trajectory. Not this year's invoice — the trend. If your licensing model scales with usage (as most low-code and legacy vendor contracts do), project it forward three to five years at your actual growth rate, not a flat assumption.
  • Talent cost and risk. What does it cost to hire and retain specialists in your current stack today, versus three years ago? What's your bus-factor if your one or two platform experts leave?
  • Velocity tax. How much longer does a feature take to ship on the current platform than it would on a modern stack, and what's the opportunity cost of that delay compounding across your roadmap?
  • Risk exposure. Security findings, audit flags, unsupported dependencies, or a vendor's own published end-of-support timeline. These convert directly into a "what happens if we don't act" number, especially if compliance or insurance requirements are involved.

Even directional numbers here — "our platform costs will likely grow 10-15% annually at current usage trends" — are far more persuasive than "the current system is old and risky." Specificity is what separates a business case from a complaint.

Step 2: Price the Migration Honestly — Including What Could Go Wrong

The fastest way to lose credibility is a migration estimate that turns out to be fiction. Include:

  • The direct cost (audit, factory, enablement — whatever your delivery model looks like).
  • A realistic timeline with phases, not a single end date — boards fund phased plans more easily than big-bang ones, because each phase is a checkpoint to stop or continue.
  • What happens if it's slower or more expensive than estimated — your contingency plan, not just your contingency budget line.
  • What "done" actually means — feature parity, verified equivalence, or something else. Vague success criteria are where migration business cases quietly die in year two.

The one-page template

  1. Current state — platform, scale (apps/users/integrations), age, and known constraints.
  2. Trigger — the specific event forcing this decision now (renewal, EOL, security finding, talent risk, M&A, roadmap block).
  3. Cost of inaction, 3-year projection — license/platform trend, talent cost/risk, velocity tax, risk exposure. One number per line, sourced.
  4. Cost of migration — direct cost, phased timeline, contingency, and explicit success criteria.
  5. Net position — where the two lines cross, and what happens if you wait another year.
  6. Decision requested — not "approve migration," but the specific first commitment (e.g., "approve a fixed-price diagnostic to validate these numbers against our actual estate").

Need real numbers, not estimates, for line 3 and 4?

The Replatforming Audit turns this template's projections into evidence-backed figures specific to your estate — not industry averages.

Book a discovery call

Step 3: Ask for the Smallest Real Commitment, Not the Whole Program

The single biggest lever for getting a business case approved is shrinking what you're asking for. Don't ask a board to fund a multi-year replatforming program in one sitting — ask for a fixed-price diagnostic or audit that produces the evidence to justify (or rule out) the larger program. This does three things: it de-risks the ask, it gives the board a natural checkpoint, and it means your business case for the big program — if you get there — is backed by real data instead of a projection.

What to Leave Out

Two things weaken a business case more than they help it: technical jargon the board can't evaluate ("we need to move off our monolith to microservices" means nothing to a CFO), and vague urgency without a number attached ("technical debt is a growing risk" — how much, by when?). Every claim should be a number, a date, or a named risk with a source — not an adjective.

For the underlying economics that typically anchor line 3 of the template, see the true 5-year cost of staying on OutSystems as a worked example, or start with a Replatforming Audit to get your own numbers instead of a template's placeholders.

← Back to all articles Mendix vs OutSystems in 2026 →