All resources

Writing an Infrastructure Modernisation Strategy That Survives a Budget Conversation

Most modernisation strategies fail at the funding stage because they read as a technology wish list. What to put in one so it reads as a business case.

4 min read
Writing an Infrastructure Modernisation Strategy That Survives a Budget Conversation. Cover illustration: three steps rising from now to next to a flagged target state.

Most infrastructure modernisation strategies fail at the funding stage. Not because the technology is wrong, but because the document reads as a list of things the technology team would like.

A strategy that gets funded answers a different question. Not what should we replace, but what does the business lose by not doing this.

Lead with the constraint, not the solution

Open with what is actually limiting the business today.

Storage pressure that delays projects. Hardware past end of life that cannot be supported. A data centre with cooling that was never designed for the load, or a generator you are about to lose. Technology effort absorbed by maintaining platforms nobody wants, instead of doing work people asked for.

Those are business problems with technology causes. Written that way, they survive a reading by somebody who does not care what a hypervisor is.

The version that does not survive opens with a target architecture diagram.

Say why now

Every modernisation strategy competes with the option of doing nothing for another year, and doing nothing is usually cheaper this financial year.

So name the thing that makes this year different. A major programme already underway that you can align with. Hardware refresh decisions converging. A facilities risk with a date on it. A licence agreement coming up for renewal.

Convergence is the strongest argument available. Several renewals landing in the same window means doing them together costs less than doing them separately, and that is an argument a finance team recognises immediately.

Put dates on the target state

A strategy without dates is a position paper.

Operate from the cloud by a stated year. Close the owned data centres by a stated year. Those are commitments, and writing them down is what turns the document into something people plan against.

They will move. That is fine. A date that slips six months still did its job, because everything downstream was scheduled against it. A strategy with no dates produces no schedule and no pressure.

Write the principles down, and keep them short

Principles are how you avoid relitigating the same decision every time a new requirement arrives.

Cloud first, meaning new solutions get assessed against cloud and managed options before traditional infrastructure. Reduce operational complexity, meaning prefer the thing with less to maintain. Secure by design. Resilient by design. Right-sized, meaning proportionate to your actual scale rather than to the reference architecture of an organisation 10 times your size.

Five or six is enough. Each needs a sentence saying what it means in practice, or it is a poster rather than a principle.

That last one deserves emphasis. A lot of modernisation strategies quietly adopt a design built for an enterprise far larger than the organisation reading it, and the operating overhead is what eventually kills the project.

Tie it to the strategy that already exists

Your organisation has a strategic plan. It talks about people, customers, growth, service outcomes.

Map each modernisation outcome to one of those. Better device provisioning supports people. More reliable digital services support customers. Lower lifecycle risk and clearer cost visibility support business performance.

This is not decoration. It is how the document gets read by an executive who is choosing between your programme and three others, and it is the section most technology teams skip.

Be honest about what it costs to run

The weakest part of most of these documents is the operating model.

Moving to cloud does not remove work. It changes it, from maintaining infrastructure to governing and orchestrating services. That needs different skills, and sometimes different people.

Say so. A strategy that claims the team will simply have more time is the one that gets challenged in the room, and rightly.

The test

Give the draft to somebody senior who is not in technology. If they can tell you what the business gets, roughly when, and what it will cost to run, it is ready.

If they come back asking what a landing zone is, you have written a technical design and labelled it a strategy.

Element Digital does infrastructure work in Hobart and across Tasmania. If you have a modernisation strategy to write or a draft to pressure test, get in touch.

Read it elsewhereMarkdownOpen in ClaudeOpen in ChatGPT

Read next

Ready to get started?

Let us talk about what you are trying to achieve, no obligation, just a conversation.

Get in touch