Has anyone encountered breaking changes or disruptions when upgrading from Pulsar 4.x to 5.x?

[Rutuja-IBM]

We're currently evaluating an upgrade of our production environment from Apache Pulsar 4.x to 5.x and are trying to identify any potential risks before proceeding.

I'd like to hear from anyone who has already completed (or attempted) this upgrade.
Specifically, I'm interested in:

1. Did you encounter any breaking changes or unexpected disruptions during the upgrade?
2. Were there any deprecated or removed APIs/configurations that required code or configuration changes?
3. Did you face any issues with brokers, proxies, Functions, connectors, or metadata storage?
4. Were there any client compatibility issues (Java, Go, Python, Node.js, etc.) with existing applications?
5. Any surprises around Helm charts, broker configuration, or operational behavior?
6. Are there any lessons learned or recommendations you'd share for a smoother upgrade?

Any experiences, migration tips, or references to useful documentation would be greatly appreciated.
Thanks in advance!

[lMysticl]

The main constraint right now is that there is no production-ready Pulsar 5.x release to upgrade to yet.

5.0.0-M1 is the only 5.x release currently published. Pulsar labels it as a preview, says GA is expected later in 2026, and explicitly says M1 is not intended for production. The current production releases are still on the 4.x lines, so I would keep production there and use M1 only for a staging compatibility run.

The M1 notes do give a useful checklist for that run:

• custom broker plugins, interceptors, authentication/authorization providers, or other extensions using javax.* must move to jakarta.* and be recompiled;
• the Etcd metadata-store backend was removed, so Etcd deployments must migrate before 5.0;
• Pulsar IO connectors moved to a separate repository and release cycle;
• source builds moved from Maven to Gradle, although published Maven artifacts and Docker images remain available;
• the existing pulsar-client and pulsar-client-api are unchanged. The new pulsar-client-v5 is additive, so existing Java applications do not need to adopt the new API merely because the broker eventually moves to 5.0;
• ZooKeeper remains supported, while Oxia is recommended for new clusters.

For a production migration, I would inventory those items now, test M1 only in staging, and repeat the assessment against the 5.0 GA release notes when they are published. In particular, test your own Functions, connectors, broker extensions, Helm values, authentication providers, and a rolling broker/client compatibility matrix rather than treating M1 behavior as the final GA contract.

The current status and each of those breaking-change areas are listed in the official v5.0.0-M1 release notes.