Richard Lingsch | Enterprise Infrastructure Strategy.
How to assess workloads, compare options, control cost, reduce risk, improve portability, and move only what makes sense.
Nubius Solutions is an enterprise IT infrastructure migration partner providing Professional IT Infrastructure Services, Managed Cloud Services, and Cloud Hosting. This framework reflects knowledge gained by performing many infrastructure migrations of high uptime workloads, including migrating workloads from VMware to enterprise-grade alternative platforms.
Table of Contents
- The Reality: Why Infrastructure Decisions Are Getting Harder
- Platform Economics: Match Workloads to Infrastructure
- Standardization: When Scale Becomes Problematic
- Portability: Preserve Choice, Reduce Migration Risk
- Pre-Planning: Key Management Considerations
- Next Steps: Discovery
Infrastructure migration should not begin with a solution in mind.
The best outcome begins with an understanding of what the business needs from its infrastructure, what each workload requires, what it costs to provide, and what it costs in opportunity when a workload doesn’t fit the infrastructure it’s running on.
That sounds straightforward. The environment facing IT leaders today is anything but.
The Reality: Why Infrastructure Decisions Are Getting Harder
Infrastructure decisions are being made under pressure from several directions at once.
VMware Licensing and Ecosystem Disruption: Broadcom fundamentally changed VMware pricing and the broader commercial model. Perpetual licensing gave way to a subscription model, the portfolio was consolidated, many standalone products became unavailable, and the partner and support ecosystem was restructured. Organizations with support services for perpetual licenses approaching end of life have no choice but to revisit VMware costs, upgrade paths, new deployments, and long-term platform strategy.
More Infrastructure Choices: Public cloud, private cloud, on-premises infrastructure, hybrid models, and alternative virtualization platforms all have a place. They also come with different cost, performance, control, and operational tradeoffs. The harder question is no longer simply where infrastructure should run, but which environment makes sense for each workload.
AI Is Reshaping IT Priorities: AI is changing both business operations and IT strategy while consuming growing portions of technology budgets. Much of that demand ultimately lands on infrastructure through compute, storage, networking, and specialized hardware. AI is also changing how much gets built in the first place—faster development cycles mean more applications and systems arrive for infrastructure to support, independent of whether the organization runs AI workloads itself. As those costs rise, IT leaders have to make harder choices about which existing platform expenses still justify themselves.
Cybersecurity Consumes Budget and Attention: Security is one area IT leaders cannot afford to neglect. AI tools can strengthen the defensive posture, but they do not replace experienced judgment about risk, architecture, and response. Cybersecurity also consumes significant budget and senior-management attention. An infrastructure platform can remain inefficient for years without creating a crisis; a major security breach can become one overnight.
Four pressures, pulling in different directions at once. The natural response is to move fast—cut costs, switch platforms, postpone projects, pursue what appears to be the obvious solution.
But infrastructure decisions made under pressure can easily create another problem somewhere else.
Infrastructure still has to improve steadily to support future requirements. Deferring the work may relieve pressure today, but it often creates a larger and more expensive problem later.
The best place to regain clarity is with workload economics: what each workload actually requires, what it costs to run, and which platform best fits those requirements.
Platform Economics: Match Workloads to Infrastructure
When the decision environment gets crowded, attention is often directed to the platform itself. Discussion often focuses on whether to renew the current platform’s licenses or adopt another virtualization platform, move to public cloud or build more private infrastructure. Those are important strategic questions, but often the attention placed on big picture questions can delay the important goal of managing infrastructure costs.
To move faster on the path to addressing escalating infrastructure costs, a good starting point is to examine the workloads themselves and determine what they truly cost. Gaining a full understanding of cost is more than tabulating the ongoing license fees. The workload’s share of compute, storage, networking, backup/DR, data-center costs, supporting software and tools, and the people required to operate and maintain the environment must be taken into account. An often overlooked factor is the cost of unused and reserved capacity.
Getting a handle on the true cost of a workload is the only way to assess whether the workload is an economic fit for the platform it is running on. It uncovers the opportunity cost of that workload and answers the important question of what is being given up by not running the workload on a lower cost alternative. Or as the CFO would say, we can better spend that money on AI and cybersecurity.
Operational risk, dependencies, performance, staffing, and migration complexity still matter. But uncovering the opportunity cost, i.e. what are we giving up by keeping a workload where it is, should be a major factor in prioritizing what work must be performed to control infrastructure costs.
The goal is not to find workloads that can be easily moved.
It is to find where workload requirements and platform economics are most out of alignment. This is where the biggest cost saving opportunities live.
The workload that looks easiest to migrate isn’t always the one creating the greatest economic pressure — Dev/test may be a logical early candidate, but the larger opportunity may be sitting somewhere else in the estate.
A lower-risk dev/test environment may be an obvious migration candidate, but it may not be the biggest opportunity. Another part of the estate may be consuming far more licensing, capacity, or engineering effort than its requirements justify, and that excess cost is money and time no longer available for security, AI, resilience, or modernization elsewhere. Workload economics does not override operational risk, dependencies, or migration effort; it simply helps leadership decide where to look first.
Start With the Workload
A useful sequence is:
- Understand the workload. Requirements, dependencies, performance, data, business criticality, and operational expectations.
- Evaluate platform economics. Consider platform cost, infrastructure, operations, cost of change, and opportunity cost.
- Identify the biggest mismatch or opportunity. Find where the gap between requirements and platform economics is widest.
- Account for constraints. Storage, dependencies, migration risk, people, timing, compliance, and other practical limitations.
Economic priority and migration order are not necessarily the same thing.
Then choose the right combination of workload disposition, deployment model, and platform.
That ordering matters. It keeps the platform decision from driving the analysis before the problem is understood.
Evaluate Workload Fit
Every workload does not deserve the same infrastructure. Treating them as if they do is how the mismatch happens in the first place. The easiest workload to move is not always the most valuable one to move.
| Workload type | What matters most | Key question |
|---|---|---|
| Mission-Critical Production | Availability, recovery, storage performance, integration, SLA requirements | Does moving this workload create business or operational risk that outweighs the benefit? |
| Dev / Test / QA / Staging | Cost, capacity, provisioning, operational simplicity | Are we paying premium infrastructure economics where they are not required? |
| Steady-State / Legacy | Predictable demand, remaining life, migration effort | Which environment provides the best long-term economics for this workload? |
| AI & Analytics | Compute, storage throughput, network latency, data location | Where can the workload run efficiently while remaining close enough to its data? |
| Regulated & Data-Heavy | Compliance, storage, recovery, data sovereignty | Which storage, compliance, and recovery constraints limit the viable options? |
For mission-critical production, the real question isn’t whether it’s expensive to run — it’s whether the expense is buying capabilities actually being used.
Steady-state and legacy workloads often become expensive almost by accident, simply because moving them has never felt urgent.
AI and analytics workloads tend to default to whatever platform already runs the VMs — but GPU-aware infrastructure and secure multi-tenant isolation for shared GPU resources are distinct requirements that deserve their own evaluation, not an inherited decision.
For regulated and data-heavy workloads, the least expensive platform on paper is not always the least expensive one in practice, once compliance, sovereignty, and data-movement costs must be considered.
Build the Economic Case
As mentioned previously, a review of platform economics for a workload extends beyond the software invoice.
This effort should take into account all costs: licensing, subscriptions, and support; the compute, network, and storage footprint required to run it. It should also include the cost of capacity for reserve and growth, and systems for backup and recovery, and the engineering time spent patching, monitoring, and troubleshooting it. Workloads are upgraded over time and usually require infrastructure and staffing resources for development and testing. Other costs may be relevant depending on the particular situation.
Compare Realistic Destinations
Once workload economics are understood, the platform discussion becomes more useful. It comes down to three related decisions: what happens to the workload itself, where it runs, and what it runs on.
Some workloads should be retained, retired, or replaced rather than migrated at all. For workloads going forward, placement decisions on public cloud, private infrastructure, or hybrid architectures depend on elasticity, data location, and control requirements. This is usually part of the ongoing architectural process.
Platform choice is where the real opportunity lives. The current platform may continue to be the right answer where capabilities, risk, and economics justify it. But for workloads running on VMware that decision is no longer automatic. VMware licensing is not necessarily the largest cost of every workload, but under Broadcom it can now be large enough to become the deciding factor in workload placement.
For this reason many Broadcom customers have successfully migrated workloads to OpenNebula, Nutanix, Proxmox, and other platform alternatives. Nubius is a certified OpenNebula partner, and it’s the platform we have the deepest operational depth in. That’s a real credential. But we recognize that the platform decision still has to follow the workload’s requirements, and are agnostic about determining the best destination for a workload.
An easy 3 year VMware vs Alternative Cost Comparison: If VMware licensing and policy changes are driving your cost/benefit analysis of where a workload should reside, a licensing cost comparison is a helpful exercise. Nubius Solutions provides a VMware Cost Calculator that compares VMware licensing costs over a three year period to OpenNebula, an enterprise-grade alternative. The tool handles multiple scenarios – VMware vSphere and Cloud Foundation environments, legacy VMware environments, and new workload deployments. The result sheds light on the opportunity cost of running a workload that does not fit the infrastructure it is running on.
Standardization: When Scale Becomes Problematic
One thing that challenges IT leaders is the goal of standardization on an infrastructure platform. Standardization has real value. Data center consolidation done well can simplify skills, tooling, support, procurement, and operations. At scale, the benefits are substantial.
But concentration creates risk. When most of the infrastructure estate depends on one vendor, the organization also becomes dependent on that vendor’s pricing, licensing model, product direction, support structure, and future business decisions.
At some point, dependence on a single vendor outweighs the hard-won benefits of standardization. Considering another platform vendor does not mean abandoning standardization. What it does mean is deciding where standardization produces value and where concentration has become an unnecessary dependency. A two-tier infrastructure model is a strategy, not a concession.
This case is not an easy one to make internally. Operational teams have real reasons to resist a second platform. After all, they have been part of the efforts to achieve standardization and recognize that environment stability, familiar tooling, and hard-earned certifications all have genuine value. Reasonable people will defend these goals and accomplishments. The distinction that matters, however, is between operational consistency, which is worth protecting, and strategic rigidity, which is not. An IT leader introducing a two-tier strategy should expect resistance and be prepared to make the important call that a premium infrastructure platform is not the best fit for all workloads. The distinction should be made explicitly, and the pushback should be dealt with firmly and with conviction.
The truth is that introducing a second platform doesn’t require rebuilding the IT organization. Many of the skills required to run modern infrastructure — Linux, networking, storage, monitoring, backup, automation, Kubernetes, virtualization — apply across more than one platform. A second platform does not displace the existing IT organization.
Done well, a two-tier approach provides:
More Choice: credible alternatives are there when conditions change.
Better Economics: platform cost matches what each workload actually requires.
Less Concentration Risk: no dependency on a single vendor for everything.
Greater Resilience: the organization already knows how to operate another viable platform.
Lower Costs: vendor leverage improves once there’s a real alternative on the table.
Portability: Preserve Choice, Reduce Migration Risk
At this point it makes sense to talk about portability. If we had a clean slate, choosing the right platform today would only be part of the job. The design of the architecture should take into account how difficult the next change will be.
Portability is not simply whether a workload can run somewhere else. It is how much surrounding architecture must change before it can.
In economic terms, portability is lost once the cost of changing platforms exceeds the cost of staying. The same cost of change weighed earlier in the economic case is what determines how much choice has actually been preserved.
A virtual machine may technically run on another hypervisor while remaining deeply dependent on proprietary storage, networking, identity, security, backup, automation, or management services. Containerization does not automatically solve the problem. Kubernetes can improve application portability, but storage classes, networking, load balancing, identity, security, automation, databases, and provider-specific services can still bind a Kubernetes environment closely to one platform.
Existing Workloads: Improve Portability Over Time
Some workloads have a high migration-risk profile today because they’ve accumulated years of dependencies. That doesn’t mean they have to stay that way.
Identify the dependencies creating migration complexity and reduce them deliberately as part of normal infrastructure improvement. By replacing a proprietary storage dependency, removing hardcoded network assumptions, standardizing identity, backup, monitoring, or automation choice increases and migration risk decreases. None of this requires an immediate migration but enables an easier future migration.
Over time, a workload that’s expensive and risky to migrate can become much more practical to move.
New Workloads: Avoid Creating the Problem
For new workloads, the opportunity is better. Use open standards and common interfaces where practical, and avoid unnecessary dependencies on proprietary services when the benefit doesn’t justify the future switching cost.
The goal is not to avoid vendors — it’s to avoid unnecessary dependencies that make the next infrastructure decision harder than it needs to be.
Pre-Planning: Key Management Considerations
Once a migration opportunity appears economically worthwhile, the CTO’s role shifts from deciding whether the opportunity deserves attention to establishing the conditions under which the work can proceed responsibly.
The technical details belong in the migration plan. Leadership has a different job: make sure the organization has the capacity, accountability, stakeholder confidence, operating discipline, and success criteria required before the project begins.
Account for the People
Before committing to a migration, assess the capacity of the internal team. The people most qualified to evaluate the environment, make architecture decisions, and guide the work are usually the same people already keeping the infrastructure running. A migration project often adds pressure before it adds value.
Leadership has three basic choices:
- Defer other work: Redirect experienced staff from another priority.
- Add staff: Bring in additional internal capability.
- Bring in outside help: Add experienced engineering capacity from outside the organization.
The third option looks the most practical, but only works if the partner actually reduces the burden on the internal team rather than adding to it.
That means judging more than technical competence. It means whether the partner will earn the team’s trust, how fast they can get up to speed, and whether they’ll actually listen when the internal team flags a real risk instead of overriding it. The strongest outside teams understand the environment, bring a clear plan, explain it, adjust when something important surfaces, and carry enough of the execution that the organization actually gains capacity.
Outside help should create capacity — not become another problem to manage.
Clarify Ownership and Decision Rights
A migration crosses architecture, operations, applications, infrastructure, and often outside partners. Before the project begins, the CTO should make sure responsibility is clear.
Who owns the migration decision? Who has authority to stop a cutover? Who decides whether results are acceptable? Where does responsibility sit between the internal team and outside engineers? Who owns the target environment after the move?
These questions do not need a complicated governance structure, but they do need explicit answers.
Ambiguity is manageable when everything is going well. It becomes expensive when the project reaches a difficult decision.
Build Confidence in the Plan
A sound plan can still be stopped if the people with authority to stop it don’t understand or trust it.
Before the project begins — and continuously through it, not as a single pre-cutover briefing — walk sponsors and stakeholders through the plan, the validation approach, and the execution playbook.
The consequences of getting this wrong aren’t political. A migration halted at the last minute for lack of confidence carries the same cost as one that fails technically.
Protect Operations During the Change
Infrastructure improvement cannot come at the expense of keeping the business running.
The pace of the migration should reflect the organization’s operational risk tolerance, the maturity of the target environment, and the capacity of the people involved.
Business-critical systems should not become test cases for an unproven operating model. Confidence should be built deliberately, and the team should be prepared to stop when results differ from expectations.
The CTO does not need to prescribe every migration step. The responsibility is to make sure the work is structured so that normal operations remain protected while the environment changes.
Set the Performance Standard
Last but not least, establish the performance standard before the migration begins.
Performance must be the lead acceptance standard, and it has to be treated as non-negotiable. Performance is objective. It can be measured, tested, and proven before and after cutover. Everything about a migration can go right. The plan can be executed perfectly, the cutover can meet the target, the validation can be exact, and the operational handoff can be smooth, yet the project can still be judged a failure if the workload is measurably slower than what it replaced.
Security, monitoring and visibility, and user experience all have to meet expectations. The organization will notice if any of them regress. But the people using the workload render their own verdict, and it isn’t a nuanced one: does it feel fast, or does it feel slow. Fast earns a thumbs up. Slow earns a thumbs down, and overrides everything that went right elsewhere.
One final thought on planning: Pre-planning is the precursor to planning. Once a workload is selected for migration the work begins. At this point it is important to raise the cost of overplanning. At some point the plan has to close and the migration has to begin. Overplanning carries its own cost — missed windows, burned budget, exhausted teams — and it is as much of a risk to the project as moving too fast.
For a deeper look at the technical planning and execution that follow these management decisions, see our VMware to OpenNebula Migration: What Matters When Moving Production Workloads.
Next Steps: Discovery
You do not need a finished migration plan to begin evaluating whether a migration opportunity is worth pursuing. Start with discovery.
Use the workload-economics principles from this article to identify a workload, group of workloads, or part of the estate where requirements and platform economics appear to be out of balance. Then gather enough information to answer the practical questions:
What does the workload require, and what does it depend on?
What does it cost today, and what makes it difficult to move?
What realistic alternatives exist, and what would have to be true for a migration to make sense?
What are the opportunity cost savings?
The purpose of discovery is not to prove that a migration should happen. It is to replace assumptions with enough information to make the next decision.
Right-Size the Assessment to the Decision
For a major platform transformation, a comprehensive infrastructure migration assessment may be appropriate — current-state inventory, dependency and storage analysis, workload classification, multi-year TCO modeling, platform comparison, performance requirements, risk analysis, staffing constraints, sequencing, and a detailed execution plan. Some vendors that specialize in VMware migrations will perform a complete assessment at no charge, in exchange for a commitment of a high percentage of savings achieved.
But that level of effort isn’t always what the moment calls for. A focused assessment of one representative workload and its storage can answer the same questions above at a smaller scale — enough to decide whether to proceed, stop, or investigate further.
Assess Without Impacting Operations
The same personnel constraint remains during discovery. The people with the best knowledge of the infrastructure are usually the people with the least available time.
Outside expertise can help, but competence alone is not enough. The partner needs to ask informed questions, understand the environment before prescribing an answer, listen when the internal staff identifies a real risk, and carry enough of the work that the internal organization actually gains capacity. Then execution has to justify that trust.
A good partner can help with discovery without impacting operations.
A Practical Starting Point
For qualified organizations evaluating VMware migration options, Nubius Solutions offers a complimentary engineer-led Migration Assessment. Nubius will perform a focused review of one representative workload and its storage.
The objective is straightforward: determine the technical parameters of migrating the workload, the level of effort required, and what the risk factors are. Included is a cost review, highlighting estimated savings by migrating to an enterprise-grade alternative, such as OpenNebula. The assessment will uncover whether it makes sense to take the analysis to the next level. If so, deeper discovery and planning can follow into a full migration plan. If not, knowing where a workload stands has value too.
Request a Complimentary Migration Assessment
On that page, click Let’s Talk About Your Project and enter Complimentary Migration Assessment in the Subject field.