Neo4j Upgrade & Migration Services

Neo4j 4.4 reached end of support on 30 November 2025. If it is still in production, it is unpatched and unsupported. GraphGuru plans and executes Neo4j upgrades — 4.4 to 5.26 LTS, 5.x to the 2025.x/2026.x calendar-versioned line, and self-managed to Aura — with rehearsed runbooks, tested rollback, and the application-side changes that are the real work of any migration.

The 2026 version landscape

Neo4j's release model changed in 2025, and the decisions an upgrade involves changed with it:

• Calendar versioning. Since January 2025 releases are named YYYY.MM.patch and ship monthly; the current line is 2026.0x. Support is rolling, so a team on the CalVer line upgrades several times a year, with no downtime on a cluster.
• 5.26 is the LTS. The last Neo4j 5 release is the long-term-support version, supported until June 2028. It is the right stopping point for estates that need a multi-year horizon.
• Cypher 25. From 2025.06 each database can run Cypher 5 (the compatibility dialect) or Cypher 25 (where new syntax lands and old deprecations are removed). Switching the default is a deliberate step, taken after your query corpus passes.
• Driver 6.x is current and required for the native Vector type.
• No direct 4.4 → 2025.x path. 4.4 estates migrate to 5.26 first; 5.26 → 2025.x is then a rolling upgrade.

Our post CalVer, Cypher 25, and GQL explains how to set a version policy; the 90-day migration plan is the schedule we run.

LTS strategy: which target is right for you

We start every engagement by recommending a target, in writing, based on four questions: how many applications consume the database and how actively they are developed; how often you can take a change window; whether you need Cypher 25 or GenAI features (vector type, neo4j-graphrag capabilities); and whether you will realistically patch monthly. The usual answer in 2026 is "land on 5.26, stabilise, then move to the CalVer line" — but the usual answer is not always yours.

Breaking-change audit

The database upgrade is the easy part. Our audit covers what breaks around it:

• Cypher deprecations and removals — exists(), USING PERIODIC COMMIT, pattern expressions, legacy index syntax, and everything else on the Cypher 25 removals list, found by replaying your logged query corpus on the target version.
• Indexes — BTREE indexes do not exist in 5.x; every one becomes RANGE, TEXT, or POINT, and we validate the plans that depended on them.
• Drivers and ORMs — 4.x drivers, Spring Data Neo4j, neo4j-ogm, and GraphQL libraries, each with its own major-version changes.
• APOC and GDS — APOC "full" split into APOC Extended; procedures that became native Cypher; GDS procedure signatures that changed between versions.
• Clustering — 4.4 causal clusters (cores/read replicas) map to 5.x Autonomous Clustering (primaries/secondaries) with new configuration and topology declarations.
• Operations — backup commands, configuration keys, metrics names, and security settings that moved.

Zero-downtime migration runbook

Every migration gets a runbook we rehearse at least twice on a full copy of production data before anyone touches the live cluster. It covers backup, store migration (neo4j-admin database migrate), index recreation, cluster bring-up, application cutover, and verification — with timings from rehearsal so the change window is a measurement, not a guess.

Rollback is designed in, not bolted on: the source cluster stays untouched and online until sign-off, cutover is a connection change, and where a write gap is unacceptable we capture the delta with the Kafka connector or an application journal. For 5.26 → CalVer and CalVer → CalVer, upgrades are rolling across the cluster with no downtime at all.

Aura lift-and-shift option

For many teams the right answer to "how do we upgrade?" is "stop operating the database." We migrate self-managed 4.4 and 5.x deployments to AuraDB, where version management is Neo4j's problem, and we size the instance, plan the data move, and handle the network, SSO, and driver-URI changes. We will also tell you when Aura is not the right fit — see our Aura & managed cloud page for the honest version of that conversation.

Post-upgrade health check

A migration is done when the new cluster is running well, not when it is running. Every upgrade engagement ends with our 2026 health check: query plans on the new planner, index usage, memory settings for the new version, cluster topology, backups restored from the new version, and a written report ordered by impact.

Engagement shape

Inventory and audit in the first two weeks; rehearsals and runbook in the next three to four; cutover on your change calendar; two weeks of stabilisation and the health check. Senior, US-based engineers, embedded with your team, remote or onsite. Fixed-scope pricing for single-application estates; time-and-materials where the inventory has to come first.

Still on 4.4, or on a 5.x that is not 5.26? Contact GraphGuru and we will tell you the fastest safe path off it.