Infrastructure as Code business case papers get rejected far more often than the technology deserves. The engineering argument is almost always sound — provisioning is manual, environments drift, every release carries avoidable risk — but the paper that reaches the finance committee counts build hours, omits the platform run cost, and offers no evidence that saved time became anything the business can bank.
This guide gives you the working instead of the argument. It covers the costed baseline a reviewer expects, the four benefit streams that carry almost every case, how to price engineer hours and failed changes without double counting, the payback and net present value maths finance asks for, and a fully worked two-year model for a 240-server estate. It sits alongside our DevOps consulting and cloud architecture practice.
It assumes you already run infrastructure at some scale rather than starting fresh. The Infrastructure as Code approach applies the same discipline to servers, networks and policy that version control long ago applied to application code, and it is the discipline that made cloud computing repeatable rather than merely rented. If you have not yet baselined delivery capability, our DevOps maturity assessment guide is the right starting point, because a return calculation needs a measured starting position to mean anything at all.
Table of contents
- What an Infrastructure as Code business case must prove
- Build the Infrastructure as Code business case cost baseline
- The four benefit streams in an Infrastructure as Code business case
- The Infrastructure as Code business case formula
- How to price provisioning effort in an Infrastructure as Code business case
- Putting a number on failed changes, drift and waste
- Payback, NPV and sensitivity in an Infrastructure as Code business case
- A worked Infrastructure as Code business case for a 240-server estate
- Does the choice of tool change the numbers?
- Infrastructure as Code business case benchmarks and what good looks like
- Mistakes that sink an Infrastructure as Code business case
- Phasing an Infrastructure as Code business case for early benefits
- Reporting the Infrastructure as Code business case after approval
- Frequently asked questions about the Infrastructure as Code business case
- References
What an Infrastructure as Code business case must prove
An Infrastructure as Code business case makes four claims, in order, and a reviewer tests each one separately. That the current way of working costs real money. That the proposed change removes a named portion of that cost. That the saved capacity has somewhere to go. And that the number survives when the central assumption is halved.
It is a financial document, not a technical one
The audience is a finance director and an executive sponsor, not a platform team. Every technical claim in an Infrastructure as Code business case needs a monetary translation and an evidence source, and anything that cannot be translated belongs in an appendix rather than in the headline ratio.
The three questions reviewers always ask
What would have happened anyway without this spend? Where does the released engineering capacity actually go, and who confirms it? What happens to the answer if the central assumption is half as good as claimed? A paper that answers all three in advance is approved far more often than one with a larger headline percentage.
Why “faster provisioning” is not a benefit
Provisioning speed is a leading indicator. Nobody banks a shorter build time. The benefit is what the recovered hours produce: features delivered earlier, incidents avoided, environments switched off, audits that no longer consume a fortnight. A case that stops at cycle-time metrics asks the finance function to finish the argument on your behalf, and it usually declines.
What a credible case contains
Six artefacts: a costed baseline of current provisioning, an itemised investment schedule, four quantified benefit streams with named owners, a two-year cash flow, payback and net present value figures, and a sensitivity table. Anything less is an opinion with decimal places attached.
Build the Infrastructure as Code business case cost baseline
Start an Infrastructure as Code business case with cost, not benefit. It is the half most teams understate, and an understated denominator collapses the moment a reviewer adds the missing lines back in.
Module development and migration effort
The largest one-off line. Writing reusable modules, importing existing resources into state, and retiring the manual runbooks they replace all consume senior engineering time. Price the hours at the same fully loaded rate you use on the benefit side, or your Infrastructure as Code business case values an hour spent differently from an hour saved.
Platform ownership: the line most models omit
Modules, pipelines and policy libraries are a product with an operating cost that never ends. Somebody maintains provider versions, reviews changes and answers questions. Carrying 1.5 full-time equivalents at senior rates is realistic for a mid-market estate, and leaving it out of years two and three is the single most common structural error reviewers look for.
Tooling, state management and policy
Count the automation platform, remote state storage and locking, secret management, policy-as-code enforcement and drift detection. Include year two at contracted uplift rather than the introductory discount, because launch pricing is why a model looks better in the deck than in the ledger eighteen months later.
Training, enablement and disruption
Every engineer learning a new provisioning workflow is delivery you did not get that week. Dual-running the manual process alongside the automated one costs more than either alone, and that overlap belongs in the denominator of the Infrastructure as Code business case rather than in a footnote.
| Cost line | What it must include | Year 1 (240 servers) | Where the figure comes from |
|---|---|---|---|
| Module development and migration | Module authoring, state import, runbook retirement | £180,000 | 3,600 hours at the blended rate |
| Platform ownership | 1.5 senior engineers, fully loaded, ongoing | £142,500 | HR cost-per-head, not base salary |
| Tooling, state and policy | Automation platform, state locking, policy, scanning | £48,000 | Contract schedule at year-two pricing |
| Training and enablement | Formal training, pairing, internal documentation | £35,000 | Hours at the same rate used for benefits |
| External enablement | Consulting, reference architecture, review | £70,000 | Statement of work, plus contingency |
| Total investment | All of the above, one window, one scope | £475,500 | The denominator of the ratio |
The four benefit streams in an Infrastructure as Code business case
Almost every credible case draws from the same four streams. Naming them separately matters, because each has a different owner, a different evidence source and a very different realisation risk.
Provisioning and change effort released
Hours engineers stop losing to tickets, manual builds, configuration by hand and the rework that follows. This is usually the largest stream and always the most contested, because released capacity only becomes money when somebody can show what it produced instead.
Environment and licence waste removed
Automated teardown, scheduled shutdown and genuinely ephemeral environments stop you paying for idle non-production capacity. This stream is the easiest to evidence, because the invoice already exists and the reduction appears on it. Our Azure cost optimisation checklist covers the specific controls that produce it.
Failed changes and drift remediation avoided
Reproducible builds and reviewed, version-controlled changes cut both the number of failures and the cost of each one. Incident records already exist, which makes this the stream auditors trust most and the one least likely to be argued down in review.
Audit, compliance and security evidence
Policy-as-code and declarative state turn evidence gathering from a fortnight of screenshots into a query, and the same records answer most cybersecurity assurance questions without a manual trawl. Quantify the effort reliably and the risk reduction conservatively, because a reviewer discounts a probability-weighted loss far harder than a timesheet. Our cloud security posture assessment guide sets out the controls this stream depends on.
| Benefit stream | What you measure | How it converts to money | Realisation risk |
|---|---|---|---|
| Provisioning and change effort | Engineer hours per request, by activity | Hours × blended rate × realisation factor | High — needs a named destination |
| Environment and licence waste | Idle non-production spend and seat count | Direct reduction on the cloud invoice | Low — appears on the bill |
| Failed changes and drift | Change failure rate, remediation hours | Failures × average cost per failure | Low — incident records exist |
| Audit and compliance effort | Days per audit, hardening review hours | Days × rate, plus reduced remediation | Low for effort, high for risk value |
The Infrastructure as Code business case formula
The arithmetic is deliberately simple. The judgement sits entirely in what you allow into each side of it.
The core calculation
Return equals net benefit divided by total investment, expressed as a percentage over a stated period. Net benefit is total benefit minus total investment. An Infrastructure as Code business case costing £753,000 across two years and returning £1,142,000 produces a net of £389,000 and a return of 52%. Always state the window in the same breath as the percentage, because a 52% two-year return and a 52% annual return are entirely different propositions.
Choosing the measurement window
Two years is the honest default. One year flatters the costs and understates the benefits, since module coverage ramps through the first twelve months. Three years starts to include benefits your current architecture may not survive to deliver, and experienced reviewers know it.
Pricing an engineer hour
Use the cost per head finance already recognises: salary, employer national insurance, pension, benefits, equipment and an allocated share of overhead. For a UK mid-market infrastructure role that commonly lands near £82,000 against a £62,000 base. Divide by productive hours — roughly 1,650 a year after holiday, sickness and training — and the blended rate is £50. Senior platform engineers are costed separately at £95,000.
Applying a realisation factor
Cutting 11,900 hours of provisioning effort is not the same as banking £596,000. Some released time enters the roadmap, some absorbs into slack, and some funds the platform work itself. Sixty per cent is a defensible default, so the model claims £358,000 and survives questioning precisely because the haircut is visible rather than hidden.
How to price provisioning effort in an Infrastructure as Code business case
Provisioning effort is the largest stream and the one most likely to be challenged. Price it carefully and the rest of the Infrastructure as Code business case inherits the credibility.
Measure the request, not the impression
Take a sample of forty recent infrastructure requests from the ticket system and total the engineering hours actually recorded against each. Estimates from a workshop are worth roughly nothing in review, because the first challenge is always where the number came from and a ticket export answers it in one line.
The baseline for a 240-server estate
Nine hundred and forty provisioning and change requests a year, at 13.5 recorded engineering hours each, is 12,690 hours. That includes waiting for approval and scheduling, building and configuring, verification and rework, and documentation. Roughly another 2,100 hours a year disappear into chasing configuration drift that nobody planned for.
What the automated position looks like
Three hours per request, covering the change, the review and the pipeline run. That is 2,820 hours against 12,690, releasing 9,870 hours, and drift chasing falls by around 2,030 hours. The gross release is close to 11,900 hours, or £596,000 at the blended rate.
The double counting trap
An hour freed from manual building cannot also be claimed as an hour freed from drift chasing and again as faster feature delivery. Map every claimed hour to exactly one stream and publish the mapping. This single discipline removes most of the inflation from a first-draft model.
Putting a number on failed changes, drift and waste
Two streams sit here, and both are unusually easy to evidence because the underlying records were written by people with no interest in your funding request. That is precisely why an Infrastructure as Code business case should lead with them when the audience is sceptical.
Change failure rate as a cost driver
Watch the distinction between rate and volume, because it catches people out. Six hundred and twenty in-scope infrastructure changes at a 19% failure rate is 118 failures a year. At an average £1,850 each — remediation hours plus business disruption — that is £218,300 before anything improves.
What reproducibility actually changes
The failure rate falls to around 7%, giving 43 failures, and the cost of each falls to roughly £1,030 because rollback is a reverted commit rather than an improvised repair. That is £44,290, and the difference of £174,000 is the annual steady-state benefit this stream contributes.
Environment and licence waste
Non-production capacity of £430,000 a year, running at 38% idle outside working hours, is the standing target. Scheduled shutdown, automated teardown and genuinely ephemeral environments remove about 40% of that spend, or £172,000 a year, and it lands directly on the invoice rather than in a timesheet.
Severity weighting keeps you honest
Weight by severity or the model drowns in noise. Only changes that touched a customer-facing service or breached a stated objective belong in the benefit. Internal tooling failures matter operationally, but claiming them as avoided business cost is exactly the padding that gets a whole paper sent back.
Payback, NPV and sensitivity in an Infrastructure as Code business case
A percentage alone rarely closes the decision. Finance functions think in cash timing, and three additional figures do most of the persuading.
Simple payback period
Payback is the month cumulative benefit overtakes cumulative investment. It is the figure executives ask for first, and it is easy to compute honestly because it needs no assumption about discount rates. In the worked model, payback lands inside month 15.
Net present value and the discount rate
Net present value restates future cash in today’s money. Apply your organisation’s hurdle rate — 10% is a common UK private-sector default, while public-sector cases follow the HM Treasury Green Book. Discounting net flows of minus £115,500 and plus £504,500 at 10% gives an NPV near £312,000, comfortably positive, which is the answer that actually decides the question.
Sensitivity analysis
Run at least one downside case and show it. Halve the realisation factor on provisioning effort and two-year benefit falls to £879,000, net to £126,000, the return to 17%, and payback slips to month 20. An Infrastructure as Code business case that still clears the hurdle rate under a halved central assumption is far more persuasive than one that only works at full strength.
Be careful with internal rate of return
Internal rate of return is the discount rate at which net present value reaches zero. On a short two-year model with a single year of negative net cash flow it produces mathematically valid but absurd percentages. Quote payback and NPV, and offer internal rate of return only if finance specifically asks and the cash flow profile supports it.
| Line | Year 1 | Year 2 | Two-year total |
|---|---|---|---|
| Module development and migration | £180,000 | £70,000 | £250,000 |
| Platform ownership | £142,500 | £142,500 | £285,000 |
| Tooling, state and policy | £48,000 | £53,000 | £101,000 |
| Training and enablement | £35,000 | £12,000 | £47,000 |
| External enablement | £70,000 | £0 | £70,000 |
| Total investment | £475,500 | £277,500 | £753,000 |
| Provisioning and change effort | £168,000 | £358,000 | £526,000 |
| Environment and licence waste | £86,000 | £172,000 | £258,000 |
| Failed changes and drift | £70,000 | £174,000 | £244,000 |
| Audit and compliance effort | £36,000 | £78,000 | £114,000 |
| Total benefit | £360,000 | £782,000 | £1,142,000 |
| Net position | −£115,500 | £504,500 | £389,000 |
A worked Infrastructure as Code business case for a 240-server estate
The table above is the model. This section explains where each figure came from, because a business case without provenance is a spreadsheet nobody can defend in a meeting.
The starting position
Two hundred and forty servers and virtual machines across three environments, six delivery teams, 45 engineers, and 940 infrastructure requests a year handled through a ticket queue. In-scope changes fail at 19%. Non-production capacity costs £430,000 a year and sits 38% idle outside working hours. Two audits a year consume 68 engineer-days of evidence gathering.
The investment
£475,500 in year one and £277,500 in year two, totalling £753,000. The largest one-off line is £180,000 of module development and migration; the largest persistent line is platform ownership at £142,500 a year, which does not taper. External enablement of £70,000 falls away entirely after year one.
Year one benefits
£360,000, weighted towards the streams that arrive early. Environment teardown produces savings within weeks of the first automated schedule, while the provisioning stream only reaches half its steady-state value because module coverage is still growing. Year one closes at minus £115,500, which is normal and should be stated openly rather than smoothed away.
Year two and the two-year result
£782,000, as coverage reaches steady state and the realisation factor applies across a full twelve months. Year two nets £504,500, cumulative net is £389,000, and the two-year return is 52%. A moderate, well-evidenced Infrastructure as Code business case earns more funding than an aggressive number a reviewer dismantles in ten minutes.
Does the choice of tool change the numbers?
Less than vendors suggest and more than engineers expect. The benefit side barely moves between mature tools; the investment side moves considerably, and that is where the choice earns or loses its place in the paper.
Where the tool genuinely matters
Three places: how much existing infrastructure can be imported rather than rebuilt, whether your team already has the language, and whether state management is your problem or the platform’s. Everything else is preference, and preference does not belong in a financial appendix.
Single-cloud versus portable tooling
A cloud-native template language is cheaper to start and harder to leave. A portable tool costs more in initial abstraction and preserves optionality. Our multi-cloud versus single cloud analysis covers how to price that optionality honestly rather than assuming it is free.
Managed platforms versus self-hosted
A managed platform converts engineering hours into a subscription line. For estates under roughly 300 resources that trade is usually favourable, because the alternative consumes senior time you do not have. Model both and put the comparison in an appendix.
Do not let the tool choice delay the paper
Teams lose entire quarters comparing tools while the manual estate carries on costing money. Write the Infrastructure as Code business case with a named default and a stated switching cost, and let the funding decision proceed in parallel with the technical selection.
| Option | Effect on investment | Effect on benefit | Best suited to |
|---|---|---|---|
| Cloud-native template language | Lowest start-up effort, no state to run | Unchanged within one provider | Committed single-provider estates |
| Portable declarative tool | Higher abstraction and state cost | Unchanged, plus retained optionality | Mixed or changing estates |
| General-purpose language SDK | Highest skill and review overhead | Marginal gain on complex logic | Strong software engineering teams |
| Managed platform subscription | Converts hours into a licence line | Arrives sooner, slightly smaller | Estates under roughly 300 resources |
Infrastructure as Code business case benchmarks and what good looks like
Benchmarks locate you; they do not set your target. Quote them as context in an Infrastructure as Code business case and keep your own evidence as the argument.
Typical payback windows
Most mid-market programmes should target payback between twelve and twenty months. Under twelve usually means the investment was a tooling purchase rather than a capability change. Beyond twenty-four months the case competes badly against everything else on the capital plan, and the sponsor tends to lose interest before benefits arrive.
Delivery benchmarks worth citing
The DORA research programme publishes the industry’s most durable clusters for deployment frequency, lead time, change failure rate and restoration time. Use them to justify the size of the improvement you forecast, not the money — the financial translation stays your responsibility, as our DevOps ROI method sets out in detail.
When the case is genuinely weak
Sometimes the honest answer is no. If your estate is small and stable, if change volume is genuinely low, or if the binding constraint sits in product discovery rather than delivery, the return will be thin and you should say so. Our digital strategy work often finds the constraint somewhere other than the pipeline.
Sizing effects for smaller estates
Below roughly sixty resources, a dedicated platform capability rarely pays for itself, and the Infrastructure as Code business case usually rests on managed services plus opinionated defaults rather than a build. The four streams still apply; the investment side simply looks completely different.
Mistakes that sink an Infrastructure as Code business case
Every error below has been used to reject a real Infrastructure as Code business case. Removing them before submission costs an afternoon and saves a funding round.
Counting build hours only
Manual provisioning costs far more than the build itself: waiting, scheduling, verification, rework and the drift that follows. An Infrastructure as Code business case built on build time alone understates the benefit by roughly two thirds, and it is usually the reason a genuinely strong programme looks marginal on paper.
Omitting the platform run cost
Modules and pipelines need an owner in year three as much as in year one. Leaving that team out of the later years is the most common structural error, and it is the first thing an experienced reviewer checks.
Assuming full realisation
Valuing every released hour at the full rate implies the headcount fell or the output doubled. Neither happened. State a realisation factor between 50% and 70% and show the arithmetic both before and after applying it.
Baselining against your worst quarter
Choosing the quarter that contained two major outages doubles the apparent benefit and destroys credibility when somebody plots twelve months. Use a rolling twelve-month baseline and publish the underlying series alongside the model.
| Mistake | How it distorts the number | The challenge a reviewer makes | The fix |
|---|---|---|---|
| Counting build hours only | Understates benefit by roughly two thirds | “Is that the whole request, or just the build?” | Total recorded hours per request |
| Platform run cost omitted | Denominator drops by hundreds of thousands | “Who owns the modules in year three?” | Carry the team for the full window |
| No realisation factor | Every freed hour valued at the full rate | “Where did that capacity actually go?” | Visible haircut, typically 50–70% |
| Double counting hours | One saved hour appears in two streams | “Show me this hour in only one place” | One hour, one stream, published mapping |
| Worst-quarter baseline | Improvement measured from an outlier | “Plot the whole year for me” | Rolling twelve-month baseline |
| Benefits claimed too early | Full-year value booked in a partial year | “When exactly did this go live?” | Phase against the delivery plan |
Phasing an Infrastructure as Code business case for early benefits
Sequencing decides the payback month more than tool choice ever will. Put the cheapest, fastest-returning work first and the cash profile of an Infrastructure as Code business case improves without changing a single assumption.
Start with the highest-volume resource type
Whatever you provision most often is where automation pays first. For most estates that is application servers and their networking, not the exotic components that consume design time and appear twice a year. Order the delivery plan inside your Infrastructure as Code business case by request volume, not by technical interest.
Take the environment waste early
Scheduled shutdown and automated teardown of non-production capacity need very little module coverage and land on the invoice within a month. Doing this in the first quarter is what keeps the year-one deficit at £115,500 rather than double that.
Migrate existing resources by import, not rebuild
Importing running infrastructure into managed state is dramatically cheaper than rebuilding it, and it avoids a change freeze nobody will approve. Where a rebuild is genuinely necessary, sequence it with a planned migration rather than as part of this programme, as our cloud adoption guidance sets out.
Leave the hardest estate until coverage pays
Legacy systems with undocumented configuration will consume disproportionate effort. Schedule them last, price them separately, and be prepared to leave a small residual manually managed. A 90% automated estate with an honest exception list beats a stalled attempt at 100%.
Reporting the Infrastructure as Code business case after approval
An Infrastructure as Code business case that is never revisited teaches the organisation that these numbers are decoration. Reporting is what converts a forecast into an operating discipline.
Set the measurement contract up front
Before funding is released, agree which measures will be reported, from which systems, by whom, and on what cadence. Write it into the approval paper. Retrofitting measurement six months later is how a programme ends up arguing about definitions instead of results.
The monthly pack
One page: resource coverage under managed state, hours per request against baseline, change failure rate, non-production spend, and phased benefit actual against forecast. Pull the figures from the pipeline and billing systems directly rather than a hand-maintained spreadsheet, which our data analytics practice can automate in a fortnight.
Quarterly re-forecasting
Re-forecast every quarter against the same model structure. Change the inputs, never the method, or the comparison stops meaning anything. If a stream underperforms by more than 20% for two quarters running, revise it down publicly — credibility built by an honest downgrade pays for itself at the next funding round.
When to stop reporting
Stop programme-level reporting once the capability is business as usual and the measures have moved into normal service reporting, typically after eight quarters. Continuing beyond that turns a decision tool into administrative overhead, and the operational metrics survive on their own merit.
Frequently asked questions about the Infrastructure as Code business case
How long before the investment turns positive?
For a mid-market estate, expect cumulative net position to cross zero between month twelve and month twenty. Year one is usually negative. Any model showing a positive first year deserves a careful look at whether platform ownership was included for the full period.
Can we build the case without historical data?
Partly. Ticket systems and billing consoles will give you request volumes, recorded hours, change outcomes and idle capacity within a fortnight, even with no prior reporting. Audit effort usually needs a conversation with the compliance team, so if that is unavailable, build the Infrastructure as Code business case on the first three streams and note the omission.
Should module development be capitalised?
Your accounting policy decides, and it may legitimately allow it. The version leadership reads should still show the full ongoing cost, with any capitalisation treated as a finance footnote rather than a way to shrink the denominator.
Does this apply to a twenty-server estate?
The method applies; the shape of the answer changes. At that size the investment is managed tooling rather than a platform team, benefits are dominated by environment waste and failed changes, and payback is often under eight months because the outlay is small. Our managed IT services model is frequently the cheaper route at that scale.
What if we are migrating to the cloud at the same time?
Sequence them and split the benefits explicitly, or both papers will claim the same savings. The migration owns the platform change; the Infrastructure as Code business case owns the provisioning and drift savings that follow. Our cloud migration business case guide covers how to divide the two without double counting.
References
DORA: The Four Keys Metrics Guide
GOV.UK: The Technology Code of Practice
GOV.UK Service Manual: Deploying Software Regularly
GOV.UK Service Manual: Measuring Success
NCSC Secure Development and Deployment Guidance
NIST SP 800-218: Secure Software Development Framework
Terraform Language Documentation
Microsoft Learn: Bicep Documentation
AWS CloudFormation Documentation
