InsightFinOpsInfrastructureWorkload placement1 September 2026

Your next infrastructure decision may already be showing up in the budget.

Natalia PletnevaCommercial Director, Inlight IT

Rising cloud spend, a difficult renewal, underused capacity or duplicated platforms can look like finance problems. Often they are signals that the architecture deserves another look.

FinOps helps identify where the economics have changed. The next step is to understand why, then decide whether the right response is optimisation or a broader infrastructure decision.

See the six signals

Cost signal / investigation / decision

SignalWhat has the cost done?

CauseWhy has it changed?

OptionsOptimise, or something larger?

TimingBefore the RFQ, not after.

Where decisions start

Three checks before the next infrastructure decision

Infrastructure decisions are usually discussed as technology decisions. In practice the first indication that one is coming often appears somewhere less obvious, and in our experience it is usually the budget.

Has the cost profile changed without the demand changing?

Cloud spend may be increasing without a corresponding change in demand. A renewal may come back materially higher than the previous term. Storage keeps growing while nobody is quite sure what is being retained. Each is a good reason to understand why before accepting the next bill.

What it testsCost against demand

Do you know the cause, or only the number?

An environment may simply be oversized. Reserved capacity may be poorly used. A data architecture may be creating transfer charges that were easy to underestimate when it was designed. A licence renewal may have changed the commercial assumptions behind an architecture that was perfectly reasonable three years ago.

What it testsCause before response

Is there still time to have choices?

The useful moment is before the procurement requirement is defined. Once a brief asks suppliers to quote a replacement for the current server estate, the responses will largely be variations on a new server estate.

What it testsTiming and optionality

The signal

A higher bill is a question. The investigation produces the decision.

The cost signal

Something has changed
Tells you where to look
Answers which workload, which platform, which agreement
Risk if used alone one financial measure determines the architecture

The architecture review

Establishes why it changed
Tells you what to do
Answers cost, performance, risk and operations together
Produces a decision while the options are still open

Cost signal

Investigate

Cause

Options

Decide

Sequence

A higher bill should trigger an architecture review, not a migration.

Where to look

Six financial signals worth investigating.

These are the six we would investigate first in a mid-market environment. Each should be tested for an optimisation response first, and each can also turn out to be the first sign of a larger infrastructure decision.

Signal 01 · Spend is increasing faster than demand

What you seeThe bill grows while users, transaction volumes and applications stay broadly flat. More demand should have a cost; the test is whether the increase lines up with it.

Optimise firstDevelopment and test environments running continuously, resources still sized for a demand peak that did not recur, services left running after a project closed, commitments that have drifted from actual consumption.

When it is architecturalThe underlying trend remains after the waste is removed. The question becomes whether the workload still suits the platform and commercial model it runs on.

Signal 02 · Provisioning no longer matches utilisation

What you seeA server built for an application that once required significant compute now spends most of its time lightly used. A system that started small reaches capacity every quarter and needs increasingly expensive additions.

Optimise firstRightsizing, consolidation, scheduling or a different consumption model. Infrastructure is frequently sized for conditions that existed when it was deployed, and those conditions rarely stay the same.

When it is architecturalUtilisation on its own says very little about where a workload should live. Review the relationship between the workload and the resources supporting it before moving anything.

Signal 03 · A renewal changes the economics

What you seeA substantial platform, virtualisation, database, support or infrastructure agreement reaches the end of its term on materially different commercial terms.

Optimise firstThe easiest operational decision is to renew what is already there, especially if the technology is working well. That may still be the right decision, provided it is a deliberate one.

When it is architecturalCompare the alternatives while there is still time to act, ideally six to nine months out. VMware is the current example for many organisations: renewal, refresh, a platform change or workload movement are all live options. PPK Mining Equipment moved a 3-node VMware estate to Azure Local when Broadcom renewal pressure turned a licensing question into a platform decision.

Signal 04 · Data movement or storage becomes a significant cost

What you seeStorage grows gradually, which makes it easy for inefficient retention and placement to become part of the normal bill. An architecture regularly moving large volumes between regions, on-premises infrastructure, SaaS platforms and users generates costs that were easy to underestimate at design time.

Optimise firstOld data retained at an unnecessarily expensive tier, backups and logs kept longer than recovery requirements justify, caching or archiving not in use, a connectivity model that no longer fits.

When it is architecturalAn application moves data repeatedly because its components are poorly placed. Sometimes the cost is telling you that the data and the compute using it should be closer together.

Signal 05 · Ageing infrastructure is becoming more expensive to keep

What you seeSupport costs increase as equipment moves beyond its standard warranty period, capacity becomes harder to expand efficiently, older platforms require more operational effort, and licensing or compatibility constraints narrow the available options.

Optimise firstCompare the replacement cost with the alternatives, including support, licensing, resilience, backup and recovery, operational effort, connectivity and the expected workload profile over the next several years. This is what an infrastructure refresh review weighs.

When it is architecturalFor a predictable 24x7 workload, new private infrastructure may still make excellent economic and operational sense. For another workload in the same estate, the refresh is the point at which public cloud, SaaS or a hybrid model becomes more attractive.

Signal 06 · You are paying for several platforms to do similar jobs

What you seeA new cloud introduced for one application, another platform arriving through an acquisition, separate backup tools remaining after workloads moved, branch infrastructure still running after most users shifted to SaaS, overlapping management or security products.

Optimise firstIndividually, each cost can appear reasonable. Reviewing the original requirement usually removes at least one overlap without touching the architecture.

When it is architecturalTogether they indicate the environment has become unnecessarily fragmented. Consolidation reduces cost, and also operational overhead, support complexity, and the effort of evidencing security and governance.

The cost is the starting point for the investigation, and the investigation is what produces the decision. Whether a workload should move is a question that comes later, once the cause is understood.

The criteria

The six things every option gets tested against.

Infrastructure cost discussions become too simplistic when one financial measure is expected to determine the architecture. A growing cloud bill, an expensive hardware refresh or a lower three-year quote each tells you something about the current environment. The decision still needs the workload context around it.

Different workloads have different economic characteristics. A predictable application running continuously favours a very different cost model from a development environment that is heavily used for several hours and idle for the rest of the day. Australian organisations also need to weigh local cloud-region pricing, connectivity, power, data residency and the operational cost of running infrastructure locally with a small team.

What is driving the current cost, and which architecture delivers the best value for this workload once cost, performance, risk and operations are considered together?

Consistent test set

01CostRun rate, commitments and the cost of change itself.

02PerformanceLatency, throughput and the profile the workload actually has.

03ResilienceBackup, recovery and what happens when a site or link fails.

04Security and complianceRegulatory requirements and data residency.

05Operational effortWhat running it costs a small team in practice.

06Expected growthThe workload profile over the next three to five years.

The response

There are usually six decisions available.

Once the cause is understood and the criteria are set, it helps to separate the possible responses into six categories, because the way the decision is framed tends to determine the answers you get.

Keep the architecture

Optimise

The architecture still fits, but there is waste or inefficient consumption to remove.

Retain

The current environment remains appropriate and the economics are acceptable. A deliberate decision to keep is still a decision.

Change what runs where

Move

A workload has a sustained technical, commercial or regulatory reason to run somewhere else.

Consolidate

Multiple platforms, services or infrastructure components are creating unnecessary duplication.

Rebuild the platform

Refresh

The architecture still fits, but the underlying platform has reached the point where it should be renewed.

Redesign

The architecture itself is creating persistent cost, performance or operational problems.

A rising Azure bill may lead to optimisation. A VMware renewal may lead to a platform refresh. A server refresh may reveal that three workloads belong on private infrastructure while two others are better suited to SaaS. The objective is to work out what the environment should look like next, whatever that turns out to be.

The timing problem

Do the analysis before the RFQ.

By the time an infrastructure decision becomes an urgent procurement exercise, much of the outcome has often been predetermined by the way the brief was written. If the RFQ asks suppliers to quote a replacement for the current server estate, the responses will largely be variations on a new server estate. If the brief says "migrate these virtual machines to Azure", suppliers will price a migration. If the requirement is to renew a platform before a deadline, the room to reconsider the platform shrinks quickly.

Analysis first

What should this environment look like for three to five years?

What should we actually be buying?

RFQ

Optimisation, consolidation and workload placement stay open while the architecture is still being shaped, before vendors begin quoting against a fixed brief.

Where to start

Most of the information already exists. It is just held in different places.

For a mid-market environment, a focused review is usually enough to get started. The invoices are in finance, the utilisation data is in monitoring tools, and the renewal dates are in somebody's calendar.

Optimise what can be optimised first, and sequence larger changes around the relevant renewal and refresh dates. Major architectural changes deserve a stronger basis than a single number: workload fit, economics, performance, risk and operations. The goal is to identify decisions early enough that the organisation still has choices.

Review

Bring the costs together

Infrastructure and cloud cost organised by workload or service.

Overlay utilisation and demand

Actual usage against business volume, not against last year's bill.

Surface the anomalies

Idle resources, unexplained growth, storage climbing quietly.

Map the renewal calendar

Every agreement and support date inside the next eighteen months.

Classify the workloads

Which warrant further investigation, and which are already settled.

Test the options

Against one consistent set of criteria, not a per-workload argument.

Sequence the work

Around the real renewal, refresh and support-expiry triggers.

Inlight IT view

FinOps can surface an architecture decision before the technology roadmap does.

FinOps is useful because it creates visibility and accountability around technology cost. Its greater value is that those numbers can expose where the technology model deserves another look, often well before the technology roadmap would have raised it. A renewal, cost increase or utilisation problem tells you that the assumptions behind the current environment should be checked. The review determines whether the answer is to optimise, keep, move, consolidate, refresh or redesign.

Cost tells you where to look. Engineering determines what to do.

Treat the cost as a signal, not a verdict

Understand the cause before choosing the response

Test optimisation before migration

Have the conversation before the RFQ

Delivery

Where this is delivered.

This analysis sits inside our Cloud & Infrastructure and Technology Procurement work: reviewing infrastructure and cloud cost by workload, assessing placement, planning renewals and refreshes, and building the roadmap before a procurement requirement is written.

Cloud & Infrastructure

Workload placement, cloud and infrastructure architecture, resilience and cost considered together.

Best whenThe question is where workloads should run and how the environment should be designed for the next three to five years.

Explore Cloud & Infrastructure

Infrastructure Refresh

Hardware lifecycle, VMware position, workload placement and recovery confidence, weighed together rather than collapsed into one rushed call.

Best whenA renewal or support-expiry date is approaching and the platform question should be settled before anything is bought.

Explore Infrastructure Refresh

Common questions

Questions organisations ask about FinOps and infrastructure cost

What is FinOps?

FinOps is the practice of creating visibility and accountability around technology cost: understanding consumption, allocating costs to workloads and services, rightsizing resources, managing commitments and removing waste. Its wider value is that the same financial information can identify where the technology model deserves another look, often well before the technology roadmap would have raised it.

Does a rising cloud bill mean we should move the workload?

Not on its own. A rising bill tells you where to look, not what to do. The first question is why the cost has changed. The cause may be an oversized environment, poorly used reserved capacity, a data architecture generating transfer charges, or a workload whose original hosting model has lost its economic advantage. Test the optimisation response first; whether the workload should move is a question that comes later, once the cause is understood.

Which financial signals are worth investigating?

Six are worth investigating first in a mid-market environment: spend increasing faster than demand, provisioning that no longer matches utilisation, a renewal that changes the economics, data movement or storage becoming a significant cost, ageing infrastructure becoming more expensive to keep, and several platforms being paid for to do similar jobs. Each should be tested for an optimisation response first, and each can also be the first sign of a larger infrastructure decision.

What does a VMware renewal change?

Changed commercial terms put a price on continuing with the status quo, which makes a renewal one of the best times to reconsider an environment. Depending on the estate, the options include renewing, changing platform, refreshing infrastructure, moving selected workloads or redesigning part of the environment. The comparison is worth running while there is still time to act, ideally six to nine months before the term ends.

How do we decide between public cloud and on-premises infrastructure?

The workload should drive the decision rather than a single cost measure. A predictable application running continuously favours a very different cost model from a development environment that is idle most of the day, and an application with significant data movement has different placement considerations from a standalone SaaS workload. Regulatory requirements, latency, resilience, staffing and operational capability can all outweigh a relatively small infrastructure saving.

When should the analysis happen?

Before the procurement requirement is defined. By the time an infrastructure decision becomes an urgent procurement exercise, much of the outcome has often been predetermined by the way the brief was written. Doing the workload, utilisation and commercial analysis first keeps optimisation, consolidation and workload placement open while the architecture is still being shaped.