Virtualisation platforms have an impressive ability to become permanent.
Once the installation is complete and the workloads have been migrated, the platform settles into everyday life. New virtual machines are added, storage expands and applications acquire dependencies nobody anticipated when the original architecture diagram was drawn. Provided everything continues working, there’s generally not much enthusiasm for revisiting the decision.
That’s understandable. Replacing a functioning infrastructure platform isn’t always necessary, however new and attractive the alternative may be.
Even so, it’s worth asking occasionally whether the reasons for choosing the platform still apply. The organisation, its workloads and the market around it may have changed considerably while the hypervisor was quietly getting on with its job.
Revisit the Assumptions, Not the History
A platform is always chosen within a particular set of circumstances. Perhaps you were consolidating physical servers, opening a data centre, standardising several inherited environments or trying to support rapid growth. At the time you had a known set of workloads, an available skills base and commercial agreements that make one option more attractive than another.
Five or ten years later, the original decision may still be entirely defensible, but the assumptions behind it could have changed.
Applications may have moved into the cloud while others have returned to on-premises infrastructure. A merger might have introduced a second virtualisation platform. Recovery expectations may be more demanding because services once regarded as secondary are now critical to customers or internal operations. The people who designed the environment may have moved on, taking with them the explanation for some of its more imaginative features.
None of this means the platform is wrong. But it does mean that “we chose it years ago” isn’t sufficient evidence that it’s still a good fit.
A useful review begins by reconstructing the original assumptions and comparing them with the organisation as it exists today. Which workloads does the platform now support? How important are they? What skills are available? What do you expect in terms of availability, recovery and support? If the answers have changed, the strategy may need to change with them.
Don’t Let the Renewal Date Do the Planning
For many organisations, the first sign of a virtualisation review is a renewal quote. Somebody compares it with last year’s figure, circulates a spreadsheet and asks whether there’s an alternative.
Cost is a perfectly valid reason to examine the platform, but a renewal deadline is a poor architect.
Virtual environments contain interconnected workloads rather than conveniently independent boxes. Before moving them, someone needs to understand application dependencies, performance, storage, networking, backup, security and recovery requirements. The target environment must be designed and built, people need to learn how to operate it and migrations have to be tested without turning the production estate into an experiment.
If this work begins only when a renewal is approaching, you may discover that your options are either to migrate too quickly or renew because there isn’t enough time to do anything else.
Reviewing the platform earlier preserves the option to stay as well as the option to leave. It gives you time to understand what you has, investigate the alternatives and decide whether changing would produce a worthwhile outcome. If the conclusion is to renew, at least the decision belongs to you rather than the calendar.
What Are You Actually Paying For?
Licence costs tend to dominate platform comparisons because they’re visible and easy to place in a table. The rest of the operating cost is less visible.
There’s hardware, storage, backup, monitoring, administration, training, specialist support, security maintenance and upgrade work. A problematic platform also consumes internal time in ways that don’t appear on an invoice: manual processes, repeated troubleshooting, delayed maintenance and the occasional long evening spent rediscovering something that should have been documented.
This makes “Which platform is cheaper?” difficult to answer without first deciding what the platform needs to deliver.
Low software costs are attractive, but not if your organisation then lacks the people or support required to operate the environment confidently. Equally, an extensive feature set doesn’t represent good value merely because it exists. Paying for sophisticated capabilities that aren’t used is rather like buying a restaurant grade grill to make toast. The toast may be excellent, but the investment case deserves another look.
Start with the requirements. Which capabilities are essential? Which are useful? Which are included in the current platform but hardly noticed? Once those questions have been answered, licensing and subscription costs can be compared alongside the cost of running and supporting each realistic option.
The objective isn’t necessarily to find the lowest figure. It’s to understand what you receive in return.
Count Services, Not Just Virtual Machines
Most technical assessments begin with hosts, processors, cores, memory, storage and the number of virtual machines. All of these matter, but they say little about the consequences of moving or losing a workload.
A small virtual machine might provide a replaceable development service. Another of identical size could run a licence server on which several important applications depend. They consume similar resources while posing very different operational risks.
For each workload, we need to understand the business service it supports, its dependencies and its requirements for performance, availability and recovery. You also need to know who owns it and whether anyone still uses it.
That last question can produce unexpectedly good migration efficiencies. Moving a virtual machine that nobody needs may take several hours; deleting it takes considerably less time and requires no target-platform capacity.
Discovery also reveals the workloads that won’t move neatly. An application may depend on old operating systems, unusual hardware, fixed network arrangements or vendor support conditions. Some systems will need remediation before migration, while others may be better left where they are until they can be replaced.
The important output isn’t simply an inventory. It’s an understanding of what the next platform must support and where the real migration risks lie.
Notice When You’re Working Around the Platform
Technical fit changes gradually. Storage grows, network requirements become more complex, security expectations increase and automation becomes more important. An architecture designed for one scale may become problematic at another without ever experiencing a catastrophic failure.
The warning signs often appear in everyday operational behaviour. Upgrades are repeatedly deferred because nobody is confident about the result. Capacity is added in response to alerts rather than forecasts. Different clusters have drifted into inconsistent configurations. Backup windows overrun, workload movement needs manual intervention and monitoring produces plenty of information without making it obvious who should act.
These symptoms don’t automatically justify replacing the platform. Some indicate maintenance or management problems that should be fixed where they are. A migration won’t improve unclear ownership, incomplete documentation or poor capacity planning; those problems are remarkably portable.
A review should distinguish between limitations of the technology and weaknesses in the way it’s being operated. Otherwise, the organisation risks building a new platform that gradually develops the habits of the old one.
Can You Support It Properly?
Feature comparisons are useful, but they don’t tell you whether the organisation can run the platform at three o’clock on a Sunday morning when an important service has disappeared.
A suitable platform needs an appropriate operating model. Day-to-day administration, monitoring, patching, upgrades, capacity management, security, backup and recovery all require ownership. Specialist help must be available when internal knowledge runs out, and the escalation route needs to be understood before it’s required.
This applies equally to open-source and proprietary software. Open source doesn’t mean unsupported, while proprietary software doesn’t mean the vendor will manage the whole environment.
Product support and platform management aren’t the same thing. A vendor may investigate a defect in its software, but it won’t necessarily take responsibility for your storage architecture, network configuration, application dependencies or recovery procedures. Those responsibilities remain with your organisation or your chosen service provider.
When comparing platforms, consider where the necessary skills will come from and what happens when the people who know the environment aren’t available. A technically capable platform that can’t be maintained confidently is unlikely to become more suitable during an incident.
Has the Business Outgrown the Resilience Model?
Not every workload begins life as business critical. A system may start as an internal convenience, acquire more users and eventually become something the organisation can’t operate without. The infrastructure hasn’t necessarily changed; the risk factor has.
This is one of the better reasons to reconsider the virtualisation strategy, even when there’s no immediate technical problem.
Look at what the current design can actually tolerate. If a host fails, can the affected workloads restart elsewhere, and is there enough spare capacity for them to do so? What happens if shared storage or a network path fails? Are backups independent of the production environment? Have representative workloads been restored, and did the recovery take less time than the business was expecting?
It’s easy to accumulate confidence from dashboards, completed backup jobs and high-availability settings. Evidence comes from testing.
Replication, high availability and backups contribute to resilience in different ways. Replication can protect against hardware failure, but it can also reproduce damaged or deleted data very effectively. High availability may restart a virtual machine without restoring the complete service on which users depend. Backups only become useful when they can be restored by the people likely to need them.
If the recovery model hasn’t been reviewed since the workloads became critical, it may be supporting expectations it was never designed to meet.
How Difficult Would It Be to Change Direction?
Every platform creates dependencies. Administrators learn its tools, scripts are written against its interfaces and applications begin to use platform-specific capabilities. Over time, moving elsewhere becomes more difficult.
That isn’t necessarily a problem. An organisation can sensibly commit to a platform because it provides substantial value. Pretending that all technologies are interchangeable usually creates more complexity than freedom.
The risk lies in not knowing how dependent you’ve become.
Could the workloads be moved if commercial or technical circumstances changed? Is their configuration documented outside the platform? Do backups support recovery elsewhere? Which applications rely on specific features or hardware integrations? How long would assessment, design and migration realistically take?
You don’t need a continuously updated plan to leave every supplier. You do need enough understanding to recognise whether you have a choice. If the answer is that migration would take eighteen months, that’s useful strategic information. It means a review needs to begin well before a contract, hardware or support deadline makes the decision urgent.
Compare the Complete Options
An alternative platform may have lower software costs, greater flexibility or a technical model that better suits the organisation. The migration still carries cost and risk.
Applications need to be assessed. Compatibility and performance must be tested. Network, storage, security and backup arrangements may need redesigning. Administrators need new knowledge, and the first migration is unlikely to reveal every complication that will appear in the twentieth.
A sensible business case compares the cost and risk of remaining on the current platform with the cost and risk of moving to an alternative and operating it afterwards. Comparing a target platform’s software price with the current licence cost tells us very little.
The transition shouldn’t be treated as one indivisible event either. A representative set of lower-risk workloads can test the architecture, migration process and operating procedures. The next phase then benefits from what was learned, which is considerably more comfortable than collecting every lesson during a single weekend.
Some workloads may remain on the existing platform for longer. A mixed environment isn’t automatically a problem if it reflects deliberate decisions about risk and compatibility. It becomes a problem when it persists accidentally and nobody can remember which platform is meant to be temporary.
Staying Can Be a Positive Decision
A review may conclude that the current platform remains technically suitable, commercially acceptable and supportable. Perhaps the organisation needs better monitoring, clearer responsibilities or more disciplined recovery testing, but not a migration.
That’s a useful outcome. It replaces assumption with evidence and identifies the work required to keep the platform suitable.
Changing technology for the pleasure of having changed it consumes time, introduces risk and distracts technical teams from other work. There should be a clear improvement in resilience, cost, supportability or strategic flexibility to justify the effort.
Familiarity has value too. Existing skills, processes and automation shouldn’t be discarded casually. At the same time, “we know how to work around it” isn’t quite the same as “it meets our needs”. Organisations can become impressively efficient at accommodating limitations they no longer need to accept.
What Should a Review Produce?
A useful review should leave decision-makers with a clear view of:
- The business services and workloads in scope
- Current technical and operational risks
- Availability and recovery requirements
- The real cost of the existing environment
- Skills and support requirements
- Realistic platform options
- Migration complexity and dependencies
- The recommended next steps
It doesn’t need to become a hundred-page strategy document. A concise report that leads to decisions is generally more valuable than an impressive one that has defeated everyone by page 27.
Most importantly, the review should create time to act. A renewal, hardware failure, unsupported version or capacity crisis narrows the available choices and gives short-term pressures far too much influence. The organisation may decide to stay, improve the current environment or begin a controlled move to an alternative. Any of those can be the right answer.
What matters is that the platform remains in place because it still fits the organisation – not simply because it has been there for years and migrating to a better solution is too difficult.
Review Your Virtualisation Strategy
Tiger Computing helps organisations assess existing virtualisation environments, evaluate alternatives and plan controlled migrations around their workloads, risks and operational requirements.
Learn more about our Proxmox VE Services and book a discovery call to discuss whether your current virtualisation platform still provides the right fit for your organisation.
