# Business case: TIBCO BusinessWorks 5 to Apache Camel

An outline, not a deck. Fill in the bracketed parts from your own estate and the accompanying
spreadsheet (`esbexit-business-case-template.xlsx`), then build it in whatever tool your change
board actually reads. Ten slides; cut what does not apply, do not pad what does.

---

## 1. Title

**[Estate name]: moving off BusinessWorks 5**

Sponsor, date, and the one-line ask: a decision to fund a pilot, or a decision to fund the whole
migration. Say which. A vague ask gets a vague answer.

---

## 2. Why this is on the agenda now

State the actual trigger: vendor support terms, a hiring problem for BW5 skills, an incident that
traced back to the platform, a licence renewal date. Do not invent urgency; use the real one. If
there is no forcing event yet, say that plainly and frame the slide as "why start now rather than
later," not "why this is on fire."

---

## 3. Current spend

- Annual maintenance and support: **[from your invoice, not an estimate]**
- What that buys today: licence, support contract, the people who keep it running
- One line on what does *not* shrink immediately after migration: hosting, on-call, and support
  staff mostly stay, so see "retained run cost" on the spreadsheet, currently modelled at 15%

---

## 4. What a scan actually finds

Pull this straight from the spreadsheet's coverage section, or from a real scan once you have run
the toolchain against your estate:

- **Translated**: a rule emits it, no marker. No effort line.
- **Caveat**: a rule fires but leaves a warning to read and a decision to make.
- **Manual**: no rule exists yet. A `TODO_HUMAN` marker and a compile that succeeds around it.

Show the split as three numbers, not a paragraph. If you are quoting the coverage report's
weighted split (currently 96.37% / 2.27% / 1.36%), say plainly it is weighted by how often each
type occurs in a scanned estate, not by how many distinct types exist, and a change board will ask
the difference.

---

## 5. Effort estimate

Copy the "Calculation" block from the spreadsheet as-is: activities per line, person-days per
line, build effort, test overhead, total, and the low/high band. Do not round the band away. The
±30% width is the honest answer to "how sure are you," and a number without it invites a challenge
you cannot win.

---

## 6. Cost and payback

- Estimated cost = total effort × day rate
- Annual saving = maintenance × (1 − retained run share)
- Payback period in months

State the day rate you used on the slide, not just in the appendix. It is the single most
arguable number in the whole model, and hiding it reads as avoidance.

---

## 7. What this estimate does not cover

Say it before someone else does:

- Parallel running during cutover
- Data migration
- Re-certification of anything regulated
- The calendar cost of a change freeze around the cutover window

These are real costs, specific to your estate, and a model that guessed at them would be lying
about precision it does not have. Naming them here is what makes the number on slide 6 credible.

---

## 8. Risks a change board will actually ask about

Pick the ones that apply to your estate; do not present all of them as equally severe if they
are not. Each is a real, documented behaviour of the generated output, not a hypothetical:

- **Nothing has been proven equivalent yet.** The generator's output compiles, and a generated
  application starts with its routes loaded. No message has been through one, and nothing has been
  compared against BusinessWorks behaviour. Until an equivalence harness exists, "starts" and
  "works" are different claims.
- **Some activities need a person, not a rule.** Where no rule exists, the route still compiles,
  with a `TODO_HUMAN` marker in place of the missing logic. That work has to be scheduled, not
  assumed away by the coverage percentage.
- **Some rules carry a caveat by design.** A caveat activity is not broken; it is a place where
  the generator made a call it flags for review, often because the two platforms genuinely do not
  agree on the semantics (locking, ordering, transaction scope). Budget review time for these, not
  just rewrite time.
- **The estimate is a field average, not a measurement of your estate.** Every coefficient on the
  spreadsheet came from real migrations, not from yours specifically, until you have run a scan.

---

## 9. What we are asking for

State the actual decision: budget and timeline for a scoped pilot (a handful of processes, chosen
for coverage of the palettes you actually run), or a go/no-go on the full estate. A pilot answers
slide 8's uncertainty with evidence instead of another estimate.

---

## 10. Appendix

- The spreadsheet, linked or attached
- Link to the coverage report / scan output for your estate, once you have one
- esbexit.com/calculator/ carries the same model, live, with every coefficient published