The moment a virtualisation estate reaches the end of its cycle rarely coincides with a failure. Machines run, services respond, the system administrator reports nothing urgent. What changes is the context. Servers are seven or eight years old and hypervisor licensing terms shifted after the vendor’s last corporate transaction. The renewal quotation arrives in a different order of magnitude from the previous year. That is the point at which migrating to Nutanix enters the list of options worth assessing.
The trouble is that an assessment of migrating to Nutanix almost always opens on the wrong question. People ask what it costs, while the variable governing everything else is sizing. How many nodes are needed, which data the calculation rests on, and what happens to the existing estate while the transition runs.
When migrating to Nutanix, three nodes is the threshold for hot expansion
Three nodes is the minimum configuration that delivers every function. With two nodes the platform works but some capabilities fall away; with a single node the architectural advantages that justify the choice disappear. So far the figure is well known and repeated in every presentation.
The operational reason matters far more and is quoted far less. From three nodes upwards a node is added or removed hot, with no service interruption and no performance penalty. Below that threshold the cluster cannot expand: it is born with the size it has and dies with it. Adding capacity means emptying it, wiping it, rebuilding it and loading the data back in. In that case the outage is certain.
A second element shapes any plan for migrating to Nutanix: data protection. With the minimum redundancy factor every block is written twice, on nodes that are always separate. Losing a node therefore does not mean losing data. Raw disk capacity is therefore never usable capacity. On top of the redundancy factor sits the controller virtual machine present on each node. Headroom must also be reserved to keep the cluster running with one node missing, whether through failure or through maintenance.
A per virtual machine licence also exists, recommended below fifteen or twenty machines and independent of the number of nodes underneath. Functionality does not change; the counting metric does. Denser environments are licensed on physical cores, which explains why processor frequency matters more than core count when hardware is chosen.
Consumed and provisioned: the figure that doubles the configuration
This is the most frequent mistake and the most expensive. Collection tools read two different values for every virtual machine: what has been assigned to it and what it actually consumes. Sizing on the first buys resources that will sit idle. Sizing on the second leaves margins so thin that one simultaneous peak is enough to run short.
On a real environment of seventy eight virtual machines the gap between the two scenarios was worth double the configuration. Consumed case: three single socket nodes, sixteen cores each. Provisioned case: three dual socket nodes, ninety six cores in total, with memory and storage requirements more than doubled. Both configurations described the same company, and the second meant buying a higher class of machine for workloads that did not exist.
Two further values deserve scepticism. Memory reported by the collector is the amount allocated by the hypervisor, not the amount genuinely in use. In one case the contact believed consumption was modest while the tool indicated more than a terabyte. That discrepancy only clears up by watching the trend across several months. Disk space, in turn, counts external units attached to the environment as datastores, and those will not exist in the new estate.
Third comes the ratio between virtual and physical cores. Collection tools apply different ratios machine by machine according to observed consumption. On lightly loaded environments the average can fall well below the figure considered normal. Forcing a single ratio and rerunning the simulation is the quickest way to see how much headroom really exists.
Data to collect before quoting a migration to Nutanix
- A complete inventory export, preferably through the collection tool that records a week of activity: a single snapshot misses the overnight peaks of batch jobs and backups.
- The list of powered off machines, with an explicit decision on which to import and whose occupied space to carry over.
- The list of workloads not to be migrated: hypervisor service machines, test environments, systems already marked for retirement.
- Over provisioned machines, meaning those with resources far above real weekly use: that is the first list to work on.
- Whether source storage is local or on a dedicated network, because the sizing must then replace the controllers of the external array too.
- The hardware homogeneity constraint: nodes must come from the same manufacturer with matched specifications, and different processor families limit live migration between clusters.
What keeps running while migrating to Nutanix
The question that blocks most projects concerns service interruption, and it is also the point where the misunderstanding runs deepest in the projects we follow. Migrating to Nutanix from a VMware environment does not require a downtime window proportional to the size of the estate, because copying happens while everything is in production.
The migration tool builds a replica from the source environment towards the new cluster and refreshes the delta every few minutes. Meanwhile the original machine keeps working. When the administrator judges the moment right, the source machine is powered off and the remaining delta is copied. The machine then starts on the new cluster, so disruption is confined to that step. The source machine stays available with a note recording the migration, so rolling back is possible until it is decommissioned. Licences for the previous hypervisor must be kept until the final cutover, and that overlap belongs in the plan alongside the renewal date.
Before the definitive switch a machine can be started in the new environment on an isolated network and verified, which keeps the migration reversible right up to the cutover. Resources can be changed during the move, networks remapped and the previous hypervisor agents removed. Anyone preferring a gradual path can keep the VMware hypervisor above Nutanix storage and convert later with a rolling restart node by node. Compatibility with the previous hypervisor is maintained in steady state too, which is why coexistence need not be rushed. Readers still weighing whether rather than how will find the preliminary criteria in our analysis of the cost of business software customisations. The same principle applies there: the bill for a shortcut arrives at the first upgrade.
Migrating to Nutanix from an estate at end of cycle: two scenarios
A company running three physical nodes from two different manufacturers, a VMware hypervisor and seventy eight virtual machines opened its assessment with a simple request. Replace hardware that had reached end of cycle, and close the licensing chapter. Installed memory exceeded a terabyte in total, available storage mixed spinning and solid state disks, and around half the space was occupied.
In this case, migrating to Nutanix hit its first knot at the simulation stage. Sized on consumption the configuration stayed contained; sized on provisioning it doubled, along with the class of machines to buy. Neither number was wrong: they described two different readings of the same environment.
Detail on individual machines clarified the picture. Many carried a single virtual processing unit, the CPU was lightly loaded. The ratio between virtual and physical cores sat at half the figure considered normal. The environment was not compressed; it had been over specified from the start.
How the configuration was settled
On that finding the final configuration was built. The single socket series with sixteen cores stayed, leaving untouched the metric on which licences are counted. Everything else grew: memory raised to half a terabyte per node, disks of double the size originally proposed, an additional network card, a higher frequency processor at the same core count. Margin logic drove one further decision: a model suggested by the configurator was discarded because it carried only one solid state disk, and therefore a single point of failure.
The hardware market then decided the timing. Memory and disk prices were volatile and delivery times ran comfortably beyond three months. The company chose to start on the measured configuration and add a node later if needed. Over specifying would have meant paying anomalous prices for capacity destined to sit idle. The whole point of the architecture is that a node can be added without stopping anything.
Insight. Migrating to Nutanix rests on three numbers rather than one. Real consumption measured across a week, the headroom required to run with one node missing, and the growth rate the company expects. With those three in hand, a supplier comparison stops being a comparison of price lists.
What changes according to node count
| Configuration | What remains available | The limit to know beforehand |
|---|---|---|
| Single node | Full platform management, per virtual machine licensing | No copy of the data on a second node and no hot expansion |
| Two nodes | Data redundancy across the two nodes | Some functions unavailable, and growing means a rebuild with downtime |
| Three nodes or more | High availability, hot add and remove, replication to a second site | Headroom must be reserved to run with one node missing, for failure or upgrade |
After migrating to Nutanix, the replication node powers on only when needed
For anyone migrating to Nutanix, replication to a second site is included in the main licence tier. That changes the economics of disaster recovery compared with the previous architecture. Multiple destinations can be configured with different recovery point objectives: a nearby site in synchronous mode, a remote one in asynchronous. Hosting can sit either in the company data centre or at a service provider.
With the entry licence the minimum interval between two replications is one hour. Higher tiers move into the region of fifteen minutes and, at the top tier, to synchronous replication. Under a managed service model licences apply monthly, which allows a remote node to be powered on only when required rather than fed all year round.
One clarification helps whoever does the sizing: replicating every machine is not mandatory. Pick the subset that has to come back first and assign it a reduced resource profile. Deciding who answers for the data and who for the infrastructure matters as soon as a cluster goes to a managed provider. Our piece on protecting corporate documents sets out those criteria.
Questions that recur in infrastructure assessments
Is hardware from the platform vendor mandatory?
No. The compatibility list includes Nutanix branded machines and dedicated families from Dell, Lenovo and HPE, alongside general purpose servers that can be verified component by component. Verification must happen before the order, covering controllers, boot devices, disks, power supplies, processors and network cards. If too many parts need replacing, buying new machines becomes the cleaner route. The vendor publishes its supported hardware platforms openly, with a restricted portal holding the compatibility matrices and upgrade paths.
Can the existing backup infrastructure be reused?
Yes. Veeam is fully supported on the native hypervisor, installed on a virtual machine or through a preconfigured appliance that connects directly to the hypervisor and centralises copies. The specific licence is required, equivalent to the one already in use under VMware. Protection domains offered by the platform can be layered on top, defining what to replicate, where and how often. Anyone wanting a copy that cannot be deleted can add immutable storage exposing a compatible object store.
Is migrating to Nutanix compatible with business critical software?
Verification belongs with the application vendor, because some certifications are written against a specific hypervisor rather than against the architecture. Close that check at the start of the assessment. In our experience it is the clause that most often forces a change of scope, since a certified dedicated server can stay outside the migration without compromising the rest of the project. More than eighteen hundred third party solutions are validated on the native hypervisor for data protection, networking and security.
Who handles node updates and maintenance after the move?
The platform coordinates system, application and security updates on its own. It places a node into maintenance, shifts workloads onto the others and returns it to service when finished. A reboot is needed only when the update touches the hypervisor. On a correctly sized three node cluster the operation runs with production workloads in place. During that window, though, the cluster temporarily has no headroom for a further failure.
Can the estate extend towards a public cloud?
Yes, and the licence is portable. The same one can sit in the company data centre, at a service provider or on a public cloud, moving as the project evolves. The only material constraint is that hyperscalers do not accept a single node, so a full cluster is required. Worth remembering that instantiating a cluster in the cloud takes under an hour, while commissioning a physical site involves procurement measured in months.
Let’s talk
Migrating to Nutanix is assessed properly only when the comparison runs between measured configurations rather than between quotations built on different assumptions.
The work that creates value comes before the quotation. Collect a week of real data, clear the inventory of machines that will not be migrated, decide deliberately whether to size on consumption or on allocation. Then write down what headroom the company wants on the day a node fails. Aesir Srl is a Nutanix Professional Partner and operates its own Tier IV data centres in the European Union with replication. It works as an MSP and MSSP under the same contractual perimeter, holding ISO 9001, 27001, 27017 and 27018 certifications and voluntary alignment with NIS2. If you would like to explore the subject or assess the situation in your own company, you can fill in the form at the bottom of this page or write to support@aesir-tech.it: we will arrange a free consultation and start from your numbers.