Migrating from GemFire and Apache Geode to Valkey or Redis

If you run VMware Tanzu GemFire — or its open-source counterpart, Apache Geode — for distributed caching and data, and you're evaluating a move to Valkey or Redis, this guide walks the migration using Redisson as the Java client. Redisson turns Valkey or Redis into a full distributed-objects platform (RMap, RLock, RQueue, and 60+ more), so you get a broader, more familiar programming model than GemFire's Region-centric one — on infrastructure you very likely already run.

The move is worth understanding as an architecture and operations change. GemFire is a peer-to-peer in-memory data grid built around Regions (essentially distributed maps), operated as a cluster of locators and servers. The technology originated at GemStone Systems in 2002; its core was open-sourced and donated to the Apache Software Foundation as Apache Geode in 2015, and Broadcom's VMware Tanzu GemFire is the closed-source commercial product built on that lineage, distributed through an authenticated Broadcom repository. Redisson is a client to a Valkey or Redis server — no grid to stand up, and Redisson's community edition is Apache 2.0. For a full feature-by-feature breakdown, Redisson maintains a detailed comparison of Valkey & Redis vs. VMware Tanzu GemFire; this guide focuses on how to make the move.

Signs You're Ready to Move Off GemFire

• You use GemFire mainly as a distributed cache and data layer built on Regions — a model Redisson covers with a far wider set of distributed objects.
• You already run Valkey or Redis and would rather consolidate than operate a separate grid of locators and servers.
• You want to shed grid operations — locator/member topology, rebalancing, gfsh, cluster tuning.
• The Broadcom distribution model is a growing source of friction. Commercial GemFire is subscription-only and its artifacts sit behind an authenticated Broadcom repository, which every developer machine and CI runner needs credentialed access to build against. That gate tightened in January 2026, when legacy per-product download tokens were retired in favour of a centralized Registry Token generated from the Broadcom Support Portal.
• You want async, reactive, and RxJava APIs, richer locks, and broad framework integrations beyond the Spring ecosystem.

GemFire vs. Redisson at a Glance

For the complete table, see the feature comparison.

What GemFire Does That Redisson Doesn't

Worth stating plainly before the migration steps, because it determines whether this move is right for you at all. A few GemFire capabilities have no direct Redisson equivalent:

• Function execution — you send Java code to run on the members that hold the data, avoiding the round trips of a get-modify-put cycle. Redisson's executor service runs tasks on Redisson worker nodes, which is task distribution, not compute colocated with the data.
• OQL and continuous queries — server-side querying over Regions, with change events pushed to subscribed clients. Redis keyspace notifications, RTopic, and RediSearch cover parts of this, but they're different mechanisms rather than drop-in replacements.
• Embedded, in-JVM data — GemFire can hold data in the same process as your code, removing the network hop entirely for some workloads.

If those are central to your system, GemFire is doing something Redisson isn't built to do, and you should keep it — at least for those parts. The rest of this guide is for the common case where GemFire is your distributed cache, data structure, and coordination layer, and a client to Valkey or Redis is the simpler operational fit.

What Redisson Gives You Over GemFire

The core reason to move is breadth. GemFire centers on the Region — a distributed map — and expects you to build higher-level structures and coordination on top of it. Redisson gives you those structures as first-class distributed objects: maps (with per-entry TTL and near cache), sets, lists, queues and deques, blocking and reliable queues, sorted sets, and multimaps, each implementing the familiar java.util and java.util.concurrent interfaces.

It also closes gaps GemFire leaves to you:

• Locks and synchronizers. Where GemFire offers a basic DistributedLockService and transactions, Redisson provides a full lock family — reentrant RLock with a watchdog, RFencedLock with a fencing token, plus fair, read/write, semaphore, and latch variants.
• Async, reactive, and RxJava APIs. Every Redisson object has synchronous, asynchronous, Reactive, and RxJava3 variants; GemFire's client API is largely synchronous.
• Framework integrations beyond caching and sessions. GemFire covers Spring well — Cache, Session, Data, and Boot — and ships HTTP session modules for Tomcat and app servers. What it doesn't reach is the rest of the Java data layer. Redisson adds Hibernate second-level cache, JCache (JSR-107) including near-cache, MyBatis, Quarkus, and Micronaut — plus, in Redisson PRO, a JMS and Jakarta Messaging provider (JMS 2.0, 3.0, and 3.1).
• Distributed services — an executor service, scheduler, MapReduce, remote-invocation service, and Live Objects.
• Managed-cloud simplicity. Redisson connects to managed Valkey/Redis (AWS ElastiCache and MemoryDB, Azure Cache, Google Cloud Memorystore) with no cluster to operate.

Compatibility

Redisson connects to Redis 3.0+ and Valkey 7.2.5+, via the redis://, rediss://, valkey://, and valkeys:// schemes, including the managed services above. Where GemFire is infrastructure you stand up and run, Redisson points at a Valkey or Redis endpoint — often one you already operate.

Two Ways to Bring in Redisson

Many GemFire applications reach it through Spring, which gives you a low-friction path alongside the native one.

Which Path?

Path A (swap the Spring backing) fits when you use GemFire through Spring Cache or Spring Session and want to change configuration, not call sites. Path B (native objects) fits when you access Regions directly and want Redisson's full object model. They combine — swap the Spring provider now, adopt native objects where you need them.

Path A — Swap the Spring Provider

If you cache with @Cacheable, GemFire is wired in as a Spring cache manager. Swap that manager for Redisson's, and your annotations don't change:

// GemFire — Spring Cache backed by GemFire regions (Spring Data for GemFire)
@Bean
GemfireCacheManager cacheManager(GemFireCache gemfireCache) {
    GemfireCacheManager manager = new GemfireCacheManager();
    manager.setCache(gemfireCache);
    return manager;
}

// Redisson — Spring Cache backed by Valkey/Redis
@Bean
CacheManager cacheManager(RedissonClient redisson) {
    return new RedissonSpringCacheManager(redisson);
}

Spring Session works the same way — replace the GemFire session store with Redisson's, which the Spring integration auto-configures:

// GemFire
@EnableGemFireHttpSession
class SessionConfig { }

// Redisson (Spring Session backed by Valkey/Redis)
@EnableRedisHttpSession
class SessionConfig { }

Add the redisson-spring-boot-starter, and see the Spring Cache docs for per-cache TTL and other options.

Path B — Native Objects

A GemFire ClientCache becomes a RedissonClient, and a Region becomes an RMap.

Connection:

// GemFire — connect to the cluster via a locator
ClientCache cache = new ClientCacheFactory()
        .addPoolLocator("127.0.0.1", 10334)
        .create();

// Redisson — a client to the Valkey/Redis you already run
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
RedissonClient redisson = Redisson.create(config);

Region → RMap:

// GemFire
Region<String, String> region = cache
        .<String, String>createClientRegionFactory(ClientRegionShortcut.PROXY)
        .create("products");
region.put("1", "Widget");
String value = region.get("1");

// Redisson — RMap implements java.util.concurrent.ConcurrentMap
RMap<String, String> map = redisson.getMap("products");
map.put("1", "Widget");
String value = map.get("1");

Near cache (GemFire CACHING_PROXY) → RLocalCachedMap:

// GemFire — client-side caching region
Region<String, String> region = cache
        .<String, String>createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
        .create("products");

// Redisson — local reads with cluster-wide invalidation
LocalCachedMapOptions<String, String> options = LocalCachedMapOptions.<String, String>defaults()
        .cacheSize(1000)
        .syncStrategy(LocalCachedMapOptions.SyncStrategy.INVALIDATE);
RLocalCachedMap<String, String> localMap = redisson.getLocalCachedMap("products", options);

Per-entry TTL → RMapCache:

// GemFire — expiration is a region attribute (set on a locally-cached region)
cache.<String, String>createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
        .setEntryTimeToLive(new ExpirationAttributes(600))   // 600s, applies to the region
        .create("products");

// Redisson — per-entry TTL (and max-idle)
RMapCache<String, String> mapCache = redisson.getMapCache("products");
mapCache.put("1", "Widget", 10, TimeUnit.MINUTES);

From here, the rest of Redisson's objects — locks, counters, queues, topics — are available on the same redisson client, giving you more than the Region model exposed.

Technical Considerations and Implementation Pitfalls

• Scope the GemFire-specific features early. Continuous queries, OQL, and function execution have no one-to-one mapping, as covered above. Plan their replacement — Redis keyspace notifications or RTopic for change events, RediSearch for querying, Redisson's executor service or server-side scripting for compute — before you commit to a cutover date.
• Serialization changes. GemFire uses PDX; Redisson uses a configurable codec (Kryo/JSON/etc.). Types you cache must serialize under the codec you choose.
• Embedded/grid → client mindset. GemFire can hold data close to compute; with Redisson every operation is a call to the Valkey/Redis server. RLocalCachedMap restores local-read speed for hot keys, but assume a network hop by default.
• Data migration isn't automatic. There's no in-place grid-to-Redis transfer; plan a dual-write or replay, or treat the cache as cold-fillable on cutover.
• Single object placement in a cluster. By default a Redisson object lives on one master; spreading one large structure across cluster nodes (data partitioning) is a Redisson PRO feature.

Community vs. PRO

Redisson's community edition is Apache 2.0 and covers this whole migration: the full object suite, near cache (RLocalCachedMap), RMapCache, the lock family including RFencedLock, pub/sub, the executor service, and the Spring Cache and Spring Session integrations — with TLS (rediss:///valkeys://) and password/ACL auth included, since those are the Valkey/Redis server's job. Redisson PRO adds data partitioning across cluster nodes, an ultra-fast engine, extra local-cache implementations, reliable messaging (Reliable Queue and Reliable PubSub) with a JMS provider, advanced Spring integration, advanced data structures, and enterprise support. On the GemFire side, Apache Geode is Apache 2.0 while VMware/Tanzu GemFire is a commercial Broadcom product — the full comparison covers the PRO-level feature differences in detail.

Frequently Asked Questions

Is Redisson a Drop-In Replacement for GemFire?

For distributed caching and data structures, it's a broader superset — the Region model maps to RMap/RMapCache, and you gain the wider object suite, richer locks, and async/reactive APIs. Continuous queries, OQL, and function execution need a planned replacement rather than a direct swap.

Do I Still Need to Run a Cluster?

Not a GemFire one. You run Valkey or Redis (single node, cluster, sentinel, or a managed service) and Redisson connects as a client.

Can I Keep My Spring Code?

Largely yes. If you use GemFire through Spring Cache or Spring Session, you swap the cache/session manager to Redisson and your @Cacheable/session code is unchanged.

Does the Same Case Apply to Apache Geode?

Partly, and it's worth being precise. The Broadcom distribution and licensing friction above applies to commercial GemFire, not to Geode, which is Apache 2.0 and openly available. Geode also came out of a difficult period in better shape than many expected: after development stalled and the project management committee voted to terminate it in 2024, contributors revived it, and Geode 2.0 was tagged in December 2025 and announced by the ASF in January 2026, with a Java 17 baseline, a Jakarta EE 10 migration, and security work including Java Module System compliance. It is a real modernization, though one carried by a small volunteer community rather than a funded engineering team.

So if you're on open-source Geode, the reason to consider Valkey or Redis isn't licensing — it's the same architectural question as with GemFire: whether you need a data grid at all, or whether a client to a server you already run covers what you're actually using it for.