Should a production network stay on Fabric 2.5 or move to 3.x?
A consortium or bank running or planning a Hyperledger Fabric network has to pick one line to standardize on, and the answer turns mainly on the ordering service. Fabric v2.5 is the long-term support release for production users, and it suits a network that runs Raft ordering, does not need Byzantine fault tolerant ordering and wants a stable baseline with patch releases. The current v2.5 patch line is v2.5.16, and the v3.1 line is maintained in parallel with v3.1.5, so staying on 2.5 does not mean the line stops receiving fixes. Confirm the support window for your own contracts with the vendor or DeployOpen before you commit.
Move to the 3.x line when one of two conditions holds. The first is a requirement for BFT ordering, which is available only from v3.0 onward and is built on SmartBFT, so a network that needs to tolerate Byzantine ordering nodes has no choice on the 2.x line. The second is a network that still runs Kafka ordering, because Kafka was removed in 3.x and must be migrated to Raft first. Solo is deprecated and meant for testing, so any Solo-based environment should be treated as a migration item too. Check your configtx.yaml and orderer configuration for these settings before you pick a target.
The decision turns on four things. First, the ordering fault model: what failures the consortium must survive and whether crash tolerance is enough. Second, whether Kafka or Solo is still in use anywhere in the topology. Third, the chaincode lifecycle state, because v3.0 removed the v1.x legacy lifecycle and every channel must already be on the v2.x lifecycle before the upgrade. Fourth, your upgrade capacity: the Fabric upgrade guide describes four steps (back up the ledger and MSPs, roll orderers, roll peers, then raise channel capability levels), and each needs a tested rollback and a change window across every organization. Client applications can move separately, since the Fabric Gateway client API works with both lines.
Which Fabric line fits each production scenario
This table maps common production situations to the Fabric line that suits them, with the condition that drives each choice. Read each row against your own ordering service, channel history and change calendar, since the right line usually turns on one fact such as whether you need BFT ordering or still run Kafka.
| Scenario | Better line | Condition that drives the choice |
|---|---|---|
| Raft network with no BFT requirement and no change freeze | v3.1 or v2.5, depending on upgrade timing | Raft is the recommended crash fault tolerant option in both lines. Choose v3.1 if you want the newer line and can complete the upgrade steps, or stay on v2.5 if you need a stable baseline first. |
| Network still on Kafka ordering | v2.5, then migrate to Raft before any 3.x upgrade | Kafka was deprecated in v2.x and v3.0 removed it. Migrate ordering to Raft on v2.5 first, then move to v3.x. Do not jump straight to 3.x. |
| Network that needs BFT ordering | v3.1 | The BFT ordering service based on SmartBFT arrived in v3.0, so networks that need Byzantine fault tolerance must run the 3.x line. |
| New build with no legacy channels | v3.1 | With no v1.x lifecycle or Kafka history to migrate, you avoid the pre-upgrade cleanup that v3.0 requires and can start on the current line. |
| Network with a long change freeze | v2.5 LTS | The Fabric documentation names v2.5 as the long-term support release for production users. A long freeze favors the LTS line, with patch releases in parallel, and an upgrade planned as a separate project. |
| Network still running Solo ordering | Move to Raft on either line | Solo is deprecated and meant for testing only. It is not a production option on v2.5 or v3.1, so the ordering migration is required regardless of line. |
| Client applications need to change independently of the network | Either line, with the Gateway client API | The Fabric Gateway client API is compatible with v2.5 and v3.0, so applications can be upgraded separately. Confirm compatibility against your exact SDK versions. |
How the ordering, peer and CA layers differ across the two lines
Fabric 2.5 and 3.x share most of their operating model, but the ordering service, MSP signing options and upgrade prerequisites differ in ways that change runbooks. The cards below cover each layer an operator touches and what to verify before choosing a line.
Ordering service: Raft and BFT
Raft is the crash fault tolerant ordering service the Fabric documentation recommends, and it is available on both lines. The BFT ordering service exists only in 3.x, where it is based on SmartBFT and tolerates failures of up to, but not including, one third of ordering nodes. Choosing BFT means committing to the 3.x line from day one, and you should confirm with your consortium whether the crash fault model is enough for your threat model.
Kafka and Solo orderers removed
The Kafka ordering service was deprecated in v2.x and is no longer supported in v3.x, and Solo is deprecated and intended only for testing. Fabric 3.0 removed both, so any network still on Kafka must migrate to Raft before upgrading. Inventory every channel's orderer type early, because this migration is the most likely blocker on an existing production network.
Peer binaries and rolling upgrades
Peer and orderer binaries are upgraded separately, one node at a time, following the four-step guide: back up the ledger and MSPs, upgrade orderers, upgrade peers, then raise channel capability levels. Peers keep their ledgers and channel membership through a rolling upgrade, but the capability level step is one-way, so test it on a non-production channel first. Confirm the peer image and chaincode lifecycle versions your channels already use.
MSP signing with Ed25519
Fabric 3.0 added Ed25519 alongside ECDSA for MSP signing. Existing identities and certificates continue to work, but new Ed25519 identities can only be used on networks where every participating peer, orderer and client library supports them. Before enabling it, check your HSM vendor and any external signing tools for Ed25519 support, because the Fabric documentation on hardware security modules is the place to confirm what your hardware accepts.
Fabric CA and user registry
Fabric CA issues enrollment certificates, handles renewal and revocation, and generates certificate revocation lists. It can use its internal identity registry or LDAP as the user registry. This layer behaves the same across the two lines for operators, but you should confirm the CA version you run against each Fabric line and test revocation and CRL distribution on your own network before any upgrade.
Operations service and Gateway client API
The operations service exposes health and metrics endpoints for peers and orderers, which monitoring stacks scrape during a rolling upgrade. The Fabric Gateway client API is compatible with both v2.5 and v3.0, so client applications can be upgraded separately from the network. Keep monitoring rules and client SDK versions in the same change plan, and check the operations endpoints after each binary swap.
Fabric 2.5 and 3.x compared on capabilities that drive the choice
This table compares the two maintained Fabric lines on the capabilities that decide an upgrade or new deployment. Read each row with its condition: a row matters only if your network needs that ordering mode, fault model, or client pattern. Confirm support windows for each line in the release notes before you commit.
| Capability | Fabric v2.5 (LTS) | Fabric v3.x (latest v3.1.5) |
|---|---|---|
| Maintenance status | Long-term support line for production users; latest patch v2.5.16 | Current line with patch releases in parallel; latest patch v3.1.5 |
| Raft ordering | Available and recommended for crash fault tolerant ordering | Available; the recommended ordering path for crash fault tolerance |
| BFT ordering (SmartBFT) | Not available | Available; matters only if you need Byzantine fault tolerance across ordering nodes |
| BFT fault tolerance limit | Not applicable | Tolerates failures of up to, but not including, one third of ordering nodes |
| Kafka and Solo ordering | Kafka deprecated; move to Raft before planning further upgrades | Kafka and Solo removed; Kafka ordering must be migrated to Raft before upgrading |
| Legacy v1.x chaincode lifecycle | Must be retired on all channels before moving to 3.x | Removed; all channels must use the v2.x lifecycle before upgrade |
| MSP signing algorithms | ECDSA | Ed25519 added alongside ECDSA; relevant if your CA and HSM policies allow it |
| Fabric Gateway client compatibility | Compatible with the client application in use | Compatible; client applications can be upgraded separately from the network |
What the Apache-2.0 license and two maintained lines mean in practice
Hyperledger Fabric is licensed under Apache-2.0, so the codebase can be used, modified and redistributed under the license terms. The license governs the software, not the networks you build with it. Fabric has no native cryptocurrency, so a Fabric network carries no token economics, and any value transfer is modeled in chaincode that your consortium designs and governs.
- Codebase rights: Apache-2.0 allows your organization to run, modify and redistribute Fabric within the license conditions, without a per-node license fee from the project.
- No native token: Fabric does not include a cryptocurrency, so you do not inherit token issuance, fees or wallet behavior from the platform.
- Chaincode ownership: The chaincode, channel configuration and data model your consortium writes are governed by agreements between members, not by the Fabric license.
- Governance: Fabric is hosted under LF Decentralized Trust, which lists it as a Graduated project. Confirm with the foundation how project governance and release decisions apply to your planning horizon.
- Patent and notice terms: Read the Apache-2.0 text and any notice files in the repository before redistributing modified binaries.
Ask your legal team to confirm how Apache-2.0 obligations apply to any modified Fabric distribution you ship to members.
The Fabric documentation states that v2.5 remains the long-term support release for production users. The latest v2.5 patch is v2.5.16, published June 17, 2026. If your network is in production and your priority is a stable line with predictable change, v2.5 is the line the project positions for that purpose. It is also the line you stay on if your ordering service is still Kafka, because Kafka ordering was deprecated in v2.x and removed in v3.x.
- Stability posture: v2.5 is the documented LTS line for production users, so change is typically limited to patches on that line.
- Current patch level: v2.5.16 (June 17, 2026) is the latest release on this line, per the Fabric GitHub releases.
- Kafka ordering: Networks still on Kafka can remain on v2.5, but the migration to Raft must be planned before any move to 3.x.
- No BFT ordering: The BFT ordering service arrived in v3.0, so v2.5 networks cannot use it.
- Lifecycle planning: Confirm with the project and your vendor how long v2.5 patches will be issued, since the project does not publish a single end date in the supplied facts.
Check whether your current ordering, MSP and chaincode lifecycle settings already meet the v2.5 documentation before you commit to staying on this line.
The 3.x line is where Fabric adds Byzantine fault tolerant ordering, Ed25519 for MSP signing and the removal of Solo, Kafka and the v1.x chaincode lifecycle. The latest v3.1 patch is v3.1.5, published June 18, 2026. A new network with a need for BFT ordering, or an existing v2.5 network that is prepared to migrate, should be planned against this line. Upgrades are run in place, with the documented steps applied to orderers and peers.
- BFT ordering: The SmartBFT-based ordering service is available only in 3.x, and it tolerates failures of up to, but not including, one third of ordering nodes.
- Ed25519 signing: v3.0 added Ed25519 alongside ECDSA for MSP signing. Confirm that your HSM and certificate tooling supports it before relying on it.
- Pre-upgrade prerequisites: Kafka ordering must be migrated to Raft and all channels moved to the v2.x lifecycle before the upgrade.
- Upgrade order: The documentation describes backing up the ledger and MSPs, upgrading orderers and peers in a rolling fashion, then updating channel capability levels.
- Client compatibility: The Fabric Gateway client API works with both v2.5 and v3.0, so applications can move separately from the network.
Run a test network on v3.1.5 with your real chaincode and MSP configuration before committing a production change window.
The Apache-2.0 license grants rights to the software. It does not include support, hosting, managed operations, certificate authority operations, or any guarantee about how your network performs. Those are costs you carry through an internal team, a vendor, a managed service or a combination of these. No paid Fabric edition appears in the supplied facts for this comparison, so any commercial support offer must be evaluated on its written terms.
- Vendor support tiers: Ask any vendor which support tiers they sell, response commitments, supported versions and whether patches for v2.5 and v3.1 are included.
- Hosting and operations: Peer, orderer and Fabric CA hosting, monitoring, backup storage and key handling are your responsibility unless a contract says otherwise.
- Managed services: Confirm which components a managed provider operates, who holds the signing keys, and how upgrades are scheduled.
- Chaincode and integration work: Development, testing and audit of chaincode and client applications sit outside the license.
- Compliance evidence: The license does not produce audit evidence. Ask providers what documentation they supply for your assessments.
Request a written scope from each provider that lists exactly what is included, excluded and billed separately before you select one.
What drives the running cost of each Fabric line
The running cost of a Fabric network is set less by the software license, which is Apache-2.0 for both lines, than by the nodes you operate, the people who maintain chaincode and the patch work that follows a release. Infrastructure is the most concrete component. A five-node Raft ordering cluster tolerates the loss of two nodes, so it is a common baseline for crash fault tolerance, but each orderer and each peer is a machine, a certificate set and a monitored process you pay for every month. If you choose the BFT ordering service that v3.0 introduced, the cost driver changes: the SmartBFT model needs enough ordering nodes to meet its fault tolerance target, which is a larger cluster than a crash-tolerant one for the same number of failures. Confirm the minimum node count for your fault model with the Fabric ordering service documentation before you size hardware.
The one-time costs sit in the migration. A Kafka-based network must move ordering to Raft, and every channel must be on the v2.x chaincode lifecycle before the 3.x upgrade, so the work includes rewriting orderer configuration, testing channel capability levels and rehearsing rollback. Staff time is the other large item: chaincode written in Go, Java or Node.js needs developers who understand endorsement policies and private data collections, while operators need to run the upgrade steps and the operations service without outages. Recurring costs follow from maintaining two supported lines. Because v2.5 is the long-term support line and v3.1 receives its own patch releases, every security update you adopt may need testing on both. Ask the provider to state the patch cadence it will cover and who performs each rebuild.
A quote is only comparable when its scope is written down. Ask for a statement that names node counts for orderers and peers in each environment, the number of upgrade rounds, the test plan for chaincode and client applications (the Gateway client API works with both lines, so these can be upgraded separately), the rollback procedure with its backup checkpoints, and the handover of runbooks and keys. Also ask whether support is a fixed-scope engagement or a retainer, what triggers additional work, and which party holds the Fabric CA and HSM responsibilities after go-live. DeployOpen does not publish a price list, so use these items to compare written proposals from any provider on equal terms.
How to plan the move to 3.x for a live network
This sequence takes a production Fabric network from the 2.5 line to 3.x in a controlled order, so every channel, orderer and peer is verified before the next component changes. Each step closes with a check you can record as evidence for your change record.
Confirm the current ordering service and lifecycle state
Before anything else, record which ordering service each channel uses and whether any channel still relies on the v1.x legacy chaincode lifecycle. Fabric v3.0 removed Solo and Kafka consensus and the legacy lifecycle, so a network still on Kafka ordering must move to Raft first, and any Solo orderer must be replaced because it is meant for testing only. The network operator and the channel administrators own this inventory, and the output is a signed list of orderers, channels and chaincode definitions. Do not proceed until every channel is on the v2.x lifecycle and every production orderer runs Raft.
Migrate Kafka ordering to Raft
If the inventory shows Kafka ordering, plan the Kafka-to-Raft migration as its own change, because the Kafka service is deprecated in v2.x and not supported in v3.x. Define the Raft consenter set, certificates and orderer endpoints, then rehearse the migration in a non-production copy of the network. The check is that the Raft cluster elects a leader, accepts transactions on every channel and that peers receive every block without gaps. Confirm the exact migration procedure against the current ordering service documentation for your release, since the steps depend on your deployment.
Back up the ledger and MSPs
Take a complete backup of ledger data on every peer and orderer, along with the MSP directories, TLS material, channel configuration blocks and the Fabric CA state if you run one. Store the backup offline or in a separate account, and restore a sample into an isolated environment to prove it is readable. The network operator and the security team should both sign off, and the output is a restore test record showing the backup opens and the channel heights match the source. Rollback depends on this step, so treat it as a gate.
Rehearse the full upgrade in a non-production environment
Build a non-production network with the same topology, channel definitions, chaincode versions and MSP structure as production, then run the four upgrade steps in the same order planned for production. Include the Fabric Gateway client applications, because the Gateway client API is compatible with both v2.5 and v3.0 and should be tested against the upgraded network. Record every deviation from the runbook, such as configuration keys that differ between releases, and feed each one back into the production plan. The output is a rehearsal report that the change board accepts.
Upgrade orderer binaries in a rolling fashion
Upgrade one orderer node at a time, confirm that it rejoins its Raft cluster and reaches the current block height, then move to the next node. Keep a majority of ordering nodes available throughout, because Raft keeps working only while a majority is up. Check the operations service endpoints and logs after each node. The output is a record that every orderer reports the 3.x binary version and that all channels continue to accept transactions.
Upgrade peer binaries in a rolling fashion
Upgrade peers organization by organization and one peer at a time, so that endorsement stays available for each chaincode. Verify after each peer that it catches up on blocks, that chaincode containers start and that endorsement requests succeed from client applications. The check is a clean block-sync status and successful test transactions on each channel before the next peer is touched. Coordinate with each member organization, since each one controls its own peers.
Update application channel capability levels
Only after all orderers and peers run the 3.x binaries, update the application channel capability levels, because enabling new capabilities too early can block older binaries from processing blocks. Make the change through a channel configuration update that each required organization signs, and confirm the new capability level is reflected in the channel configuration. Then retest the BFT ordering setup if you use it, since BFT ordering is available only in the 3.x line and needs its own consenter configuration and failure tests. Record the signed config update and the post-change test results as the close-out evidence.
Where Fabric upgrade and migration projects usually run long
The longest part of a Fabric upgrade is rarely the binary swap. Moving to the 3.x line means changing the ordering design first: any network still on Kafka ordering must move to Raft before the upgrade, and a network that needs Byzantine fault tolerant ordering must adopt the BFT service, which only exists in 3.x. Each choice reshapes the orderer set, the consenter configuration and the failure assumptions the operations team has been working with. Before fixing a plan, confirm which ordering service each channel uses today, and whether the team has run a BFT ordering cluster before, since the operating model is different from Raft.
Identity work is the second common source of delay. Check the MSP definitions, the Fabric CA configuration and the enrollment and revocation paths on every organization, and confirm that certificate renewal and CRL generation still behave as expected after the change. Chaincode is the third. Every channel must be on the v2.x chaincode lifecycle before the 3.x upgrade, so inventory each channel and each chaincode definition, and treat any channel still on the legacy lifecycle as a blocking item. Rehearse the full sequence in a staging network that mirrors your MSP layout, orderer count and channel list, and record the time each rolling step takes.
Consortium coordination is where timelines most often slip. Each member runs its own peers and controls its own change windows, so the orderer upgrades, peer upgrades and channel capability updates need an agreed order and a shared rollback position. Application clients can move separately, because the Fabric Gateway client API works with both v2.5 and v3.0, but that decoupling only helps if each application team has its own release schedule and test evidence. Ask each member for its change calendar, its staffing for the upgrade window and its backup of the ledger and MSPs before agreeing a date. Any timeline you commit to should follow from those answers and the staging results, not from the vendor documentation alone.
Questions buyers ask before choosing or upgrading Fabric
Is Hyperledger Fabric 2.5 still safe to run in production?
Yes, v2.5 is the line the Fabric documentation identifies as the long-term support release for production users, and it is still receiving patch releases, with v2.5.16 published on June 17, 2026. Staying on 2.5 is a valid choice if you do not need BFT ordering and your team can keep up with patches. The cost of staying is mostly ongoing: you apply each patch release across orderers and peers, and you plan the eventual move before support decisions force it. Confirm the support window for your own change process with the Fabric maintainers and your vendor before you commit to a multi-year plan.
Do I have to replace Kafka ordering before moving to Fabric 3.x?
Yes. Fabric v3.0 removed the Kafka and Solo consensus options, so a network still using Kafka ordering must migrate to Raft before it can upgrade to 3.x. Kafka ordering was deprecated in the v2.x line, and the Solo orderer is intended for testing only. The migration work is an ordering change that touches channel configuration, orderer identities and the operational runbooks your team uses, so it should be scoped and rehearsed as its own item. Ask any provider to list the channels, orderer nodes and MSP configurations that will change, and to show how they will test the cutover.
Does a consortium network need BFT ordering?
Only if your threat model includes ordering nodes that may behave maliciously, not just crash. Raft is the crash fault tolerant option the Fabric documentation recommends, and it keeps working while a majority of nodes are available. The BFT ordering service, based on SmartBFT, is new in v3.0 and tolerates failures of up to, but not including, one third of ordering nodes, so it requires the 3.x line. Consider the extra node count, the operational maturity you need and the governance agreements among members. Many consortia decide this with their legal and risk teams before any engineering starts.
How long does a Fabric upgrade take?
No duration is fixed by the documentation, so the honest answer depends on the size and number of your nodes, the number of channels, your change windows and how much testing you require. The Fabric upgrade guide breaks the work into four steps: back up the ledger and MSPs, upgrade orderer binaries in a rolling fashion, upgrade peer binaries in a rolling fashion, then update application channel capability levels. The largest variable is usually the prerequisite migration work (Kafka to Raft, legacy chaincode lifecycle), which can take longer than the binary upgrades. Ask for a schedule built from your own inventory and a rehearsal in a non-production network.
What does the upgrade need from our own team?
Your team needs ownership of the network, not just the application. Expect to supply people who can approve change windows, manage certificate authorities and MSPs, operate the orderers and peers, and verify that client applications still work. The Fabric Gateway client API is compatible with both v2.5 and v3.0, so application teams can often upgrade on a separate schedule from the network. Plan for the backup step to be verified by someone who can restore from it, and for the operations service to be monitored during rolling restarts. Agree on these roles before the work starts, because they determine what you can hand to an outside partner.
Can our own engineers do the Fabric migration without outside help?
They can, if they have operated Fabric in production before and the network is small enough to rehearse each step. Skills that matter include certificate authority administration (Fabric CA handles enrollment, renewal and revocation), MSP and channel configuration, chaincode lifecycle changes and rolling restarts. If your team has not run these before, the risk sits in the migration steps that are hard to reverse, such as ledger and MSP backups and channel capability changes. A fixed-scope engagement can cover planning, rehearsal, the cutover and documentation, while your staff keep operational control. Decide which of these you want to keep in house before you request proposals.
What should a quote for a Fabric upgrade include?
A useful quote lists the scope in writing before any work starts: which networks, channels, orderers, peers, CAs and client applications are in scope, and which are excluded. It should name the deliverables, such as an inventory, a migration plan, a tested rollback procedure, a rehearsal record, the production cutover and updated runbooks. It should separate one-time work from recurring work, such as patch application, monitoring and retained support, and state what triggers a change order. DeployOpen does not publish a price list; quotes follow from the written scope. Ask any provider how they will verify backups and what evidence you receive at the end.
How DeployOpen helps choose, plan and run a Fabric move
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Hyperledger Fabric, that means helping a team decide between the 2.5 and 3.x lines, then planning and carrying out the move on its own network.
How we scope
- Inventory current orderers, peers, channels and chaincode lifecycle status before any version decision is made.
- Confirm whether Kafka ordering must move to Raft and whether BFT ordering is a real requirement.
- Agree the scope, deliverables and timelines in writing before work starts, as most engagements are fixed-scope.
How we build
- Plan the four-step upgrade path: ledger and MSP backup, rolling orderer upgrade, rolling peer upgrade, then channel capability levels.
- Test the upgrade on a staging network that mirrors channel topology, MSPs and client applications before production.
- Check Fabric Gateway client applications for compatibility with both v2.5 and v3.0 so they can be upgraded separately.
How we hand over
- Deliver runbooks for backup, rolling upgrades, rollback and the decision record behind the chosen Fabric line.
- Document Fabric CA identity, enrollment, renewal and revocation procedures so operators can run them without the project team.
- Walk the client's operators through the cutover and the post-upgrade checks against their written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Track patch releases on both the v2.5 and v3.x lines so the network stays current on the line it runs.
- Re-plan the next upgrade step in writing when a new Fabric release changes the path for the client's network.
