Ageing servers should not decide your next platform. A refresh is an architecture and recovery decision, not a like-for-like replacement carried into the next cycle.
The risk is not that old infrastructure fails. It is a like-for-like refresh that carries the same architecture and recovery uncertainty into the next cycle. Inlight IT helps decide what to replace, what to modernise and what belongs on-premises — then delivers it without carrying old risk forward.
- Engineering-led, not quote-led
- The platform question settled before hardware is bought
- Recovery treated as part of the decision
The estate still runs, but the margin between normal operations and a real incident has narrowed.
Hosts are harder to manage. Storage is closer to the edge of comfort. Firmware updates feel riskier than they used to. Backups run, but recovery has never been proven under pressure. A failed host, disk, switch or power path would cause more disruption than the business is comfortable carrying.
Updates that used to be routine now carry more risk than the team is comfortable taking on.
Capacity and reliability are closer to the limit, and performance issues are becoming more common.
Backup jobs complete, but restore order and immutability have never been tested under pressure.
A single failed host, disk, switch or power path would now disrupt the business, not just a service.
Ageing hardware, VMware pressure, recovery confidence and workload placement often arrive together.
At first the decision sounds simple, replace the ageing hardware. But once the estate is looked at properly, the real questions surface. Select one to see what is behind it.
Test the platform question before anyone buys hardware, then make the call.
This is where refresh conversations often become too neutral, with every option treated as equally sensible. They are not. The work is to separate the decisions that pressure tends to fuse together, then take a clear path.
A clean replacement with better monitoring, validated backup and lifecycle control, without turning it into a project it does not need to be. The "do less" answer, and often the right one.
Where the business still needs on-premises compute but the old three-tier model is past its useful life, HCI gives better resilience, simpler operations and clearer recovery than the legacy design.
Stay on VMware temporarily, move to Azure Local or Nutanix, use Azure VMware Solution as a bridge, consider Proxmox, or move selected workloads straight to Azure, decided workload by workload.
Some workloads are a better fit for Azure or SaaS, so the local footprint reduces and there is less to buy. A good outcome, not a smaller sale.
Settle the platform question first, then refresh in controlled stages.
The work does not start with a platform assumption. It starts with the estate, the reason a refresh is on the table, and the risk of carrying old decisions forward.
Servers, storage, virtualisation, workloads, backup, recovery, network dependencies, licensing and support responsibilities, reviewed before any path is set.
Hardware lifecycle, VMware position, workload placement, recovery confidence and operating model are connected but should not be collapsed into one rushed call.
Like-for-like, modern local infrastructure, HCI, VMware transition, selective Azure migration or a staged hybrid model, with the reasoning, not just the recommendation.
Sequenced around dependencies, business impact and rollback. Where possible new infrastructure runs in parallel so workloads move and are validated with control.
Monitoring, patching, backup verification, documentation and lifecycle planning. The refresh is not finished until the environment is supportable.
Infrastructure modernisation in practice
Four platform decisions, reached four different ways: a VMware exit under renewal pressure, staged estate modernisation, private cloud, and a controlled data-centre migration.
This looks like a replacement project from the outside. It is an architecture and recovery decision.
The value is not in supplying hardware. It is in getting the platform direction right and being able to deliver it.
01Engineering-led, not quote-led
The decision starts with the estate and its risks, not a bill of materials. We will tell you when the environment should stay simpler rather than become a transformation, which is the opposite of how a vendor selling a platform behaves.
02Assessment, design, migration and support stay connected
The people operating the environment understand the reasoning behind the architecture, because the same team assessed it, designed it and delivered it. The decision does not get lost in a handover between vendors.
03Recovery is part of the decision
Recovery, backup, monitoring and lifecycle planning are treated as part of the decision, not post-project clean-up, because they determine whether the refreshed environment is supportable on a bad day.
04The outcome is a platform that holds under pressure
Ageing risk is removed rather than rehosted. Resilience is designed across compute, storage, network, power, backup and recovery, so a single failed component is not a business outage, and the day-to-day gets quieter.
Questions that come up before an infrastructure refresh.
Should we just replace the hardware like-for-like?
Sometimes that is exactly right. If the architecture still fits, the workloads belong where they are, and recovery is sound, a clean replacement done well, with better monitoring, validated backup and lifecycle control, is the sensible answer. The point is to make that call deliberately, not by default, because like-for-like quietly locks in the same weaknesses for another term.
What are the options if we exit VMware?
It depends on the estate. Staying on VMware temporarily, moving to Azure Local or Nutanix, using Azure VMware Solution as a bridge, considering Proxmox, or moving selected workloads straight to Azure are all valid. The exit is treated as a workload decision, not a licensing one, and it is decided workload by workload rather than platform-wide.
What is HCI, and when does it fit?
Hyper-converged infrastructure combines compute and storage into a simpler platform. Where the business still needs on-premises compute but the old three-tier model is past its useful life, Azure Local or Nutanix can provide local infrastructure with better resilience, simpler operations and clearer recovery than the legacy model. Azure Local suits Microsoft-aligned estates; Nutanix suits estates that want mature HCI and hardware flexibility.
Does everything need to stay local or move to cloud?
Neither by default. Local infrastructure is not automatically legacy: large design files, finance platforms and latency-sensitive workloads can make local compute the right answer. Some workloads are a better fit for Azure or SaaS, which shrinks the local footprint. The decision follows the workload, not a cloud-first or on-prem-first slogan.
How does recovery factor into a refresh?
Directly. Backup software completing is not recovery readiness. A refresh is the right moment to prove restore order, identity dependencies, immutable backup and rollback paths, because newer hardware will not fix an underlying resilience gap; it will just host it. Recovery is treated as part of the decision, not post-project clean-up.
How does this relate to cloud migration?
They meet at the refresh moment. If infrastructure spend is coming anyway, it is the right time to ask which workloads should move to Azure instead of being refreshed locally. Where a broader move to Azure and Microsoft 365 is the answer, the Managed Cloud and Migration pathway covers it.