Strategix · Nutanix .NEXT Johannesburg

The shape of it, in two minutes

Eleven questions, most of them a tap. A range, not a quote - and the things nobody tells you until you are already committed.

Question 1

What are you running today?

Everything that follows adapts to this answer. If you run more than one platform, choose the one carrying most of the workload. XenServer, XCP-ng, OLVM, OpenShift Virtualization and anything else are covered by Something else, or mixed.

Question 2

Roughly how many VMs would move to the new platform?

Not everything you run - the machines you would actually migrate. A ballpark is fine. It sets the floor for everything else.

Question 3

Total memory allocated to the VMs moving

Allocated, not used. That difference is bigger than most people expect - we will show you why.

GB

Assumed at 14.6 GB each - our own cluster's average, not a typical machine. Change it if you know yours.

Your own figure - we will not overwrite it.

Question 4

Total virtual CPUs allocated

Again allocated, not used - across all the VMs moving.

vCPU

Assumed at 4.3 each, same cluster. Change it if you know yours.

Your own figure - we will not overwrite it.

Question 5

Storage actually in use

What the VMs consume, not what the array holds.

TB

Assumed at 0.56 TB each, same cluster. Change it if you know yours.

Your own figure - we will not overwrite it.

Question 6

When does your current agreement end?

This changes the advice more than any technical answer.

The environment round

Five questions about what surrounds your machines

The machines themselves migrate. These are the things that get rebuilt, re-licensed or replaced - and this is where the work and the cost actually sit.

Question 7

-

Question 8

-

Question 9

What backs it up?

Question 10

What do you monitor with?

Question 11

Any of these in the estate?

Tap all that apply. These need handling separately, and it is better to know now.

An indicative shape - not a sizing

Modelled on our own migration off VMware, not on an industry average.

What is driving it

-

-

Everything below is how we got there - open whichever sections you would like more detail on.

Processor - the one we will not pretend to size

-

-

The thing nobody mentions

The target platform does not overcommit memory by default

-

-

One worked alternative

If you right-sized first

-

What you would be licensed on

-

-

Raw is not usable

-

-

Your rebuild list

Things that do not move across

For each one: what does the job on the new platform, what the move actually involves, and what changes once you are living with it.

The management plane

-

-

What we have NOT counted

Things that will add to this, and we would rather say so

  • A separate management cluster. Once you are running more than one tenant, or at any real scale, leading practice puts the management plane on its own cluster with its own resilience floor. That is nodes on top of the number above, and whether you need one is a design decision rather than a calculation.
  • Backup infrastructure. The new platform has no equivalent of the transport your current product uses, so it deploys worker machines onto the cluster itself - which consume the cores you are licensed for.
  • The migration tooling. A small appliance, and only for the duration, but it has to live somewhere while it runs.
  • The controller's own footprint on disk. We have deducted its memory and accounted for its processor, but its system and metadata space on the drives is inside our working headroom rather than counted separately.
  • Anything you stand up new - file services, database services, monitoring you have to replace, a test cluster.

What we could not see

Being straight with you

-

If you do one thing

-

-

Your reference -

This is a shape, not a sizing. Eleven answers and a set of stated assumptions. A real number needs measured data from your own estate - and a sizing done badly is worse than none, because a wrong number still gets budgeted from and committed to.

What we assumed. Two copies of your data, and a node held back so the cluster can rebuild itself. Eight percent working headroom, and a twenty percent buffer on storage. No data-reduction savings claimed at all. A four-node floor, 64 GB of controller memory on every node, and the management plane counted in.

Where we estimated, we said so. Any figure you did not enter yourself is calculated from your machine count using averages from our own production cluster, and the question says so in red. What we could not see at all is named on your result.