The Light Switch Test
Part 2 from Everpure Accelerate 2026, where the Enterprise Data Cloud moved from vision to blueprint
Last night, in Part 1, I wrote that the Everpure Accelerate 2026 opening keynote did not really feel like a storage keynote.
My takeaway from day one was simple:
Everyone wants your data.
The bigger question is who owns the context.
Day two answered a different question.
If day one was about why the Enterprise Data Cloud matters, day two was about how customers are supposed to get there without turning it into another giant transformation project that sounds great on stage or in a boardroom and then dies somewhere between budget approval, staffing constraints, internal politics, and the next urgent outage.
That is why the second keynote mattered.
It was not trying to restart the vision. The vision had already been established. It was about turning that vision into something customers could actually use: a methodology, a blueprint, and a way to connect data architecture to risk reduction, efficiency, agility, modernization, and business outcomes.
And then John Colgrove, Coz, did what Coz does.
He simplified the whole thing.
Not by making it smaller.
By making it clearer.
The phrase that stayed with me from his session was not a technical phrase. It was not Enterprise Data Cloud, Data Primacy, Fusion, data intelligence, or workload mobility, even though all of those ideas were underneath what he was saying.
It was the light switch.
Coz talked about walking into a room at home and turning on the light. You know exactly what is going to happen. It is simple. It is obvious. It works the way you expect it to work.
Then he compared that to walking into a conference room at the office, where five people spend the first few minutes trying to figure out how to turn on the right lights, dim the screen area, wake up the display, connect the laptop, and make the audio work.
Everyone has lived that moment.
It is also a perfect way to explain what Everpure has been trying to do since the beginning.
Make the complicated thing feel like the light switch.
That may sound too simple for enterprise infrastructure, but I think it is exactly the point. The best infrastructure does not feel simple because the problem is simple. It feels simple because somebody did the hard engineering work to hide complexity without hiding control.
That has always been part of the Everpure story.
When Pure Storage first became known in the market, the message was not only flash performance. Performance mattered, of course. But the thing customers really felt was that the experience was different. The arrays were simpler. The upgrades were non-disruptive. The support model was different. Evergreen architecture was different. The idea that you could keep modernizing without the usual forklift pain was different.
Over time, that simplicity moved from one array to more of the environment.
Fusion extended the idea from a single system to a fleet. Policy, placement, automation, workload mobility, service levels, compliance, and lifecycle management started to move from device-by-device thinking toward something broader.
Now, with the Enterprise Data Cloud, Everpure is trying to move that simplicity again.
From array to fleet.
From fleet to data.
From data storage to data management.
That was the thread both Nirav Sheth and Coz pulled through the keynote, and I think it connected day two back to day one in a very useful way. They made it clear that the move from Pure Storage to Everpure is not an abandonment of what got the company here. It is a continuation of the same journey.
That matters because customers are rightfully skeptical when technology companies rebrand or expand their message. They wonder whether the company is moving away from the thing they trusted. They wonder whether the new story is strategy or just vocabulary.
Coz addressed that directly.
We are not abandoning storage infrastructure. We are going to keep building the best storage infrastructure we can. But we are also going higher, because to build better infrastructure, you have to understand more about the data above it.
That is a founder’s version of the message.
Less theater.
More first principles.
If you store data, you want to know what it is. You want to know how it will be accessed. You want to know how often. You want to know what it relates to. You want to know whether there are copies. You want to know whether those copies create risk. You want to know whether the rules are being followed.
The problem, as Coz pointed out, is that nobody really knows the future.
The infrastructure has to be built for agility.
That word gets overused, but in this context it matters.
Agility is the ability to change without breaking everything.
It is the ability to move workloads non-disruptively. It is the ability to rebalance a fleet. It is the ability to modernize hardware without turning it into a migration event. It is the ability to adjust policies as risk changes. It is the ability to bring intelligence to data that already exists instead of forcing the business to start over.
That is where the Enterprise Data Cloud story becomes more practical.
And I personally think the Enterprise Data Cloud Success Blueprint was the clearest example of that.
I liked this part because it moved the conversation away from “look at all these capabilities” and toward “here is why it matters to you” and “what outcomes are you trying to drive?”
That is where a lot of technology conversations go wrong. We get excited about the architecture and forget that customers are not buying architecture for the sake of architecture. They are trying to solve business problems with limited people, limited time, limited budget, and increasing pressure from every direction.
They are dealing with supply chain constraints.
They are being asked to do more with the same team.
They are trying to create VMware optionality without making a reckless move.
They are modernizing applications while still running legacy workloads that cannot just disappear.
They are dealing with cyber risk, ransomware, and minimum viable business recovery.
They are being asked to support AI before the data foundation is ready.
The blueprint framework organized those pressures into three simple categories: risk reduction, efficiency, and agility.
That may seem obvious, but obvious is underrated.
Risk reduction is not just a security feature. It is knowing whether your data is protected, whether your snapshot policies are aligned, whether you can recover the minimum viable business, whether sensitive data is duplicated everywhere, and whether compliance follows the data instead of living in someone’s spreadsheet.
Efficiency is not just a density number. It is energy efficiency, automation, operational scale, fewer manual tasks, fewer migrations, and fewer people spending nights and weekends babysitting infrastructure that should be managing itself.
Agility is not just modernization language. It is VMware optionality, container readiness, AI readiness, cloud flexibility, application mobility, and the freedom to make the next decision without being trapped by the last one.
I think that is a much better way to have the conversation with customers.
Not “Do you want this product?”
But “Which business outcome are you trying to improve, and what is standing in the way?”
The Red Hat and CSX discussion made that practical.
When Eric Grabill from CSX talked about Positive Train Control, sensors along the tracks, safety requirements, and systems where a loss of data can affect train operations, the conversation moved from platform strategy into the real world.
That is where infrastructure earns its keep.
CSX has already moved a large portion of its applications to Kubernetes on OpenShift, but still has legacy VMs remaining. That is the real enterprise pattern. It is not containers or VMs. It is containers and VMs. It is cloud and on-premises. It is modern and legacy. It is AI coming next while everything else still has to run today.
The Red Hat and Portworx conversation made the point that modernization cannot mean creating another disconnected stack. Customers need one operating model across VMs, containers, and eventually AI workloads. They need a practical transition path, not a big bang migration. They need data services that protect the applications, not just compute platforms that can host them.
The St. Elizabeth Healthcare conversation made the same point in a more personal way.
Charles Shepherd talked about joining St. Elizabeth in 1997, starting at the help desk, moving through Novell, GroupWise, backups, storage, and eventually becoming part of the team responsible for systems that support a healthcare environment that never really stops.
What stayed with me was not only the technical story.
It was the laptop on vacation.
Anyone who has worked in infrastructure understands that detail. The laptop that comes with you just in case. The phone you keep checking because maybe something happened. The family event where part of your brain is still in the data center. The trip where you are physically present but operationally on standby.
That is not a feature comparison.
That is a life comparison.
Charles said he recently was able to go to his niece’s graduation and not get called. That sounds small only if you have never been the person who always gets called.
He also talked about more than one hundred hardware upgrades and more than one hundred fifty Purity upgrades without downtime. He talked about moving from older systems to modern ones without the traditional forklift migration pain. He talked about change boards becoming comfortable with upgrades during the day because the process had earned trust.
That is the kind of customer proof that matters.
It shows what the solution that was delivered gives back. It gives back time, trust and confidence.
That connects directly to the light switch idea.
Simplicity is not cosmetic. It is not just a better UI. It is not just fewer clicks. Simplicity changes what people can spend their time on. It changes what teams believe they can safely do.
And it changes whether the infrastructure team is trapped maintaining the past or free to prepare for what comes next.
Coz also said something important about time.
This Enterprise Data Cloud journey is not a one-year story. It is not one product cycle. It is not done because it showed up in an Accelerate keynote. Coz described it as a journey that will take five to ten years, and even then, it will not really be done because the solution will keep improving.
I appreciate that kind of honesty.
So when a founder says this is a long journey, I believe that more than I believe a slide that says “seamless transformation” in large font.
But I also think now is the right time for the journey to become possible.
And Coz reminded us that the best version of this is not complexity with better branding.
The best version is the light switch.
Coz, in the most Coz way possible, reminded everyone that the goal is not to make enterprise infrastructure sound impressive.
The goal is to make the hard things feel obvious.
Like turning on the lights.
I appreciate you reading.
Dmitry Gorbatov
© 2025 Dmitry Gorbatov | #dmitrywashere