Hyperledger Besu vs GoQuorum: which to choose

Choose Besu over GoQuorum when your network needs a maintained successor, and plan privacy differently

If your network runs on GoQuorum, the repository is archived and Consensys does not recommend it for new projects. The last release, v24.4.1, was published on June 12, 2024, so there will be no upstream fixes for the software you depend on. Besu is the maintained option to evaluate, but only if your network can run on QBFT, which GoQuorum and Besu share, and only if you accept that Besu has dropped the features that made GoQuorum's privacy model work. Besu removed the Tessera privacy feature and onchain permissioning in 25.6.0, so GoQuorum-style private transactions are not available out of the box. Treat that as a design change, not a configuration toggle.

Three decisions should come first. The first is whether private transactions must stay. If they must, you will need to design a replacement for Tessera-based private state and confirm with your privacy and legal owners that the replacement meets your requirements, because Besu does not offer a drop-in equivalent. The second is whether permissioning moves to local configuration. Besu's node permissioning and account permissioning are defined in a permissions configuration file on each node, so every change to who can connect or transact must be made and tracked on every node rather than on the chain. The third is whether your team can absorb a migration. Confirm the JDK version Besu requires for your target release, the consensus configuration you will carry over, and how you will roll back, since the Besu 26.10.0 release notes say upgraded Bonsai databases cannot be opened by older versions.

Write the answers down before you request a quote. A scope that states which privacy behavior must survive, how permissioning will be administered, and how each node will be backed up before upgrade gives a fixed-scope implementation partner something to price and test against. Read the Besu documentation on permissioning and the release notes for each version you plan to run, and confirm details that the research did not cover, such as how your existing GoQuorum private contracts would be migrated or retired, in a proof of concept on a copy of your network.

Which platform fits which network scenario

This table maps common network situations to the platform that fits better, with the condition that drives each choice. Read it against your current GoQuorum feature use: the deciding factor is usually whether your network depends on Tessera-based private transactions or private contracts, which Besu no longer offers.

Scenario	Better fit	Driving condition
Existing GoQuorum network with no private transactions	Besu, planned migration	Public state only and QBFT consensus map to Besu. Confirm your node and account permissioning setup, since GoQuorum's permissioning does not carry over unchanged.
Existing network that depends on Tessera private contracts	GoQuorum stays for now, with a migration plan	Besu removed Tessera privacy in 25.6.0, so private contracts have no direct Besu equivalent. Any move requires redesigning how private data is handled and tested end to end.
New QBFT consortium on private infrastructure	Besu	Besu supports QBFT and recommends it as the enterprise-grade option. GoQuorum is no longer actively maintained and Consensys does not recommend it for new projects.
Network that needs Raft or Istanbul BFT	Neither platform maps directly; re-evaluate the consensus choice	Besu's private network consensus options are QBFT and IBFT 2.0. Raft and Istanbul BFT do not map to Besu, so a Raft or Istanbul BFT network needs a consensus decision before any migration.
Network that depends on Clique proof of authority	Neither as-is; move to QBFT or IBFT 2.0	Besu 26.4.0 removed Clique, so Besu cannot start or produce blocks on pure Clique networks. Plan a consensus change as part of any move.
Team that wants public-network interoperability	Besu	Besu is an Ethereum execution client for public networks such as Ethereum Mainnet, but it must be paired with a consensus client. Confirm the pairing and operating model your team will support.
Network with strict need for vendor-maintained releases	Besu, with a documented upgrade process	GoQuorum's last release was v24.4.1 (June 12, 2024). Besu ships roughly monthly and requires JDK 25, so budget for regular upgrade work and rollback backups.

How Besu and GoQuorum are built and what that means for operations

GoQuorum and Besu both run Ethereum-style nodes, but they come from different codebases and carry different operational duties. The cards below cover the architecture, build and upgrade requirements, and monitoring tasks that a team moving a network should check before it commits to a migration plan.

GoQuorum as a go-ethereum fork

GoQuorum is a fork of go-ethereum that follows upstream go-ethereum releases, and its privacy comes from separating public and private state on each node. Private contracts and transactions are handled by the Tessera private transaction manager, which moves encrypted private data between peers. Operators running GoQuorum today must keep Tessera alongside each node. Confirm which go-ethereum base version your current build tracks, since the repository is archived and no longer receives fixes.

Besu as a Java execution client

Besu is an Apache-2.0 Ethereum client written in Java, and it has no Tessera dependency because the Tessera privacy feature was removed in 25.6.0. A private network on Besu uses QBFT proof of authority, which the Besu consensus documentation recommends for enterprise use. Private data handling must be redesigned, since Besu does not offer GoQuorum-style private transactions out of the box. Map every private contract in your network to a replacement design before you plan cutover.

Java 25 build and runtime requirement

Besu 26.6.0 requires JDK 25 to build and run, so build pipelines, base container images and host runtimes built for GoQuorum's Go toolchain will not carry over. Teams should add a JDK 25 build stage to their image pipeline and validate it in a non-production network first. Ask your platform team whether JDK 25 is already approved under internal patch and runtime standards, because that approval can take longer than the migration itself.

Bonsai auto-upgrade and rollback

Besu 26.10.0 upgrades the Bonsai database automatically on first start, and older Besu versions cannot open an upgraded database. Rolling back therefore depends entirely on a backup taken before the upgrade, so the pre-upgrade backup is the rollback plan. Test restoring that backup on a copy of a node, and document the restore steps in the runbook before any node in a shared network is upgraded.

Node permissioning files

Besu applies local permissioning through a permissions configuration file on each node, covering node permissioning (which peers may connect) and account permissioning (onboarding, suspension and restricted actions). Unlike GoQuorum's peer-level permissioning, these files are maintained per node, so changes must be rolled out to every participant consistently. Set a change process for updating these files and record who approves each change.

Monitoring and API authentication

Besu exposes metrics that operations teams can scrape and alert on, and its JSON-RPC API can be configured to require authentication. Replace any GoQuorum dashboards and alerts that depended on Tessera or private state endpoints, and confirm that authenticated access is enforced on every node exposed to participants. Ask your team to verify which metrics and alert thresholds carry over, because the metric names are not identical between the two codebases.

What Besu removed and what replaces it

Besu removed several features that GoQuorum networks often depend on, and the dates matter for planning. Tessera privacy and onchain (smart-contract-based) permissioning were removed in Besu 25.6.0, released June 4, 2025. The EEA and PRIV privacy RPC API groups followed in Besu 25.7.0. Clique proof of authority was removed in Besu 26.4.0, released April 22, 2026, so a pure Clique network can no longer start or produce blocks on Besu. A team still on any of these features cannot treat Besu as a drop-in replacement for its current GoQuorum setup. Start by listing every privacy call, permissioning contract and consensus setting the network uses, then check each one against those release notes.

Permissioning does not disappear in Besu, but it moves from contracts to configuration. Besu's local permissioning uses a permissions configuration file on each node. Node permissioning restricts connections to known participants, and account permissioning covers onboarding rules, suspending accounts and restricting actions. Operators who used GoQuorum's onchain rules must decide who maintains these files, how changes are approved and distributed to every node, and how they are audited. The Besu permissioning documentation describes the file model. Confirm with your own change-control process that a node-local model meets the governance your consortium expects.

Besu does not offer GoQuorum-style private transactions out of the box. With Tessera and the EEA and PRIV APIs gone, there is no built-in way to send encrypted payloads visible only to selected parties inside a contract. Any private-data requirement needs a separate design, such as an off-chain data exchange, a commitment pattern on chain, or a different platform altogether. Treat this as an architecture decision, not a configuration change. Before any migration plan is approved, document what each application actually reads and writes, which data must stay confidential, and which parties must see it. Confirm the chosen approach with your application owners and legal or compliance reviewers.

Side-by-side capability comparison for GoQuorum and Besu

This table sets GoQuorum, the archived LGPL-3.0 client, against Hyperledger Besu, the Apache-2.0 client, on the capabilities that decide whether a network can move. Read the rows on consensus, privacy and permissioning first, because those are where Besu removed features that GoQuorum networks may depend on.

Capability	GoQuorum	Hyperledger Besu
License	LGPL-3.0	Apache-2.0
Maintenance status	Archived; Consensys does not recommend it for new projects. Last release v24.4.1 (June 12, 2024)	Actively released under LF Decentralized Trust; latest release 26.10.0 (October 16, 2026)
Consensus protocols	QBFT, Istanbul BFT, Clique proof of authority and Raft	QBFT and IBFT 2.0 for private networks; Clique and Ethash no longer supported
Privacy model	Private transactions and contracts through Tessera, with public and private state separation	No built-in private transactions; Tessera and onchain permissioning were removed in 25.6.0
Permissioning	Node and peer permissioning so only known parties can join	Local node permissioning (connections to known participants) and account permissioning (onboarding, suspension, action rules)
External vault support	Account plugins for external vaults	Confirm with the Besu documentation whether your key management pattern is supported before planning migration
Docker image source	Published under the quorumengineering Docker Hub account	Confirm the current official image location in the Besu documentation and release notes
Release cadence	No further releases expected from an archived repository; last release June 2024	Calendar versioning with roughly monthly releases; Bonsai database upgrades on first start, so back up before upgrading

Licensing and what each project costs to use

GoQuorum is licensed under LGPL-3.0, so the software carries no license fee. Its repository is archived for historical reference, and Consensys does not recommend it for new projects. The last release, v24.4.1, was published on June 12, 2024, so a network running it depends on code that its maintainer no longer updates.

License obligations: LGPL-3.0 allows use without a fee, but it adds conditions if you modify the library and distribute it. Have counsel review any changes before they ship.
No further releases: No fixes or security updates from the maintainer are expected after June 12, 2024. Patching, dependency tracking and vulnerability review become your responsibility.
Vendor support: Consensys states that it no longer actively maintains or supports GoQuorum, so vendor support is not a dependable route for an archived product.
Recurring spend: Ongoing cost is infrastructure, internal staff time and any external engineering you retain, not software renewals.

Confirm whether your node software, Docker images and build dependencies still come from the archived repository or from images you control before you budget for operations.

What drives running cost on a Besu network

Running a Besu network costs more in people and discipline than in software licensing, since Besu itself is Apache-2.0. The cards below cover the recurring and one-time items that move the total, and what to put in writing when you request a quote from any implementation partner.

Node count and hosting

Every validator and RPC node is a Java process with its own disk, memory and network footprint, so the node count sets most of the infrastructure bill. A GoQuorum network that is sized for Clique or Raft may need a different topology once it runs QBFT on Besu. Ask for the planned validator count, the number of RPC nodes, and whether each node runs in a separate failure domain in your own cloud account or data center. These are recurring costs.

Storage growth under Bonsai

The Bonsai database is the default state storage you should plan for, and it grows with chain state over time. The 26.10.0 release notes say it auto-upgrades on first start, so disk planning must include the headroom for that migration as well as steady growth. Ask the vendor or partner to model state growth for your transaction volume and to confirm retention for historical data. Storage is recurring, and migration headroom is one-time.

Monitoring and alerting

Besu exposes metrics that your team must scrape, store, dashboard and alert on, and a permissioned network with regulated counterparties usually needs documented uptime evidence. The metrics documentation is the starting point for deciding which signals feed your existing stack. Budget for the time to build alerts on peer count, block production and sync state, and for the observability tooling itself. Setup is one-time, and tuning and alert review recur.

Java and JDK 25 operations

Besu requires JDK 25 to build and run, according to the 26.6.0 release notes. GoQuorum teams often run Go binaries and have no JVM on hand, so the platform engineers who patch and tune the nodes may need new skills. Confirm who owns JVM heap sizing, garbage collection tuning and runtime patching in your organization. Training is one-time, and ongoing patching is recurring.

Monthly upgrade cadence

Besu ships on a calendar version scheme and releases roughly monthly, so an upgrade process that once suited a slower GoQuorum cycle will need a standing rhythm. Each release needs a test on a non-production network, a review of release notes for removed features, and a scheduled rollout. Ask whether your partner's retainer covers upgrades, how many releases it includes, and who signs off on production changes. Upgrade work recurs for the life of the network.

Pre-upgrade backup discipline

Because an upgraded Bonsai database cannot be opened by older Besu versions, rollback depends on a backup taken before the upgrade. Plan for backups of every node's data on a fixed schedule, plus a tested restore procedure and a named owner for the decision to roll back. The backup storage and the restore drills are recurring costs, and the first documented restore test is a one-time cost. Ask for evidence that restores have been exercised, not only that backups run.

Support and retainer scope

Besu is open source, so support comes from the internal team, a partner, or a paid arrangement with a vendor, and the choice drives the recurring bill. DeployOpen runs most engagements on a fixed written scope and offers ongoing support, upgrades and testing as retainers, but it does not publish prices. Ask any provider to state in writing which releases, incidents, backups and testing are covered, and what happens when a monthly release breaks a deployment.

How to move a GoQuorum network to Besu, step by step

This sequence turns a GoQuorum network into a Besu QBFT network with its chain state and compatible contracts carried over, while privacy and permissioning are rebuilt on Besu's own terms. Each step ends with a written output the consortium can review before the next one starts.

Inventory contracts, private state and dependencies
Start by listing every deployed contract, every private contract and the participants who hold each private state. Record which GoQuorum features the network depends on: Tessera private transaction manager instances, node and peer permissioning files, account plugins for external vaults, and any RPC API groups that applications call. Besu no longer offers Tessera privacy or onchain permissioning, and the EEA and PRIV privacy RPC groups were removed in 25.7.0, so every item on this list is marked as carried over, rebuilt or retired. The step is done when the consortium signs off one inventory that application owners and the security team have both reviewed.
Decide how private data is preserved
For each private contract, decide whether its data must survive the move, can be re-issued from source records, or can be retired. Work this out with the data owners and the legal or compliance lead, because Besu does not provide Tessera-style private transactions out of the box. Options that teams typically evaluate include keeping private data in an application layer under the consortium's own controls, or re-deploying private logic in a different design. Confirm each option with your own counsel and architecture review, since the choice affects audit evidence and retention obligations. The output is a written decision record per private contract.
Stand up a Besu QBFT test network
Build a separate test network on Besu for private networks, using QBFT as the consensus protocol, since Besu recommends QBFT as the enterprise-grade option. Install a Besu release that requires JDK 25 to build and run, and configure a genesis file with the validator set that matches the production plan. Replace the GoQuorum node permissioning files with Besu local permissioning, where each node holds a permissions configuration file that restricts connections to known participants, and set account permissioning rules to match the consortium's onboarding policy. Confirm the network reaches consensus and produces blocks before moving on. Done means a documented test network that every participant can join.
Validate contract behavior and state migration
Deploy the public contracts to the test network and compare their behavior against GoQuorum using the same transaction set, including edge cases and gas-sensitive paths. Confirm that contract code relying on GoQuorum-specific behavior or private state reads still works, and check every private contract separately, since those are the ones Besu cannot replay without the privacy design you chose in step two. Test the state migration by exporting balances and storage from GoQuorum, loading them into a staging environment and comparing results with an independent check. The step closes when the team has a reconciliation report showing matching results and a list of any contracts that need redesign.
Plan the cutover with fresh backups
Write a cutover runbook that sets the order of node shutdowns, the freeze point for transactions on GoQuorum, the state export, the Besu start and the application endpoint changes. Take fresh backups of every GoQuorum node and every Tessera instance before the freeze, and store them where a rollback can reach them. Note that the Besu 26.10.0 release notes state the Bonsai database auto-upgrades on first start and that older Besu versions cannot open an upgraded database, so a backup taken before the first Besu start is the only rollback path. Confirm the rollback steps in a rehearsal on the test network. The output is a signed runbook with a named go or no-go owner.
Run the cutover and verify the new network
Freeze transactions on GoQuorum, export the agreed state, start the Besu nodes on the QBFT configuration and confirm that every validator joins and produces blocks. Check that the permissioning rules admit only the known participants and that application traffic reaches the new endpoints. Record block heights, state roots and the results of the reconciliation tests from the rehearsal against the live network. The step is done when the business owners confirm that transactions run as expected and the team has a written cutover log with timestamps and results.
Decommission GoQuorum nodes after a retention period
Keep GoQuorum nodes, Tessera instances and their backups in read-only form for a retention period set by your records policy and your regulator's expectations, since the move does not remove obligations to retain historical records. Confirm the retention period with your compliance lead and external auditor, because the period is not set by this guide. Revoke GoQuorum keys and peer credentials, remove the nodes from monitoring and document the decommissioning in the change record. The step is complete when the consortium signs a decommission record and the retained archive has been tested for restore.

Where Besu migration projects usually run long

The longest part of a GoQuorum to Besu move is rarely the node swap. Most of the effort sits in redesigning private data flows and re-expressing permissioning. GoQuorum carried private transactions and private contracts through the Tessera private transaction manager, and Besu 25.6.0 removed Tessera and onchain permissioning. Every application that relied on private state, and every rule that lived in a permissioning contract, has to be mapped to a new design before the network can go live. That design choice is the one to settle first: decide which data still needs confidentiality, where it will be held, and how each participant's permissions will be expressed in Besu's local node and account permissioning files, since those files are configured per node and must agree across the consortium.

Testing against real application traffic usually takes longer than teams expect. Synthetic load tests do not show whether a contract call that depended on a private transaction path still behaves the same way, or whether an integration that read onchain permissioning state now fails. Build a test network that mirrors your consortium topology, replay production-shaped transactions, and check the JSON-RPC consumers, monitoring and key handling end to end. Confirm with your Besu release team which version you will target, since Besu releases roughly monthly and the 26.10.0 release is current as of its October 16, 2026 date. Consortium cutover is the other constraint. Every member must agree on one date, and a single laggard holds the whole network at the old version, so agree the cutover plan, the freeze window and the communication path in writing before anyone touches a node.

Rollback needs planning because the database upgrade is one-way. The Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older Besu versions cannot open an upgraded database. Take and verify a backup of each node's data before the upgrade, and rehearse restoring it on the test network. DeployOpen can plan the migration, implement the node and permissioning changes, harden the nodes and keys, set up backup and restore, and document the runbooks and the final configuration for your operations team. Ask any implementation partner for a written scope that names each of these deliverables, the rollback test and the handover, and confirm with your own consortium how it will be governed. Scope, timelines and cost follow from that written scope, so the quote should not be accepted until the cutover and rollback steps are specific.

Questions teams ask before moving off GoQuorum

Does GoQuorum still work if it is archived?

Yes, a network already running GoQuorum keeps running, but no one upstream maintains it anymore. The GoQuorum README says Consensys no longer actively maintains or supports the project and does not recommend it for new projects. The last release, v24.4.1, was published on June 12, 2024, under LGPL-3.0. Your team would carry the risk of security fixes, dependency updates and compatibility with newer Ethereum tooling. Review the archived repository and decide how long your current network can run safely before you plan a move.

Can Besu replace Tessera private transactions?

Not with a configuration change. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, so Besu no longer offers GoQuorum-style private transactions out of the box. Besu 25.7.0 also removed the EEA and PRIV privacy RPC API groups. Replacing private transactions means choosing a different privacy design, such as an off-chain data exchange that your team designs and operates, or a platform with native private data handling. Start by listing which contracts and flows depend on private state, because that inventory decides how much redesign the move needs.

How long does a GoQuorum to Besu migration take?

No duration is published for this work, so ask for a timeline in the written scope rather than relying on a general estimate. The main drivers are the number of nodes and environments, how many private contracts need redesign, and how many consortium members must upgrade together. Other factors include key and account handling, integration with signing or vault systems, and the number of rehearsal cycles your change board requires. Consensus alignment helps: GoQuorum lists QBFT as interoperable with Besu, but you still need to test the cutover and the rollback path before any production date is set.

What does a migration need from our internal team?

A migration needs several roles to be filled, and most teams find that no single person covers all of them. The main roles are:

Node operators who can build and run Besu, which requires JDK 25 according to the 26.6.0 release notes
Smart contract owners who can map private contracts and confirm expected behavior after the move
Infrastructure owners who handle backups, monitoring and network configuration, including the metrics documentation
Security owners who manage node keys, permissioning files and JSON-RPC authentication

Also confirm who approves changes and who is on call during cutover.

Can our own team migrate GoQuorum to Besu alone?

Your team can do it alone only if it already has operators who know both platforms, time for rehearsals, and the authority to make privacy design decisions. Many teams find the hardest part is the privacy redesign and contract review, not the node work. DeployOpen plans, implements, integrates, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, usually under a fixed scope agreed in writing before work starts. Contract logic changes may fall outside that scope, so confirm who owns them. Ongoing support after cutover is available as a retainer.

Does Besu support Istanbul BFT or Raft like GoQuorum?

The supplied Besu consensus documentation lists QBFT and IBFT 2.0 as the proof of authority protocols for private networks, and it recommends QBFT as the enterprise-grade option. Besu no longer supports Clique, and Besu 26.4.0 removed Clique so that pure Clique networks can no longer start or produce blocks. GoQuorum offers Istanbul BFT, Clique and Raft, but those two options are not listed in Besu's private network protocols. Confirm the current consensus documentation before you plan, and treat any network that depends on Raft or Istanbul BFT as a design change to scope.

What should a migration quote include?

A useful quote states the scope in writing before any price or schedule is discussed. Ask that it includes:

The nodes, environments and networks in scope, and what is excluded
A contract and privacy inventory, with the redesign assumptions behind each item
A backup plan and rollback path, including a backup taken before any Besu upgrade, since older versions cannot open an upgraded Bonsai database
Test scope, acceptance criteria and cutover steps
Documentation handover and training for your operators
Post-cutover support, either as a retainer or a separate agreement

Ask what drives the fee and which items are one-time versus recurring.

How DeployOpen helps choose, implement or migrate a Besu network

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. The cards below cover the work a GoQuorum team typically needs, and the platform decision itself depends on your network's requirements.

Platform fit assessment

Before any migration plan, we can help you test whether Besu meets the requirements your GoQuorum network actually depends on. Those include the consensus protocol, how node and account permissioning is enforced, how private transactions are handled, and which external vaults or plugins are in use. The output is a written assessment that lists each requirement as met, partly met or not met, so the decision rests on your network's needs rather than on a default choice.

Privacy replacement design

Besu no longer includes Tessera privacy or onchain permissioning, so any GoQuorum workflow that relied on private transactions or private contracts needs an explicit replacement design. We can map which parties need to see which data, document where that data flows, and identify the application-layer or architectural changes required. Confirm each design choice with your legal and compliance owners before build work starts.

Migration planning and cutover

A network move involves node rebuilds, key handling, genesis and configuration changes, and a cutover window agreed with every consortium member. We plan the sequence, rehearse it in a non-production environment and document the rollback path. Ask for the migration plan, the test evidence and the cutover runbook to be listed as written deliverables in your scope.

Node operations and backups

Once Besu runs, operators need backup schedules, upgrade procedures and monitoring for each node. Besu's Bonsai database upgrades automatically on first start, and older Besu versions cannot open an upgraded database, so a backup taken before each upgrade is the only practical rollback. We can set up those backups, the upgrade runbook and metrics collection, and confirm restore tests in your environment.

Hardening, testing and compliance evidence

We harden node access, JSON-RPC authentication and key storage, and run security testing against the network and its applications. We also prepare the controls and evidence your compliance assessor will ask for. DeployOpen does not issue audit reports, attestations or certifications, so confirm with your independent auditor which evidence they need before scoping the work.

Fixed-scope engagement terms

Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as retainers. Ask for each deliverable, acceptance criteria and the handover of documentation to be stated in the written scope.

Hyperledger Besu vs GoQuorum