On 20 October 2026, AWS announced that Amazon ElastiCache Serverless for Valkey now supports online migration with zero downtime. If you run your own Redis OSS or Valkey cluster on Amazon EC2, you can now move it into a fully managed, serverless cache while your application keeps reading and writing, without third-party replication tools or a maintenance window.
For many startups and SMBs, a self-managed Redis cluster is one of those systems nobody wants to touch: it works, but patching, scaling and failover all sit on one or two engineers. This guide explains how the new migration works, what it costs, the limits you must check first and a practical plan to move from Redis to Valkey safely.
What Is ElastiCache Serverless for Valkey Online Migration?
Online migration replicates data from a self-managed cache on EC2 into an Amazon ElastiCache Serverless for Valkey cache while traffic keeps flowing. AWS defines zero downtime as zero errors returned to the client during migration, measured the same way the ElastiCache SLA measures availability.
According to the ElastiCache documentation, your application connects to a migration endpoint, which is simply the serverless cache’s standard endpoint. During the migration, ElastiCache routes requests to your source cache while it replicates data to the target. At cutover it switches the same endpoint to serve from the serverless cache, so your application never changes its connection string a second time.
Supported sources and targets
- Source: self-managed Redis OSS 4.0 through 7.2, or Valkey 7.2 through 8.1, running on Amazon EC2 in cluster mode.
- Target: an ElastiCache Serverless for Valkey cache running Valkey 7.2, 8.1 or 9.0, created before you start. You can migrate straight to Valkey 9.0.
- Not supported as sources: ElastiCache managed caches and Amazon MemoryDB.
The feature is available in all commercial AWS Regions, the China Regions and the AWS GovCloud (US) Regions, as stated in the launch announcement.
Why This Matters: Cost and Operations
1. Lower cache pricing with Valkey
The ElastiCache pricing page states that ElastiCache Serverless for Valkey has 33% lower pricing than other supported engines, and a minimum metered data storage of 100 MB per cache, compared with 1 GB for Redis OSS and Memcached. Serverless billing is based on data stored (GB-hours) and ElastiCache Processing Units (ECPUs), where reads and writes use 1 ECPU per kilobyte transferred. For small or spiky workloads, that is often far cheaper than keeping oversized EC2 nodes running around the clock.
2. No more cache servers to babysit
With self-managed Redis you own patching, node replacement, resharding and capacity planning. A serverless cache removes that work from your team’s backlog. ElastiCache Serverless caches can hold up to 5,000 GiB per cache and process up to 15,000,000 ECPUs per second, according to the migration prerequisites.
3. Security controls stay in place
Migration connects to your source using TLS and authentication, and reads credentials from AWS Secrets Manager. You do not need to open your cache to the internet or weaken security for the move.
How the Migration Works: Step by Step
Step 1: Create an empty target cache
Create an ElastiCache Serverless for Valkey cache that is available, empty, uses the IPv4 network type and has no public endpoint. Its Valkey version must be at least as high as your source version. The target needs a subnet in each Availability Zone that ElastiCache Serverless uses in your Region.
Step 2: Prepare the migration
In the console, choose Migrations, then Create migration and Migrate to serverless. Enter the source address and port, choose an authentication method (existing secret, new secret or none) and TLS settings, then pick your target. ElastiCache validates the source and returns the migration endpoint. The procedure guide walks through each screen.
Step 3: Redirect your application
When the state shows Ready to sync, point your application to the migration endpoint and confirm it is serving traffic. ElastiCache cannot detect whether your application has moved, so verify this yourself.
Step 4: Start the data sync
Start the sync from the console or with aws elasticache start-migration --serverless-cache-name my-cache. Add --auto-cutover if you want ElastiCache to switch automatically at the next fully synced window.
Step 5: Complete the cutover
Manual cutover is the default. When you have validated the target, run aws elasticache complete-migration --serverless-cache-name my-cache. The cutover documentation notes that heavy write traffic can delay the fully synced window, so plan cutover for a quieter period.
Limits and Gotchas to Check Before You Start
- Cluster mode only: a cluster-mode-disabled source is rejected.
- Size limits: up to 32 GB of data per source node and up to 166 shards. No key name may exceed 4 KiB.
- Replication commands: your source must support
PSYNCandREPLCONF. Restore them if you renamed or disabled them. - Pipelining is serialized: a batch of 100 pipelined commands takes 100 round trips during migration, so latency for batches rises. Increase connection pool sizes temporarily.
- Scripts and pub/sub: loaded Lua scripts are not replicated, so re-run
SCRIPT LOADthrough the migration endpoint. Pub/sub clients are disconnected at cutover and must re-subscribe. - No rollback after cutover: to go back, you must move traffic to the source yourself. Migration errors are permanent; a failed migration can only be ended with a force complete.
- Source headroom: your source primaries serve all traffic until cutover and need spare CPU and memory for the initial full sync.
Pricing
Migration usage is free for the first 180 days per AWS account, starting when the account first prepares a migration. After that, you pay per node-hour for the migration nodes for as long as a migration is active. Charges continue if you only stop the data sync and end when you complete the migration. The serverless cache itself is billed at standard data storage and ECPU rates, including during the free period. Full details are on the ElastiCache pricing page.
Best Practices for a Smooth Redis-to-Valkey Move
- Audit commands first. Check your application against the supported and restricted commands list, especially
FLUSH,CLUSTERand pub/sub usage. - Rehearse in staging. Run a full migration on a copy of production data to find oversized keys or missing scripts.
- Prepare close to cutover. There is no on-demand health poll, so watch the target cache’s Events tab throughout.
- Use manual cutover for production. It gives you a validation window before switching.
- Finish what you start. Call
CompleteMigrationto stop migration charges, then decommission the old EC2 nodes.
Caching is often one piece of a larger cloud migration and modernization plan, and moving off idle, oversized cache servers is a common quick win in our cost optimization and infrastructure management reviews.
Frequently Asked Questions
Is the migration really zero downtime?
AWS defines zero downtime as zero errors returned to the client during migration, measured like the ElastiCache SLA. Your application keeps reading and writing through cutover.
Can I migrate from Redis OSS to Valkey directly?
Yes. Self-managed Redis OSS 4.0 through 7.2 in cluster mode on EC2 can migrate straight to ElastiCache Serverless for Valkey, including Valkey 9.0.
How much does online migration cost?
Migration nodes are free for the first 180 days per AWS account. After that, they are billed per node-hour while a migration is active. The serverless cache is always billed at standard rates.
Can I migrate from an existing ElastiCache cluster or MemoryDB?
No. At launch, only self-managed caches on Amazon EC2 are supported as sources.
Need Help Planning Your Cache Migration?
Shanav Technologies helps startups and growing businesses modernize their AWS workloads without risky weekend cutovers. If you want help checking your Redis cluster against these requirements, or estimating what serverless Valkey would cost you, talk to our team and we will map out a safe migration plan.