The most useful edge strategy creates a resilient, repeatable platform that can support today’s operations and tomorrow’s digital experiences.
Can your edge foundation keep up?
According to IDC research, retail edge adoption is already underway: 49% of retailers are using some element of edge computing, 97% have it in their plans, and 39% are using some element of AI. The differentiator will not be whether retailers experiment with edge and AI. It will be whether they can operationalize those investments across a distributed fleet.

That starts with a foundation that is consistent by design, resilient through disruption, and flexible enough to accommodate what comes next.
Recently we hosted Dave McCarthy, VP Analyst at IDC, Saad Malik, CTO and Co-Founder of Spectro Cloud, and Chris Kennedy, Senior Architect at Portworx for a webinar, Build a Resilient Edge for What’s Next, to discuss what separates a scalable retail edge program from a collection of promising pilots.
Our conversation went well beyond Kubernetes and infrastructure. We also explored the operational choices retailers need to make now: how to keep stores running through connectivity disruptions, how to avoid fleet drift across hundreds or thousands of locations, and how to create a foundation for AI without turning every new use case into an infrastructure project.
Here are five key insights from the discussion and why they matter for retailers planning their next move.
1. Edge is a complement to cloud, not a replacement
Edge computing is not about robotically moving everything out of the cloud. It is about placing the right workloads where they can deliver the best outcome.
For latency-sensitive, bandwidth-heavy, or connectivity-dependent workloads, that can mean processing data locally and sending events, summaries, or selected data upstream. Video analytics is a clear example: a store does not need to continuously send every high-resolution video stream to the cloud in order to identify an event and act on it.
That approach can help retailers reduce data movement and cost while keeping essential services available when WAN connectivity is intermittent. It also gives teams more control over where operational data is processed, which is an important consideration for security, compliance, and data sovereignty.
“…And so this idea of, like, latency, cost, security, compliance, resiliency, not everybody prioritizes them the same way, but those are the things that I think are really sort of having an impact on why edge computing all of a sudden is looked at as a complement.”
— Dave McCarthy, IDC
2. The real scaling problem is inconsistency, not store count
A handful of stores can be managed with manual processes. A national fleet can’t.
The issue of configuration drift came up repeatedly: small, location-by-location differences that accumulate until each store becomes its own “snowflake.” The result is harder troubleshooting, slower updates, more onsite intervention, and a greater likelihood of outages.
The antidote is a centrally managed, versioned definition of the full store platform, not just throwing Kubernetes at the problem. That definition should account for the data layer, logging, monitoring, security, ingress, applications, and the operational policies that govern updates and recovery.
A disciplined rollout model also matters. Test changes in a lab or sandbox, roll them out in stages, and preserve the local variables each store needs without sacrificing the common baseline. This is how teams can update a fleet predictably instead of discovering differences after a failure.
“Within six months or a year, some config drift happens where it will eventually lead to an outage.”
— Saad Malik, Spectro Cloud
3. Design resilience into the pilot, not after the rollout
Retail stores are becoming miniature data centers for digital business. Point of sale, video, inventory, employee workflows, and customer experience increasingly depend on local services being available.
That changes the standard for an edge pilot. Resilience cannot be a phase-two concern. Retailers need to ask from the outset: What happens when a node fails? What happens when the WAN is unavailable? How does a replacement device get deployed? Can a store continue operating in a degraded state?
There are several practical architectures for this reality. The essential point is that instead of a one-size-fits-all topology, retailers need the data layer and recovery model to match the constraints of an edge site: limited space, lean local staffing, and a low tolerance for downtime.
When recovery is simple and replacement hardware can be connected with minimal onsite expertise, IT can avoid expensive truck rolls and keep store personnel focused on serving customers.
“You can look at it as also building a competitive advantage, because you’re giving yourself a platform that whatever you do dream up, you know, down the road, you’ve already put that in place, and it’s not something that you then have to go retrofit through thousands of stores or even hundreds of stores.”
— Chris Kennedy, Portworx
4. Modernization doesn’t require an all-at-once rewrite
Not all applications will move to cloud-native architectures in either the short or long run. Retailers will continue to run legacy applications, which means operating a mix of virtual machines, virtual appliances, containers, and cloud-native services for years.
So the path forward is to establish a common platform that can support both legacy and modern workloads, then evolve applications on a timetable that makes business sense.
This gives retailers a way to standardize operations now while progressively retiring older components. It also avoids the false choice between preserving the status quo and launching a disruptive, all-at-once transformation.
“And so you see more and more people kind of converting. If they have existing environments, you know, they’re modernizing them to things that look a lot more like, you know, cloud-native principles, but not necessarily limited to the cloud, right? Cloud-native principles that you can deploy anywhere.”
— Dave McCarthy, IDC
5. Start AI where outcomes are measurable and risk is manageable
AI is seemingly omnipresent, but for those starting out the panel’s advice was pragmatic: start with internally focused use cases that have measurable value before moving to highly visible customer-facing experiences.
Examples include inventory insights, planogram compliance, queue monitoring, shrink analysis, and video analytics. These applications can help teams prove value, improve operational workflows, and build confidence in the supporting platform.
It’s also worth considering an incremental technical path. Smaller models may enable early experiments on existing CPU-based infrastructure, while GPU-enabled nodes or accelerators can be added later as workloads mature. The goal is to create a repeatable way to introduce capabilities when the business case is ready.
“I think step one is to look at more of what you might call the low-hanging fruit of things like making better use of the data that’s being generated in the store. That’s one of the side benefits of all the technology that’s been packed into these stores today, is now you have much more detailed information around inventory. You can do so many more things around planograms and, you know, how people are moving around stores. You can look at stuff like wait time at registers.”
— Dave McCarthy, IDC
Build an Edge Foundation for the Future
Build a consistent, centrally managed edge foundation before scaling AI or new digital services. That foundation should support legacy and cloud-native workloads, keep stores operating through disruption, and make future capabilities easier to deploy across the fleet.
Ready to take your edge modernization journey? Watch Build a Resilient Edge for What’s Next to hear the full conversation, including practical guidance on fleet profiles, staged rollouts, compact high-availability architectures, and how retailers can move from initial edge pilots to a scalable operating model.