Neo4j 4.4 reached end of support on 30 November 2025. If you are reading this in 2026 with a 4.4 cluster in production, you are running an unsupported database: no security patches, no bug fixes, no vendor support case if it falls over. A surprising number of estates are in exactly this position — 4.4 was a long-lived LTS, it was stable, and "we'll upgrade next quarter" compounded for three years.
This is the plan we run with clients in that position. Ninety days is realistic for a typical single-application deployment with a few hundred gigabytes; larger estates with many consumers take longer, but the sequence does not change.
The facts you are planning against
- 4.4: end of support 30 November 2025. Done.
- 5.26: the Neo4j 5 LTS release, supported until June 2028. The conservative target.
- 2025.01 onwards: calendar-versioned releases, monthly, rolling support. The current line is 2026.0x (2026.05 shipped 28 May 2026).
- Cypher 25: a second Cypher language version available from 2025.06 alongside Cypher 5. New features land there; Cypher 5 stays as the compatibility dialect.
- Drivers: the 6.x line is current and is required for the native Vector type.
References: Neo4j's upgrade and migration guide and endoflife.date/neo4j.
The decision: 5.26 LTS or straight to CalVer?
There is no supported direct path from 4.4 to 2025.x. You migrate 4.4 → 5.26 first. The only real decision is whether you stop there.
Stop at 5.26 LTS if: you have many downstream consumers you cannot re-test quickly, change windows are rare, or your organisation prefers a two-year support horizon per major step. You get until June 2028 to plan the next move.
Continue to 2025.x/2026.x if: you want Cypher 25, the native Vector type, and GenAI-related features; you can adopt a monthly (or at least quarterly) patch cadence; and your consuming applications are under active development. 5.26 → 2025.x is a rolling upgrade on a cluster, so doing it a few weeks after landing on 5.26 is a small increment, not a second project.
Our default recommendation in 2026: land on 5.26, stabilise for two to four weeks, then move to the CalVer line unless there is a specific reason not to. Being on LTS only helps if you would actually stay there for years.
Weeks 1–2: inventory
You cannot migrate what you have not listed.
- Databases and sizes:
SHOW DATABASES; store size per database from disk. - Applications and drivers: enable the query log with client information, run it for a week, and extract distinct user-agents. Every
neo4j-java/4.x,neo4j-python/4.x,neo4j-javascript/4.x, and every Spring Data Neo4j orneo4j-ogmversion is a line item. - Cypher surface: export distinct query texts from the log. This is your test corpus.
- Plugins: APOC (core vs. full — in 5.x "full" became the separate APOC Extended), GDS, any custom procedures. Each needs a version matched to 5.26.
- Indexes:
CALL db.indexes()in 4.4; everyBTREEindex will have to becomeRANGE,TEXT, orPOINT. - Integrations: Kafka connector, Spark connector, BI connector, backups, monitoring agents.
- Topology: 4.4 causal cluster (cores and read replicas) maps onto 5.x Autonomous Clustering (primaries and secondaries), with different configuration keys.
Weeks 3–5: Cypher and application sweep
Run the captured query corpus against a 5.26 instance loaded from a backup. The breakages we see most:
exists(n.prop)→n.prop IS NOT NULLUSING PERIODIC COMMIT→CALL { ... } IN TRANSACTIONS- Pattern expressions in
RETURN/WITH→EXISTS { },COUNT { } CREATE INDEX ON :Label(prop)→CREATE INDEX ... FOR (n:Label) ON (n.prop)- Removed APOC procedures that now have native equivalents, and
apoc.periodic.*semantics changes shortestPathand variable-length patterns with relationship-property predicates- Procedure signature changes in GDS (version-specific)
Upgrade drivers to 5.x (or straight to 6.x) in every application; 4.x drivers do connect to 5.x servers, but you will want the new transaction and routing APIs anyway, and 6.x is where you need to be for the CalVer line. Budget time for ORM upgrades — Spring Data Neo4j and neo4j-ogm majors change more than the raw driver does.
Weeks 4–6: infrastructure rehearsal
Build the 5.26 cluster to the target topology in a non-production environment and migrate a full copy of production data into it at least twice. The mechanics:
neo4j-admin database backup(4.4) of each database.- Restore on the 5.26 servers, then
neo4j-admin database migrate <name>to rewrite the store format. - Recreate indexes (
BTREE→RANGEetc.) and let them populate. - Bring up the cluster; confirm
SHOW DATABASESshows every database online on every allocated server.
Time the whole thing. That number is the floor of your production change window. If it is too long, the usual levers are parallel backups per database, faster disks on the migration host, and dropping indexes before migrate and recreating them after.
Rehearsal two is where you run the application test suites, performance-compare the top fifty queries (PROFILE both sides), and validate integrations end to end.
Weeks 7–8: hardening and rollback
Write the runbook — every command, every owner, every checkpoint. The rollback strategy is simple and must be tested: the 4.4 cluster stays up, untouched, until sign-off. Cutover is a DNS/connection-string change; rollback is reverting it. Because 4.4 cannot read a 5.x store, do not plan on "migrating back"; plan on re-pointing applications and accepting a replay of writes made during the window (capture them via the Kafka connector or an application-side journal if that is unacceptable).
Also in this block: monitoring dashboards for the new cluster, alerting on the new metric names, backup jobs on the new version, and security review (TLS, roles, SSO) since configuration keys changed.
Weeks 9–11: production cutover
- Freeze schema and application changes one week before.
- Announce the write freeze window to consumers.
- Execute the runbook; the rehearsal timing tells you when each checkpoint should land.
- Smoke test with real users on the application, not just with
cypher-shell. - Keep 4.4 running, read-only, for at least a week.
Weeks 12–13: stabilise, then decide on CalVer
Watch GC pauses, page cache hit ratio, and slow-query logs for two weeks. Then, if you chose to continue, the 5.26 → 2025.x (or 2026.x) move is a rolling upgrade of the cluster, one server at a time, with no store migration downtime. Switch the default Cypher language to 25 only after your query corpus has passed against it.
Common ways this slips
- Discovering a consumer nobody knew about in week 10. The query-log inventory prevents this; do not skip it.
- An ORM upgrade that turns into a rewrite. Scope it in week 3, not week 9.
- A GDS workflow whose procedures changed signature. Pin the GDS version early.
- Backups that were never restored. Rehearsal one finds this — better than the cutover night does.
Getting help
We have done this migration enough times to know where the time goes, and we can run it with your team or for it: inventory and Cypher sweep in the first two weeks, rehearsals and runbook next, cutover on your schedule. If your 4.4 estate is still in production, talk to us — or start with the Neo4j Upgrade & Migration Services overview.