Mental model
In the previous lesson you built a three-horizon roadmap. Each horizon has a cost, and that is exactly this lesson’s subject: how to estimate the cost of migration, and seeing how this course’s own source material answered that question wrongly.
The corpus’s own contradiction: four numbers, zero agreement
This course’s raw source material (the Day 14/15 documents) has four different figures for the 3-year migration CAPEX, and none agrees with any other:
- Day 14, a partial-scope calculation: EUR 1.2M - 2.5M
- Day 14, in the same document, a full itemized breakdown: EUR 2.05M - 3.9M (all components are unsourced round numbers, and the figure is wrongly described as “conservative”, while the DigiCert survey it is compared with measures only a partly overlapping scope)
- Day 14, an executive summary rounding: EUR 2-4M
- In a YAML export, with false precision:
capex_eur_low_m: 2.05,capex_eur_high_m: 3.9
On top of that, Day 15 derives the cost of the discovery phase as a percentage of Day 14’s, but along two different, contradictory paths: in one place it says “~25-30%” to get EUR 650K-1.35M, in another “40-55%” to get EUR 1.4M-2.2M. The second percentage does not even match its own stated base (40-55% of EUR 2.05-3.9M): the correct arithmetic gives ~EUR 0.82-2.15M, not 1.4-2.2M.
This is a provenance lesson: why we use none of them
None of these four figures entered this course’s numbers.json as SOURCED or MEASURED, because none rests on a real source (an audit report, a real bank project, a published methodology); all the itemized components are unsourced, and the two derivation methods contradict each other. The right way to fix this is not to pick “whichever looks more right” (recall that in M6 a BSI date appeared taken from the wrong document and matched to the wrong year, and that the corrected version is documented in a note on 2031SOURCED; picking a figure that “looks more reasonable” is also a kind of fabrication), but to accept none of them as true.
Instead, the cost model tool works on this principle: bank parameters (such as number of systems, certificate inventory, staff capacity) are taken as input, each assumption (for example “X person-hours per certificate”) is listed explicitly and is editable, and the output is a range always presented with an ESTIMATED tag, never as a “true” total. DigiCert’s own survey data is third-party data this course could not verify independently (so it cannot enter numbers.json as SOURCED yet); if it can be verified, it may be one of several data points informing the default values, but on its own it is not a reference that guarantees the “true total”.
The scope here: methodology, not the tool
This lesson teaches not the tool itself but the methodology behind it: (1) break down the cost components (inventory and discovery, certificate renewal, HSM and infrastructure upgrades, staff training, testing and validation), (2) write an assumption for each component and state its source (a SOURCED data point, or an ESTIMATED guess), (3) produce a range, not a single point estimate, (4) keep every assumption transparent, so that it can change when the bank enters its own parameters. The tool makes this methodology interactive; this lesson teaches how to set those assumptions defensibly for an atypical bank before you use it, because running the tool is not enough: you need to be able to defend the range it produces against your own bank’s reality.