Building the business case

On 15 July 2026, SharePoint Server 2016 and SharePoint Server 2019 both reached the end of extended support (2016 lifecycle, 2019 lifecycle, checked on 7 August 2026). The two dates are the same on purpose: Microsoft aligned the 2019 date with the 2016 one so that the later product would not lose support first (servicing policy, checked on 7 August 2026).

That date matters here more than anywhere else in this book, because it changed what one of your two options means.

Until 15 July 2026, doing nothing meant continuing to run a supported platform. After it, doing nothing means continuing to run a platform that receives no security updates. The activity is identical. The thing you are comparing against is not.

This chapter prices the recommendation chapter 4 produced. It does not remake it.

A recommendation is not yet a business case

Chapter 4 answered where, and why. This chapter answers what follows:

What does acting on the recommendation cost, what does not acting cost, and which parts of either number can you defend?

Notice what is not in that sentence. There is no "which option is better". That was decided, on constraints, in the open, and reopening it in financial language is the failure this chapter exists to prevent. It is a common one: a licence bundle turns out cheaper at the destination that was eliminated, and the recommendation quietly changes to the option that produces the better number. The constraint that eliminated it has not gone away. It has stopped being mentioned.

We recommend writing the recommendation at the top of the business case, unchanged, with its date. Everything below it prices that. If the numbers genuinely reopen the decision, that is a finding, and it goes back to chapter 4 with the constraint list in front of you.

Start with the work the recommendation already created

You are not beginning from a blank page. Chapter 4 asked you to record every eliminated path with the cost of removing it:

SharePoint Online          eliminated
  by: two full-trust solutions still required by the finance sites
  cost to remove: quoted at N days, not funded this year
  recorded: 2026-08-05

That N days is the first line of your business case. Chapter 4 called an eliminated path with a cost attached a priced door rather than a closed one, and this is the chapter that pays for it or decides not to. Do the same with the soft constraints: each already carries effort, and here that effort becomes money at rates you can show.

What you must not do is discover new work. If the business case is finding scope the inventory did not, the inventory is not finished, and chapter 2 is where that gets fixed.

The current state is not free

The baseline is the part most business cases get wrong, and they get it wrong the same way: the current state is entered as zero, because nobody is being invoiced for it this month. Build it properly. Each of these lines is a real payment or a real obligation:

The last line is where honesty is hardest, because nobody invoices it. Two administrators spending a third of their week on a farm is a real cost, and it does not disappear if the farm stays. If you cannot measure it, say what you did instead: an estimate from a named person is a defensible input; a number chosen because it looked reasonable is not.

Risk is not automatically money

Running without security updates changes your risk profile, and there is pressure to put a figure on that change. Resist it unless you can defend the figure. An expected-loss calculation needs a probability and an impact, and organisations rarely have either for their own estate. A number invented at that step will be the first one challenged, and when it falls it takes the credible lines with it.

Where a risk has a quotable cost, price it: an insurance premium that changes with the platform, a contractual penalty for running unsupported software, a compliance obligation with a stated deadline. Everything else belongs in the record as an identified risk, stated plainly, with no currency symbol. We would rather present a business case with an unpriced risk than one with an invented number, because the first can be discussed and the second can only be believed or not.

One-off and recurring are different currencies

Mixing them is the most common arithmetic failure in this work, and it survives review because both are in euros.

Change

  one-off
    remediation of what does not move as it is
    migration execution
    testing and validation
    training
    transition and parallel running

  recurring
    licences
    hosting or subscription
    support
    operations
    governance

A project of 150,000 with 30,000 a year afterwards is not comparable to 90,000 a year for staying where you are until you say over how long. At three years the first is 240,000 and the second is 270,000. At two years the order reverses. The horizon is not a detail of the model; it is the model.

State the horizon before you compute anything, and state why it is that number. A contract renewal, a datacentre lease, a hardware refresh and a compliance deadline are all defensible reasons to choose one. "Five years" chosen because it is a round number is not, and a reader who asks why five will not get an answer.

If you discount future cash flows, say which rate you used and where it came from. Most organisations have one. Using theirs makes the model theirs.

The quality of every number

This is the part of the chapter worth carrying into the rest of your work.

Chapter 3 sorted constraints by weight: hard and soft. Chapter 4 sorted them by speed: who can change this, and how fast. Here the axis is confidence, and it applies to every figure in the model:

Every figure in the model carries one of these labels. It takes a column, and it changes the conversation entirely, because it makes the shape of your uncertainty visible instead of averaging it away.

A total of 183,742 built from five approximations is not precise. It is a number with three digits of false confidence, and the moment a reader finds one soft input behind it, the whole model becomes suspect. The same model presented as "between 160,000 and 210,000, driven mainly by the number of forms that must be rebuilt, which we have bounded and not measured" is weaker on the slide and far stronger in the room.

That is the rule, and it is the one sentence of this chapter to keep:

Financial precision must not exceed evidential precision.

If a total is presented to the euro, every input behind it is quoted or measured. If any input is estimated or bounded, the total is a range, and the range is honest about which input is driving its width.

Benefits need evidence, exactly like costs

The same discipline applies on the other side, and it is applied far less often.

"Better collaboration" is not a benefit in a business case. It may well be true, and it may be the real reason the organisation wants this, and it still does not enter a model as a number, because nobody can check it.

What can enter: 420 support hours a year, taken from the ticket system, at a loaded hourly cost, where the reader can ask to see the query. Three physical servers retired, at their actual annual run cost, where the invoice exists. A licence line that ends on a known date. Storage no longer bought because content was archived rather than migrated, if chapter 2 counted it.

What cannot, unless the measurement exists: productivity gains per employee, hours saved by better search, faster onboarding. These are not dishonest claims. They are unevidenced ones, and putting them in the model puts the whole model at the mercy of the first person who asks how they were derived.

A benefit that cannot be monetised is still a benefit. It goes in the record, in words, under its own heading, and it is allowed to be the reason a decision is taken. What it is not allowed to do is contribute to a total that is presented as financial.

When two destinations survived

Chapter 4 left some readers with two viable destinations and a written comparison of the soft constraints that discriminated between them. Here that comparison acquires numbers, and both sides get the same six lines:

one-off cost · recurring cost, per year · delta against the baseline
benefits, evidenced · risks, unpriced · quality of the weakest input

That last line matters most. Two totals built from inputs of different quality are not comparable, and presenting them side by side without saying so is how a model misleads without anyone lying.

This is not a feature comparison returning through the back door. A comparison of two products ages badly; a comparison of what your estate costs at each destination stays meaningful for as long as the estate does.

The business case record

Chapter 4 ended by insisting that a recommendation is a record and not a sentence. The same is true here, in a form that is easier to get wrong because a business case is so often reduced to a single figure on a slide.

A business case is a model with provenance, not a number.

The record contains:

Recommendation           unchanged, from chapter 4, with its date
Horizon                  the number of years, and why that number
Baseline                 current state, line by line
One-off cost             the work that happens once
Recurring cost           what changes in the annual run
Evidenced benefits       measured or quoted, with the source
Unpriced benefits        in words, not in the total
Known risks              identified, priced only where quotable
Assumptions              stated, each one falsifiable
Unknowns                 named, not hidden inside a contingency
Review date              when this stops being trustworthy

Every material number carries where it came from and which of the five quality labels it holds. That column is what lets somebody reopen the case in a year without rebuilding it, which is the same test chapter 4 applied to the recommendation.

The review date deserves its own sentence. A business case built on a quote with a ninety-day validity is a business case with a ninety-day life, and saying so in the document is what stops it being presented, unchanged, eight months later.

Figure 5.1. The business case prices two paths from one recommendation. The unknowns are a layer of the model, not a line in it.

When a business case fails

Business cases rarely fail because the arithmetic was wrong. They fail in ways a reader can smell without being able to name:

The current state is entered as zero, so the change appears to cost the full amount while the alternative appears to cost nothing.

One-off and recurring are added together, producing a total that is large, impressive and meaningless, with no horizon stated anywhere.

Benefits are monetised without evidence. One challenged assumption takes the credible lines down with it, because the reader can no longer tell which numbers were derived and which were chosen.

Unknowns are hidden inside a contingency percentage. Fifteen per cent added at the end conceals exactly what a decision-maker needs to see.

A precise total is derived from vague inputs. The most common defect, and the one this chapter names as its rule.

The recommendation changes to produce a better number. The worst of the six, because it is invisible in the finished document. The constraint that eliminated the option is still true; it has simply stopped being mentioned. That one deserves stating as plainly as the rule at the top:

The business case exists to price the recommendation, not to reverse-engineer one that passes a financial threshold.

Out of scope

Prices, licence terms and product costs. They move faster than a book can, they differ by agreement, geography and volume, and Microsoft does not publish them as documentation. This chapter teaches the method and sends you to your own agreement and to real quotes for the numbers. Anything else would be a figure with a date on it that ages badly and misleads confidently.

Whether Extended Security Updates exist for SharePoint Server 2016 or 2019. We do not know. Microsoft's Extended Security Update programme is documented for certain products, and the lifecycle pages for these two do not list one (2016 lifecycle, 2019 lifecycle, checked on 7 August 2026). If your baseline depends on that answer, get it from Microsoft or your account team in writing, because it is the difference between a supported baseline and an unsupported one.

Procurement, negotiation and approval. Getting a better price and getting a signature are both real work, and neither is this chapter. What this chapter can do is make the approval a decision about a model somebody can examine, rather than a decision about a number somebody has to trust.

Governance at the destination. How the target environment will be run is chapter 6, and it belongs before the build rather than after it.

Before you continue

• The recommendation from chapter 4 sits at the top of the case, unchanged and dated
• The baseline includes licences, infrastructure, operations, support, known remediation and people time, and is not zero
• One-off and recurring costs are separated, and the horizon is stated with the reason for that horizon
• Every material number carries its source and one of the five quality labels
• The total is a range wherever any input behind it is estimated or bounded
• Benefits in the total are measured or quoted; the rest are recorded in words, outside it
• Risks without a defensible price are identified and left unpriced, not hidden in a contingency
• The document carries a review date, and it is no later than the earliest quote expiry

If you want the destination question answered before you price it, the SharePoint Compass gives a rules-based recommendation with its reasons in about two minutes. Chapters 2 to 4 are the long version, and this chapter is what happens after them.

Guide version 0.1.0·Chapter version 0.0.0·Last reviewed 7 August 2026