What Sitecore says it did
Sitecore provides digital experience and content management technology. Its applications ran in Azure Kubernetes Service and relied on self-managed Redis as a primary datastore. Per Microsoft's account, shared infrastructure caused operational complexity and occasional planned downtime meant to avoid performance impacts between tenants. Operations staff also spent time on passwords, operating system updates, cluster balancing and other maintenance.
Architect Aaron Mousavi said everything worked but the company wanted a more flexible, scalable and integrated platform. He pointed to expected growth in agentic AI workloads.
The migration itself is the headline claim. Microsoft and Redis helped Sitecore move roughly 1,000 datastores while keeping them synchronized and available. Director of Engineering Thomas Duyck described a one-to-one transfer of Fortune 500 customers' large data sets, with most of the changeover automated.
Claimed benefits, and the limits of the evidence
- Isolation: Duyck says each customer gets dedicated resources. That reduces the chance of one customer's usage hurting another and cuts the need for planned downtime or for chasing usage spikes.
- Operations: Routine management and upgrades are automated. Sitecore says this frees two dedicated operations resources for customer requests and AI work. The story doesn't say whether these were full-time roles or headcount cuts, so don't read it as two jobs eliminated.
- Cost: The headline promises "significant savings." The story's only figures are "hundreds of thousands of dollars annually" and "significant annual costs," with no baseline, time period or method. Treat it as a directional claim, not a benchmark.
- Right-sizing: Sitecore says it can size resources per customer. That lets it serve both larger and smaller customers without overprovisioning.
- Security: Sitecore adopted private endpoints and Microsoft Entra ID managed identities. It describes private, encrypted connections between AKS and Azure Managed Redis. Mousavi says customer data stays inside its Azure networks and there are no passwords to leak. This supports the claim that password management and credential rotation are gone for this connection. It doesn't prove that no credentials exist anywhere in the deployment.
- Product: Sitecore built a lightweight version of its Content Hub digital asset management product on Azure Managed Redis and folded it into Sitecore AI. Customers can start small and scale up to full enterprise Content Hub. The story gives no adoption numbers or architecture.
The story gives no migration duration, Redis version, tooling, performance benchmarks or incident-rate data.
How a live Redis migration usually works
Sitecore didn't say how it kept data synchronized, so don't assume a method. Microsoft's general migration guide lists four options for moving a cache to Azure Managed Redis:
| Approach | Upside | Downside |
|---|---|---|
| Create a new cache | Simplest to implement. | Data has to be repopulated, which may not suit many applications. |
| Export and import an RDB file | Generally compatible with any Redis cache. | Data written to the old cache after the snapshot can be lost. |
| Dual-write to both caches | No data loss or downtime, per Microsoft, and easier testing of the new cache. | Needs two caches running for an extended period. |
| Programmatic copy | Full control over how data moves. | Needs custom code. |
One compatibility rule matters for RDB imports. The Redis version you export from should be equal to or lower than the version Azure Managed Redis provides.
Migration tooling is a separate matter. Microsoft's preview tooling for Basic, Standard and Premium tiers handles endpoint migration only. Its documentation says it does not migrate any data. Sitecore's starting point was self-managed Redis, and the story doesn't say it used that tooling.
Don't read this as a platform-wide uptime guarantee
Sitecore's no-downtime result describes a controlled migration. It isn't a service-level promise. Microsoft's reliability documentation says high availability means at least two nodes with automatic replication. In a zone failure, expected downtime is typically 10 to 15 seconds. Data not yet replicated can be lost.
Regional resilience is more hands-on. Active geo-replication is asynchronous. Customers are responsible for routing traffic and deciding when to fail over. Inconsistencies are possible during regional outages. Maintenance also triggers failovers, so Microsoft says applications should have retry logic.
In short, a managed service takes patching and balancing off your plate. It doesn't remove the need for resilient client design.
Why Azure shops should care
This story lands as Microsoft pushes Redis users toward its newer service. A third-party analysis dated June 2026 reports that Azure Cache for Redis Enterprise retires on March 31, 2027, and Basic, Standard and Premium follow on September 30, 2028. Microsoft's own migration page now says to move existing instances to Azure Managed Redis as soon as you can. I haven't verified those dates against an official Microsoft retirement notice. Check the current Azure announcement before planning around them.
Another Microsoft engineering team has shared its own migration experience on a Power Platform developer blog. It reports about 72% lower ongoing Redis costs, including the AMR replacement, against its pre-migration baseline. That is a different workload with its own cleanup work, so don't extrapolate it to Sitecore or to your own environment.
One caution for Sitecore's own customers. Sitecore's XP developer documentation says Azure Managed Redis supports Microsoft Entra ID authentication, but Sitecore doesn't currently support that method for its session state provider. That documentation covers on-premises deployments. Sitecore's cloud setup, as described in the case study, is evidently different.
Practical takeaways for IT teams
- Pick the migration method first. Whether cache data can be rebuilt decides if you need snapshot, dual-write or programmatic copy.
- Check Redis versions and key sizes. Confirm RDB compatibility before relying on snapshot import.
- Plan for retries anyway. Failovers and maintenance still cause brief connection interruptions.
- Decide your resilience tier deliberately. Zone redundancy and geo-replication cost more and behave differently.
- Treat passwordless auth as a goal to test. Entra ID managed identities and private endpoints can remove shared secrets, but validate that your client libraries support them.
- Run your own cost model. Sitecore's savings figure has no published baseline, so it can't stand in for your numbers.
Bottom line
Sitecore's account is a credible example of moving a large, multi-tenant Redis estate onto a managed service with little operational disruption. The savings, staffing and security gains are company statements with sparse detail. The migration trade-offs and the reliability limits in Microsoft's documentation are the more reusable lessons.