# How we switched 150+ stores from Redis to Valkey, and nobody cared!

**Date:** 2026-06-22  
**Author:** Kees C. Bakker  
**Categories:** Projects  
**Tags:** How It's Made  
**Original:** https://keestalkstech.com/how-we-switched-150-stores-from-redis-to-valkey-and-nobody-cared/

![How we switched 150+ stores from Redis to Valkey, and nobody cared!](https://keestalkstech.com/wp-content/uploads/2026/03/Redis-vs-Valkey.jpg)

---

Ever since we started our move from the on-premises data center to the cloud, delivery teams haven't had to worry about their infrastructure. We've built a platform that lets delivery teams focus on solving business problems. At Wehkamp, teams don't have to worry about Kubernetes, network infrastructure, or writing Terraform code to provision data stores. They don't even need to know about AWS! Team infrastructure is easily provisioned through our Slack bot. *Basically, the teams have been running serverless since 2013!*

Having such a platform comes with a peculiar downside: when teams don't *have to care* about infrastructure, they usually... don't!

*So what if we want to migrate our AWS ElastiCache Redis stores to Valkey?* In this article we'll explain how we switched 150+ AWS ElastiCache stores from Redis to Valkey.

A big shout-out to [Klaas Talsma](https://www.linkedin.com/in/klaastalsma/) and [Chris Vahl](https://www.linkedin.com/in/chris-v-4b9a62b/) for working together on this story.

We started this migration at the beginning of 2026, so this article was long overdue.

## Why?

Back in 2024, [Redis switched to another license](https://redis.io/blog/redis-adopts-dual-source-available-licensing/), and that got developers around the world thinking about a fork. Valkey was born in no time! [AWS was heavily involved from the start](https://aws.amazon.com/blogs/opensource/why-aws-supports-valkey/). Honestly, the results were very impressive. And they didn't stop there, as Valkey 8.1 was released with [even more power](https://aws.amazon.com/blogs/database/year-one-of-valkey-open-source-innovations-and-elasticache-version-8-1-for-valkey/#:~:text=Innovations%20that%20matter).

When we read that it was [20% cheaper to run Valkey](https://aws.amazon.com/blogs/database/get-started-with-amazon-elasticache-for-valkey/#:~:text=On%20ElastiCache%20for%20Valkey%20self%2Ddesigned%20(node%2Dbased)%20clusters%2C%20you%20can%20benefit%20from%20up%20to%2020%25%20lower%20cost%20compared%20to%20other%20engines.) than Redis, the decision became a no-brainer. So we threw together some slides, gave a Tech Talk, and started adding Valkey to our platform.

![](https://keestalkstech.com/wp-content/uploads/2026/03/TechTalks-Valkey-Provisioning-slide-3.jpg)
*This was only the beginning, as these slides are from early 2025.*

![](https://keestalkstech.com/wp-content/uploads/2026/03/TechTalks-Valkey-Provisioning-slide-4-2.png)
*To sum up: it is faster && cheaper => let's migrate.*

## Step 1: Stop the bleeding

Whenever we introduce new technology, we work according to a two-step principle:

1. **Stop the bleeding**: make sure *newly* provisioned infrastructure uses the new technology by *default*.
2. **Migration**: present a migration path and let teams move at their own pace.

Our delivery teams don't have to write Terraform code (they can); we provide a Slack bot to guide developers to provisioning a data source. Here we swapped out the provisioning of Redis resources for that of Valkey. In the beginning we even kept the Redis icon, but over time that got swapped as well, as the name caused confusion.

![](https://keestalkstech.com/wp-content/uploads/2026/06/provisioner-screenshot.png)
*The Provisioner provides an easy dialog in Slack for Valkey provisioning. In an earlier version you could select Redis or Valkey engines.*

Our Provisioner provisions Valkey according to Tech Hub standards, including TLS, authentication, and multi-AZ. It generates Terraform code, commits to the IAC Git repository, creates a PR, and watches it roll out to production, all while keeping the user informed on Slack.

## Step 2: Migration

Again, we made some slides:

![](https://keestalkstech.com/wp-content/uploads/2026/03/TechTalks-Valkey-Provisioning-slide-14.png)
*We made TLS mandatory for our new Valkey setups, which requires application changes.*

The usual suspects moved right away, but the bulk of the teams did not migrate 😱. So we talked to the teams to find out if there were any blockers.

- Some older services did not use AUTH or a TLS connection, and the teams did not want to refactor those applications to include both features.
- Some teams still had their service on a *single fascia* environment, so they needed to move to a multi-fascia environment before they could benefit from the new setup.
- Some teams had very busy backlogs, so they couldn't prioritize it.

## Step 3? Now what?

What could we, as a platform team, do? If we wanted to reap the performance and financial benefits, we needed to make an in-place upgrade possible. Fortunately for us, Valkey is meant as a drop-in replacement.

However, we hit a technical hurdle: our latest infrastructure standards mandate encryption and TLS, but applying those specific enhancements to existing environments would have made an in-place engine upgrade impossible. 
Fortunately there was a pragmatic solution: we rewrote an older version of the Terraform module, so old environments could also benefit from the new engine.

By testing this extensively on clusters with at least two nodes, we confirmed we could swap the engine under the hood with no downtime, because with a multi-node cluster, there's always a node left to serve traffic during the switch.

The result was a process so streamlined that teams could migrate to Valkey by updating just a few lines of code:

![](https://keestalkstech.com/wp-content/uploads/2026/03/image-3.png)
*Only 4 lines need to be changed.*

### A New Year's Resolution

The next step was to talk to [Koen Roumen, Head of Technology](https://www.linkedin.com/in/kmroumen/). We explained that there was no reason not to move, and we came up with a plan: *either* the teams move *before* a certain date, or *we would make the move for them.* Maybe it was the optimism that comes with starting a new year, or maybe the stars aligned, but we all agreed on a pretty tight timeline.

![](https://keestalkstech.com/wp-content/uploads/2026/03/Shop-Valkey-Migration-slide-5.png)
*We wanted to move within the month.*

Again, some teams woke up and moved, but most teams were like: *if you're sure there is no impact, go for it!* And so we did. We ran the migration in batches. On the morning of the 27th, we migrated a batch of 47 stores for 6 delivery teams across 3 AWS development environments to Valkey. It went incredibly smoothly. Yes, it took AWS a while to provision the stores (no idea why), but by 9 o'clock we were done. Our delivery teams did not report any problems.

Production was scheduled for a week later. As dev went so smoothly, we dropped our requirement to send a backend engineer to the call, and we decided to start at 09:00 instead of 08:00. Again: one smooth transition.

## Step 4: Right sizing

Now that the migration to Valkey was behind us, we shifted our focus from "making it work" to "making it right". Because our in-place migration kept the exact same instance types that were previously running Redis, much of our fleet was likely over-provisioned. On a number of stores we *observed* lower resource utilization after the switch.

- **Valkey runs leaner.** Where we saw genuinely lower load after the swap, the engine itself is the likely driver.
- **Some stores were simply oversized under Redis.** Safety margins had been chosen years ago and never revisited. That capacity was "ghost capacity" regardless of engine, the migration was just the moment we finally went looking for it.

To do this well, we started a deep-dive analysis, leveraging LLMs and the AWS CLI to parse two weeks of CloudWatch metrics since the migration. Guided by our FinOps tooling, this data-driven approach identified consistently over-provisioned stores, which we then scaled down, keeping headroom for peaks. It's a pragmatic approach to cloud spending: optimize the baseline first, so we only pay for the performance we actually use.

## So what did we learn?

155 stores migrated, no production downtime, and zero complaints. We switched the engine, we're seeing the savings, and, just as we intended, nobody even noticed. Great.

Our main lessons:

1. Valkey really is a great replacement for Redis.
2. Our delivery teams are very busy, and that's great! But that shouldn't stop us, as a platform team, from moving forward. This is where the real benefit of Infrastructure as Code and AWS shows: we can move the whole fleet without asking every team to stop what they're doing.
3. There is [even more power](https://aws.amazon.com/blogs/database/announcing-valkey-9-1-for-amazon-elasticache/#:~:text=Improve%20price%2Dperformance%20at%20scale) ahead in Valkey 9.1!