vSAN ESA landed with a fair amount of marketing noise, and like most things that arrive with marketing noise, the actual technical substance got somewhat obscured by the time it filtered down into vendor conversations and design reviews. When clients ask whether they should be on ESA or OSA, the honest answer depends entirely on what hardware they're sitting on and what they understand about the migration path between them — which turns out to be the part nobody leads with.
What OSA Was Actually Doing
OSA organized storage into disk groups. Each group had a caching device — originally an SSD fronting spinning disks in hybrid configurations, then an NVMe device fronting SATA SSDs as all-flash became the norm — that absorbed incoming writes, acknowledged back to the VM, and destaged to the capacity tier behind it on the backend. The model existed because it compensated for a real performance gap: the capacity media was slow enough that without a write buffer absorbing the burst, VM latency would have been unacceptable.
The disk group was also a failure domain. If the caching device in a group failed, every capacity device in that group became unavailable until the cache was replaced and rebuilt. Data loss didn't follow automatically — assuming the storage policy had FTT=1 configured correctly, the data existed on other hosts — but a cache failure meant a sudden loss of available capacity and a rebuild process that pulled on cluster resources until it completed. In a small cluster, one cache failure at the wrong time was an uncomfortable afternoon.
This worked well enough to get vSAN to production scale across thousands of environments. It was a reasonable architecture for the hardware generation it was designed around. The problem ESA was built to solve is that NVMe devices don't need a cache tier fronting them — they're fast enough that buffering writes to a separate tier and destaging them to a slower capacity tier is just adding latency for no benefit.
What ESA Actually Changed
ESA threw out the disk group entirely. No caching device, no capacity tier, no staging relationship between them. Every NVMe device in the host is added to a single storage pool, and all devices contribute to both performance and capacity simultaneously, managed by a new log-structured filesystem Broadcom calls the vSAN LFS.
The LFS is what makes this work without a cache tier. Rather than writing to a buffer and destaging later, LFS ingests incoming writes as sequential I/O into what it calls the performance leg of each object, acknowledges back to the VM immediately, and then asynchronously packages those writes into efficient full-stripe writes across the capacity leg. The VM sees fast acknowledgment. The backend gets clean sequential I/O that NVMe handles well. The write amplification that came with OSA's destage cycle is eliminated.
A device failure in ESA takes one device out of the pool. It doesn't take a disk group down. The remaining devices keep contributing to both performance and capacity, and the rebuild draws on all of them in parallel.
The RAID-5 story changed in a way that actually matters for capacity planning. In OSA, RAID-5 carried a write performance penalty that most architects worked around by defaulting everything to RAID-1 — accepting 2x capacity overhead because RAID-5 with the cache destage overhead wasn't worth the tradeoff on latency-sensitive workloads. In ESA, erasure coding is embedded in the LFS write path, and Broadcom's own benchmarking puts RAID-5 performance comparable to RAID-1. You can run RAID-5 on a 3-node ESA cluster, get 33% capacity overhead instead of 100%, and not pay a meaningful latency penalty for it. In a large environment, that difference in usable capacity per dollar is significant.
Snapshots changed completely. OSA snapshots were redo-log based — the same mechanism vSphere had used for years, with all the associated performance degradation during active snapshot operations and consolidation times that scaled poorly as snapshots grew. ESA snapshots are metadata-based, built on the LFS structure. Consolidation is roughly 100x faster than the OSA model according to Broadcom's documentation, and crash-consistent snapshots can be taken without stunning the VM. For environments running backup workloads against frequent snapshot schedules, that operational difference is tangible.
The Migration Path That Surprises People
In-place upgrade from OSA to ESA is not supported. There is no conversion path, no rolling migration across disk groups, no cluster-level toggle. You build a new ESA cluster from scratch, migrate workloads to it using vMotion or HCX, and decommission the old one when it's empty.
This surprises people less because the concept is complicated and more because the hardware requirements for ESA mean the new cluster often requires entirely new servers.
ESA requires NVMe TLC flash storage devices — minimum 1.6TB per device, at least 4 devices per host. It requires 25GbE networking at a minimum; 10GbE is not supported. The ReadyNode hardware profiles were updated with lowered minimums in November 2025, which expanded the range of qualifying hardware somewhat, but the NVMe and 25GbE requirements remain hard requirements.
- The planning conversation. A client I worked with had been running vSAN OSA for four years across a 6-node cluster — SATA SSDs on 10GbE, solid configuration, no problems with it. They read the ESA feature summary, got interested in the performance numbers and the RAID-5 capacity efficiency, and started scoping a migration.
- The discovery. Midway through the planning exercise, it became clear that none of the existing nodes met ESA's hardware requirements. The entire server fleet would need to be replaced, not just the storage devices. What had looked like a storage architecture project was actually a full hardware refresh.
- The outcome. They aligned it to their next hardware refresh cycle and planned ESA from the start for that deployment. The right call — but only because the hardware requirement was identified before anyone had committed to a timeline.
- The lesson. ESA capability planning starts with a hardware audit, not a feature comparison. The feature list is only relevant if the hardware qualifies.
When OSA Is the Right Answer
OSA is not a burning platform. Broadcom has not announced an end-of-life timeline for OSA support, and environments running it on well-maintained hardware have no technical reason to force a migration. OSA still supports hybrid configurations with a mix of SSD and spinning disk capacity devices, broader hardware compatibility including SAS and SATA flash devices, and 10GbE networking. For an environment that isn't planning a hardware refresh and is operating stably, moving to ESA is not a problem you have right now.
The urgency that sometimes gets injected into this conversation — "you need to be on ESA" without qualification — doesn't match the technical reality for an organization that isn't shopping for new servers. ESA is the right architecture for new deployments and for hardware refreshes where the foundation can be built correctly from the start. It is not worth forcing a premature hardware refresh just to get onto a newer filesystem model.
The Storage Policy Question That Gets Overlooked in Both Architectures
Regardless of which architecture is underneath, most vSAN environments leave meaningful capacity efficiency on the table by applying a single storage policy to everything in the cluster.
In OSA, the reflex to default all workloads to RAID-1 made some sense given the RAID-5 performance tradeoff — but most workloads in a typical enterprise estate are not running latency-sensitive transactional databases. File servers, development environments, test workloads, and backup targets can all tolerate RAID-5 protection without any operational consequence. Running them on RAID-1 for convenience is paying 2x capacity overhead for workloads that don't require it.
In ESA, that tradeoff is gone — but the reflex often isn't. Teams that move to ESA and continue defaulting to RAID-1 across the estate are leaving the capacity efficiency benefit of the architecture sitting on the table. Storage policy-based management exists precisely to let each workload carry the appropriate protection level. The time required to define per-workload policies is the reason it usually doesn't happen, not a technical limitation.
It's one of the more consistent ways that a vSAN environment that looks correctly designed from a cluster topology perspective is still underperforming on cost per usable terabyte — and it's fixable without touching the hardware.