// Migration Scenario
VMware exit: what happens to your databases, brokers and Tanzu components.
OSSeva delivers the data tier. Not the hypervisor.
A VMware exit plan has two halves. One is the platform your virtual machines land on. The other is everything running on top of it: databases, message brokers, caches and the Spring and Tanzu components, each with its own version and support contract. OSSeva delivers the second half only, moving or supporting RabbitMQ, GemFire, Spring and PostgreSQL on open source terms.
Trusted globally by enterprises
What does OSSeva do, and not do, in a VMware exit?
The scope is deliberate. We do the part of a VMware exit that involves the software on your servers, and leave the virtualization platform to the people who specialise in it.
What we do
- Inventory the data tier on your VMware estate: every database, broker, cache and Spring or Tanzu component, its version and who supports it today.
- Decide, component by component, whether it keeps running and changes support source, moves to its open source equivalent, or is retired.
- Patch community builds where upstream or the vendor has stopped: RabbitMQ, PostgreSQL, MySQL, Kafka, ZooKeeper, Redis and Valkey, MongoDB, Spring and GemFire with Apache Geode.
- Migrate Tanzu middleware to open source equivalents: RabbitMQ to community RabbitMQ, GemFire to Apache Geode, Spring to community Spring with independent patching, PostgreSQL to community PostgreSQL.
- Operate the result around the clock on the Operate tier, on whichever platform it ends up running.
What we do not do
- Migrate virtual machines, swap the hypervisor, or design the target virtualization platform. Your platform team or an infrastructure integrator does that.
- Resell Broadcom or VMware licences, or negotiate your Broadcom renewal.
- Support VMware infrastructure products such as vSphere, vCenter, vSAN, NSX or VMware Cloud Foundation, or Greenplum. OSSeva publishes no coverage for them.
- Speak for Broadcom. OSSeva is independent: it is not endorsed by or affiliated with Broadcom or VMware.
VMware, vSphere, Tanzu, GemFire and TrueSource are Broadcom trademarks, used here only to describe the software we support.
Which parts of the data tier are tied to VMware?
Mostly the contract, not the engine. RabbitMQ, PostgreSQL, Apache Geode and Spring are open source and run on any hypervisor, Kubernetes or bare metal. What ties them to VMware is the commercial packaging and support around them, and the assumptions your operations built on the old platform. That means the data-tier decision can be made separately from the hypervisor decision, and before, during or after it.
VMware exit data-tier decision matrix
For each component you keep the engine and change who supports it, or you move to the open source equivalent. Neither is the default.
| Component | Tied to the hypervisor? | Keep the engine, change support | Move to open source | Read more |
|---|---|---|---|---|
| RabbitMQ (Tanzu RabbitMQ) | No. The broker is community RabbitMQ and runs on any hypervisor, Kubernetes or bare metal. | Patched RabbitMQ replaces the Broadcom support contract with no broker move. | Community RabbitMQ on Kubernetes or VMs: export vhosts and topology, rebuild policies, validate in parallel, then cut over. | |
| GemFire | No. GemFire is a JVM data grid; Apache Geode is its upstream project. | Patched GemFire 9.x and 10.x builds, so the grid stays as it is. | Apache Geode, with cluster topology and region security reviewed before cutover. | |
| Spring Boot and Spring Framework (Tanzu Spring) | No. Spring runs wherever the JVM does. | Independent patching of the Spring lines you run, without a Broadcom subscription. | Upgrade to an upstream-supported Spring line when your application is ready. | |
| PostgreSQL (Tanzu Postgres, Postgres on VMs) | No. Community PostgreSQL is the engine. Check VM-level HA and snapshot backups. | Patched community PostgreSQL past end of life, with replication-based failover instead of VM restart. | Community PostgreSQL on the new platform, with logical replication for the cutover. | |
| MySQL and Valkey or Redis | No. Both are community engines; Broadcom sells support for them inside TrueSource Data Services. | Patched MySQL and Redis or Valkey builds on a per-cluster contract. | Community MySQL, Valkey or Redis on the new platform. | |
| Kafka, ZooKeeper, MongoDB and other engines on VMs | Not by the engine. They only move when their virtual machines move. | Leave the engine alone, test failover and backup on the new platform, and keep patching. | Only if the engine itself is at end of life; that is a separate upgrade decision. |
Broadcom sells support for PostgreSQL, RabbitMQ, MySQL and Valkey inside TrueSource Data Services, announced on 31 August 2026. See Broadcom TrueSource compared with OSSeva for what each covers.
What changes in the data tier when the hypervisor changes?
The engine does not change. What surrounds it does. These are the four places a data-tier exit plan most often finds a surprise, to be tested in your own environment.
High availability
A single-node database or broker that relied on the hypervisor to restart a failed VM has no failover of its own. Move that duty to the engine: replication for databases, mirrored or quorum queues for brokers, clustering for grids.
Backups
VM snapshots are not database backups. If your recovery plan was a quiesced VM snapshot, replace it with engine-native backups and point-in-time recovery before the move, and test a restore.
Storage and network behaviour
Brokers and databases are sensitive to disk latency and network jitter. Measure fsync latency, throughput and replication lag on the new platform before cutover rather than assuming they match.
Licence metrics and agents
Any commercial software licensed by vCPU, host or cluster, and any agent that talks to vCenter, needs a second look. This is a check of your contracts, not something OSSeva can answer for a vendor.
VMware migration services for the data tier: how it runs
The same four stages apply to every component. We set no fixed schedule: the pace follows the clusters, your change windows and your hypervisor project.
Inventory and classify
List every engine, version, owner and support contract on the estate, and mark which have a Broadcom or VMware commercial dependency.
Choose per component
Keep and re-support, move to the open source equivalent, or retire. The matrix above is the starting point; the answer is set per cluster.
Validate in parallel, then cut over
Live replication, dual writes or traffic shadowing keep the old system running until your team signs off. Every cutover has a rollback point.
Operate the result
Patch tiers keep every version covered. Operate adds 24/7 monitoring and incident response with a 15-minute P1 response, wherever the cluster runs.
Pricing model: per cluster, with no licence resale
OSSeva support is priced per application cluster across the Patch, Assure and Operate tiers. We do not resell Broadcom or VMware licences, and migration work is scoped from your real estate on a discovery call. Contact us for a quote.
Who does what alongside your hypervisor project?
Your platform team, or the integrator you choose, plans and moves the virtual machines to whichever platform you pick: another hypervisor, Kubernetes, a public cloud or bare metal. OSSeva owns the clusters that run on them. Because the engines are hypervisor-agnostic, we can swap a support contract first and shrink Broadcom exposure straight away, rebuild a cluster on the new platform during the move, or take over operations once it lands. For the Tanzu-specific view, see leaving Tanzu Spring, RabbitMQ and GemFire.
Frequently asked questions
What is a VMware exit strategy for the data tier?
It is the plan for the databases, message brokers, caches and Spring and Tanzu components that run on top of VMware, separate from the plan for the hypervisor itself. For each component you decide whether it keeps running as it is under a different support source, moves to its open source equivalent, or is retired. The engines are mostly open source and run on any hypervisor, Kubernetes or bare metal, so the data-tier decision can be made on its own schedule.
Does OSSeva offer VMware migration services?
For the data and middleware tier only. OSSeva moves and supports databases, message brokers and Tanzu components such as RabbitMQ, GemFire, Spring and PostgreSQL. It does not migrate virtual machines, swap the hypervisor or design the target virtualization platform. Your platform team or an infrastructure integrator does that part, and OSSeva works alongside them.
What belongs in a VMware exit plan for databases and brokers?
An inventory of every engine, its version and who supports it today; a decision per component (keep and change support, move to the open source equivalent, or retire); the checks for anything that relied on VM-level high availability, VM snapshot backups or the storage and network behaviour of the old platform; and a cutover per cluster with a rollback point. Each of these is a per-cluster decision rather than one estate-wide switch.
Do I have to leave vSphere before I can leave Tanzu RabbitMQ, GemFire or Spring?
No. Those products are software that runs on a platform, not part of the hypervisor. You can change who supports RabbitMQ, GemFire or Spring while the virtual machines stay where they are, and you can move the virtual machines while the support contract stays the same. The order is your choice.
Is OSSeva affiliated with Broadcom, and do you resell Broadcom or VMware licences?
No to both. OSSeva is an independent support vendor. It is not endorsed by or affiliated with Broadcom or VMware, and it does not resell their licences. VMware, vSphere, Tanzu and GemFire are Broadcom trademarks, used here to describe what we support.
Does OSSeva support Greenplum, vSAN, NSX or VMware Cloud Foundation?
No. OSSeva publishes no coverage for VMware infrastructure products or for Greenplum. Coverage is the open source data and messaging software listed on the supported versions page, including RabbitMQ, PostgreSQL, MySQL, Kafka, ZooKeeper, Redis and Valkey, MongoDB, Spring and GemFire with Apache Geode.
How is a VMware data-tier exit priced?
Support is priced per cluster across the Patch, Assure and Operate tiers, and migration work is scoped after a discovery call against your real estate. We do not publish price bands yet. Contact us for a quote.
Plan the data-tier side of your VMware exit.
Start with a discovery call. We inventory your databases, brokers and Tanzu components, and agree what moves, what stays and who supports it. Contact us for a quote.