Migrating from GemFire and Apache Geode to Valkey or Redis

If you run VMware Tanzu GemFire — or its open-source core, 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 50+ 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. VMware/Tanzu GemFire is Broadcom's closed-source product, forked from Apache Geode and distributed through an authenticated Broadcom Maven repository; Apache Geode is the Apache-2.0 core. 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 licensing and distribution model is a growing cost or friction: commercial GemFire is subscription-only and gated behind an authenticated Maven repository, while the open-source Spring for Apache Geode integrations are now in maintenance-only mode (CVE and critical fixes, no new features).
• You want async, reactive, and RxJava APIs, richer locks, and broad framework integrations that GemFire's client doesn't offer.

GemFire vs. Redisson at a Glance

For the complete table, see the feature comparison.

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.
• Broad framework integrations. Beyond Spring Cache and Spring Session (which GemFire also supports), Redisson integrates with Hibernate, 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

• Plan replacements for GemFire-specific features. A few GemFire capabilities don't map one-to-one: continuous queries and OQL (server-side query with pushed change events) and function execution (running code on the data nodes). If you use these, plan the replacement before cutover — for example, Redis keyspace notifications or RTopic for change events, RediSearch for querying, and Redisson's executor service or server-side scripting for compute. These are different mechanisms, not drop-in equivalents, so scope them early.
• 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.