> ## Content Index
> Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Platform Decision: How to Run the Evaluation Without a Recommended Answer
- URL: https://www.mohammadsiddiqui.com/the-platform-decision-how-to-run-the-evaluation-without-a-recommended-answer/
- Published: 2026-09-08T06:38:01.000Z
- Updated: 2026-09-08T06:38:01.000Z
- Description: Most material on this question is written by people who already know what they want you to choose. This is the method instead — requirements first, weighted before you see a demo.
- Author: Mohammad Siddiqui
- Tags: architecture, operations

Every infrastructure leader I speak to is being asked some version of the same question right now. Do we stay on our current virtualisation platform, and if not, what replaces it?

Most of the material available to answer that question is written by people who already know the answer they want you to reach. This is not that. It is the evaluation method I would run with a customer, with no recommended outcome attached, because the right answer genuinely differs by estate.

## The mistake almost everyone makes

The evaluation starts with a shortlist. Somebody has heard good things about a platform, somebody else has a relationship with a vendor, and within two weeks the exercise has become a comparison of three products rather than an examination of what the organisation actually needs.

Once you are comparing products, the vendor with the best demo wins. That is not a decision, it is a preference dressed as analysis, and it falls apart the first time somebody senior asks why.

The order that works

Requirements, weighted and agreed. Then options. Then evidence. Then cost, including the costs nobody quotes. Then the decision, written down with its reasoning.  
  
Skip a step and you will redo the exercise in eighteen months. 

## Step one: requirements, weighted before you look at anything

Write the requirements before the shortlist exists, and weight them before you know which option scores well. This is the single most important discipline in the whole exercise, because weighting after the fact is how people rationalise a decision they already made.

The categories that matter in most enterprise estates:

- **Workload fit.** What actually runs today, including the awkward things. Clustered applications, licence-bound databases, appliances with vendor support matrices, anything with a hardware dependency.
- **Operational model.** How your team works now, and how much change they can absorb while still running production.
- **Skills and market.** What your people know, and how hard the missing skills are to hire in your location.
- **Regulatory and compliance.** The frameworks you are actually subject to, and what evidence each option can produce.
- **Ecosystem and integration.** Backup, monitoring, security tooling, ITSM, automation. This is where migrations quietly fail.
- **Commercial.** Licensing model, term, exposure to change, and what happens at renewal.
- **Exit cost.** How hard it is to leave the thing you are about to adopt. Almost nobody scores this, and it is the one that bites in five years.

Weight them with the people who will live with the outcome, and record the weighting before the options are scored. If the infrastructure team weights operational model at 30% and the CFO weights commercial at 40%, that disagreement is worth surfacing in week one rather than at the steering committee.

## Step two: the option set, honestly drawn

A real option set includes doing nothing. If staying put is not on the list, the exercise is not an evaluation, it is a procurement.

The realistic categories for most enterprises:

Stay and optimise

Renegotiate, consolidate, extract more from what you own. Lowest disruption, and the option most often dismissed without analysis.

Alternative on-premises hypervisor platform

A like-for-like replacement. Familiar operating model, unfamiliar product. The migration is the cost.

Container-first platform

Running VMs alongside containers on a Kubernetes-based platform. Different operating model entirely, and the skills question dominates.

Public cloud, wholesale or partial

Includes the VMware-on-cloud services as a transition path. Watch the run-rate assumptions carefully.

Hybrid, by workload class

Different answers for different workloads. Usually the honest outcome, and usually the hardest to govern.

Score each against the weighted requirements. Where you cannot score something on evidence, mark it unknown rather than guessing. An honest gap is more useful than a confident invention, and the unknowns tell you what to test.

## Step three: the total cost, including the parts nobody quotes

Licence cost is the number that appears in the proposal and the smallest part of the real total. The components that get missed:

- **Migration labour.** Per-workload, not per-VM. A simple VM might be an hour. A clustered database with a vendor support matrix might be a fortnight and a change window.
- **Parallel running.** You pay for both platforms during transition. For a large estate that overlap is measured in quarters, and it is often the single largest line.
- **Retooling.** Backup, monitoring, automation, security tooling and ITSM integration all need rework. This is routinely underestimated by an order of magnitude.
- **Retraining and productivity loss.** Your team gets slower before it gets faster. Budget the dip.
- **Hardware.** Whether the new platform runs on what you own, and what the certification position actually is.
- **Risk cost.** The probability-weighted cost of the migration going badly. Rarely modelled, and the reason some evaluations should end in "not yet."
- **Exit cost of the new platform.** You are choosing your next lock-in. Price it.

Model it over five years, not three. Three-year models flatter migration because the disruption sits in year one and the savings arrive later. Five years shows whether the payback is real.

## Step four: test the two or three things that would change the answer

You cannot proof-of-concept everything and you should not try. Identify the specific unknowns that would flip the decision, and test only those.

In most estates that list is short. Does the awkward workload actually run. Does the backup product genuinely support it in the configuration you use, not in the datasheet. Can your team operate it under pressure rather than in a lab. What does the migration of one representative complex application actually take, measured rather than estimated.

That last one is worth doing properly. Migrate one genuinely difficult application end to end, time it, and multiply. The number will be larger than the estimate, and knowing the multiplier before you commit is worth more than any vendor benchmark.

## Step five: write the decision down, with its reasoning

Record what was decided, the weighting that produced it, the evidence behind each score, the assumptions the model rests on, and what would have to change for the decision to be revisited.

That last element is the one that separates a professional evaluation from an expensive opinion. Decisions age. If you write down the conditions under which this one should be re-examined, the next review starts from your reasoning rather than from scratch.

## What this looks like when it works

The strongest evaluations I have been part of shared three things.

**The requirements were agreed before anyone saw a demo.** Everything downstream stayed honest because of that one discipline.

**Doing nothing was scored seriously.** Sometimes it won. More often it lost on evidence rather than being dismissed, which meant the eventual decision could survive a hard question from the board.

**Somebody owned the number.** One person accountable for the cost model, with the assumptions written down and visible. Distributed cost modelling produces a number nobody believes and nobody defends.

## A note on who is telling you this

I have spent most of my career on one side of these conversations, and I have watched enough of these decisions play out over years to know that the platform is rarely what determines whether the outcome was good. The quality of the evaluation is.

Estates that ran a disciplined process and chose to stay have done well. Estates that ran a disciplined process and chose to move have done well. Estates that skipped the process and picked a product are the ones still arguing about it.

If you are running one of these exercises and want a second pair of eyes on the framework rather than the answer, my contact details are on the about page.

*Views expressed here are my own.*