Migrating Apache Ignite 2.x to Ignite 3: What Changes, What the Migration Tools Do, and When to Stay on 2.x

The short answer

Apache Ignite 3 is not an in-place upgrade from Ignite 2. The project describes it as a rework of the product from its core. Caches become tables, configuration moves from Spring XML to HOCON, every client is a thin client, and persistent data has to be converted because, in the words of the migration guide, Ignite 3 storage "is not directly compatible with Ignite 2". The same guide says code written for Ignite 2 cannot be directly reused.

Ignite 2 is not end of life. The project's documentation page labels Ignite 2 the "Long-term support (LTS) generation", currently 2.18.0, and tells existing Ignite 2 deployments to continue with the Ignite 2 documentation and turn to the migration guide when ready. New projects are pointed at Ignite 3. The project publishes no end-of-life date for either generation.

So the question is not whether 2.x is about to lose support upstream. It is whether, and when, a migration to 3 is worth what it costs for your workload.

Where the release lines stand on 5 October 2026

Dates come from the Ignite download page and release notes, collected on the Apache Ignite end-of-life tracker. One oddity: at the time of writing, the download page still shows 2.17.0 as the latest 2.x release, while the documentation and the release blog cover 2.18.0.

What changes in Ignite 3

The 3.x documentation has developer guides for the table API, SQL, transactions, compute, the data streamer, code deployment, events and the clients. It has no equivalent sections for the 2.x service grid, continuous queries, near caches or the machine learning module. Treat those as features you will need to replace or redesign, not port.

Two operational details catch teams out. Metrics are disabled by default in Ignite 3 and have to be enabled per source before they appear in JMX. Events are split into channels and sinks, and the only sink so far is the log.

Ignite 3 is tested on JDK 11, 17 and 21. On Linux it needs glibc 2.29 or newer and a C++ standard library with GLIBCXX_3.4.26, which rules out some older distributions that still run Ignite 2 happily.

What Apache provides for the migration

The project ships migration-tools-cli as part of the 3.1.0 release. It has three parts.

• Configuration converter. migration-tools configuration-converter source.xml node.conf cluster.conf turns an Ignite 2 XML file into Ignite 3 node and cluster configuration. The documentation lists the properties it converts: cacheConfiguration, clientConnectorConfiguration, communicationSpi, dataStorageConfiguration, discoverySpi and sslContextFactory. Anything else you configure is yours to translate.
• DDL generator. migration-tools sql-ddl-generator ignite-config.xml writes a CREATE TABLE script for each cache in the configuration. --allow-extra-fields stores fields of unsupported types in an extra JSON column, and --extra-lib adds the JARs that define your key and value classes.
• Persistent data migration. migration-tools persistent-data <work-dir> <consistent-id> <config> list-caches reads a stopped Ignite 2 node's work directory, and migrate-cache <cache> <ai3-urls> copies a cache into a running Ignite 3 cluster partition by partition. The --mode option decides what happens when a record does not fit the target table: ABORT (the default), IGNORE_COLUMN, SKIP_RECORD or PACK_EXTRA, which writes extra fields to JSON. --rate-limiter caps records per second, and a progress file lets a failed run resume.

Two limits matter. The persistent data route requires downtime: you stop the Ignite 2 node, let it finish a checkpoint, and read its files. And IGNORE_COLUMN and SKIP_RECORD lose data by design, so a run in one of those modes needs a row count and content check afterwards.

Nothing in the toolkit converts application code. There is no compatibility layer for the Ignite 2 cache, compute or services APIs.

SQL changes

Ignite 3 runs SQL on Apache Calcite. The migration guide's function comparison lists what needs attention:

• Renamed: DAY_OF_MONTH, DAY_OF_WEEK and DAY_OF_YEAR lose their underscores, ISNULL becomes NVL, RANDOM_UUID becomes RAND_UUID, and INSTR(a, b) becomes POSITION(b IN a).
• Replaced by CAST: FORMATDATETIME and PARSEDATETIME become CAST ... FORMAT.
• No equivalent yet: among others GROUP_CONCAT, STDDEV_POP, STDDEV_SAMP, VAR_POP, VAR_SAMP, LOG, CONVERT, CURRENT_TIME, the bitwise functions, ENCRYPT and DECRYPT.
• BOOLEAN accepts only true and false.

Our recommendation: switch the Ignite 2 cluster to the Calcite engine before the migration. Ignite 2.18 took the Calcite-based engine out of experimental status, so queries can be tested against Calcite behaviour while the data is still on Ignite 2.

Client changes

Every application changes its client. Ignite 3 clients connect over a socket to port 10800 by default, keep connections to the other listed nodes for failover, and route key-value requests to the node holding the primary partition. Clients exist for Java, .NET (with LINQ and ADO.NET support), C++ and Python, plus JDBC and ODBC drivers. A Java application that ran as an Ignite 2 thick client node needs the most work, since it loses near caches, topology events and anything else that relied on being a cluster member.

Compute jobs move to the new compute API and are deployed as deployment units before they run. Colocated execution and map-reduce tasks are still available.

A migration plan

1. Inventory caches, cache groups, affinity functions, query entities, SQL statements, compute tasks, services, continuous queries, near caches, listeners and every client type.
2. Decide the target per feature. Map each cache to a table and zone, and decide what replaces each feature that has no 3.x section.
3. Move Ignite 2 to Calcite and fix the queries that change.
4. Build the Ignite 3 cluster from converted configuration, then review storage profiles, zones and replica counts by hand.
5. Generate and review the DDL, and create the tables.
6. Port applications to the Ignite 3 table, SQL and compute APIs.
7. Move data. For persistent caches, stop each Ignite 2 node and run migrate-cache. For caches that are rebuilt from a system of record, reload them from the source instead.
8. Verify row counts and sample contents for every table, then switch traffic.

Rollback

There is no downgrade from Ignite 3 to Ignite 2. Data written to Ignite 3 after cut-over has to be copied back by your own tooling. Keep the Ignite 2 cluster, its work directories and its application builds until Ignite 3 has run through a full business cycle. Since the persistent migration reads from stopped Ignite 2 nodes, back up those work directories before you start.

Staying on Ignite 2

For many estates, staying on 2.x is a reasonable decision rather than a delay. The upstream project still ships 2.x feature releases and calls the line LTS. Ignite 2.18 added rolling upgrade commands to the control utility, data centre aware placement and a long list of SQL improvements. If you stay, plan for these points:

• Fixes come in new minor releases. Older 2.x lines such as 2.13 and 2.16 had a single release each, so staying current means moving minor versions, not applying patches.
• Java 11 from 2.17. Ignite 2.17 moved the sources to Java 11, so a cluster still on Java 8 has to move its JVM before it can take 2.17 or 2.18.
• Removed APIs. 2.17 removed deprecated authorization methods from the security context and the shared memory port setting on TcpCommunicationSpi. 2.18 removed the deprecated GridClient and SpiQuery, and deprecated DeploymentSPI and lazy SQL fields queries.
• Control utility. From 2.17, control.sh connects over the thin client protocol by default, and the binary REST connection is deprecated for removal.

When a cluster cannot move to 2.18 either, because of Java 8, a pinned dependency or a removed API, it needs fixes on the version it runs. OSSeva ships patched, signed Ignite 2.x builds for 2.8, 2.9, 2.13 and 2.16 with the API and storage format unchanged, delivered through Maven, Docker and tarballs. Assure adds a baseline topology and data region review, a discovery port exposure and authentication audit, an inventory of cache and compute API usage, a SOC 2 and HIPAA attestation package and an Ignite 3 migration assessment with an effort estimate. Operate adds 24/7 heap, off-heap and baseline topology monitoring, a 15-minute P1 response, a named senior Ignite engineer, checkpointing, WAL and rebalance tuning, and execution of a migration to Ignite 3 or another data grid. See Ignite 2.x extended support and Apache Ignite support. If you are weighing other grids, the Hazelcast IMDG 3 to 5 migration guide and GemFire and Geode support cover the alternatives OSSeva also supports.

Common questions

Is Apache Ignite 2 end of life?

No. The project labels Ignite 2 its long-term support generation and released 2.18.0 on 23 April 2026. It publishes no end-of-life date.

Can I upgrade Ignite 2 to Ignite 3 in place?

No. Storage is not compatible and Ignite 2 code cannot be reused directly. You build a new Ignite 3 cluster and move data into it, with the migration tools or by reloading it.

Does Ignite 3 have thick clients?

No. All Ignite 3 clients are thin. They do not join the cluster topology, hold data or run compute jobs.

Is moving from Ignite 3.0 to 3.1 an in-place upgrade?

No. The 3.1 guide says zone-based replication requires a new 3.1 cluster and an export and import with COPY INTO, with downtime.