Migrating a GoQuorum network to Hyperledger Besu: the short answer
If your network runs GoQuorum, the repository was archived on June 5, 2026, and Consensys no longer maintains or supports it. The README says it is not recommended for new projects, so every node you operate now carries security and upgrade risk that will not be fixed upstream. The good news is that the consensus layer is not the main obstacle. The GoQuorum README describes its QBFT implementation as interoperable with Besu, which means the chain itself can be a starting point for a Besu network. What you must replace is everything around the chain: the private transaction layer and the deployment tooling built for GoQuorum. How much work that is depends on two things you can measure now: whether your contracts rely on private transactions, and how many validators you run.
Be careful with one assumption. The facts available to us do not document an in-place validator transition across a mixed-client network. Besu's add-and-remove-validators-without-voting transitions are Besu-specific, so they cannot be used to change the validator set while some nodes still run GoQuorum. Plan any validator change as a coordinated move in which the full set of nodes ends up on Besu, and confirm the exact steps with the Besu maintainers and your own test network before you commit to a date. Private transactions are the larger issue. GoQuorum uses Tessera for them, and Besu removed its Tessera privacy feature in 25.6.0, so an existing private contract flow has no direct equivalent in Besu. Ask your team to inventory which contracts and participants depend on private payloads before estimating scope.
Which GoQuorum capabilities map to Besu and which do not
This table compares the main GoQuorum capabilities a network relies on with their Besu counterparts. Read the status column first: QBFT is documented as interoperable, Tessera privacy has been removed from Besu, and the remaining rows need confirmation against your own node and validator configuration before you plan the move.
| Capability | GoQuorum | Besu status |
|---|---|---|
| QBFT consensus | QBFT implementation, documented in the GoQuorum README as interoperable with Besu | Interoperable per the GoQuorum README. Confirm the QBFT genesis and validator set with your own nodes before any cutover. |
| Validator changes on a mixed-client network | Validator set changes made through the existing GoQuorum process | Besu transitions cannot change validators in a mixed-client QBFT network. Plan validator changes separately. |
| Private transactions | Private transactions delivered through Tessera | Not available. Besu removed the Tessera privacy feature in 25.6.0, so private transaction flows must be re-platformed. |
| Private RPC access | Private transaction RPC calls tied to the Tessera workflow | Not available. The EEA and PRIV RPC API groups were removed in 25.7.0. |
| Node permissioning | Node and account controls configured in your GoQuorum setup | Local permissioning files per node. Confirm that your allowlists and account rules can be expressed in these files. |
| Node and validator configuration | Node startup flags and genesis settings specific to your deployment | Besu uses its own flags and configuration. Confirm each option you rely on against the Besu documentation for your target release. |
| JSON-RPC access | RPC endpoints exposed under your existing access controls | Credentials file or JWT authentication supported. Besu does not terminate HTTPS, so confirm your TLS termination layer. |
| Node private key handling | Key handling as configured in your GoQuorum deployment | Node key file is unencrypted by default. Confirm whether an HSM plugin is required for your key policy. |
| Helm charts and deployment tooling | Charts and scripts built around GoQuorum and Tessera | Must be rebuilt or replaced for Besu. Confirm each dependency against your own deployment repository. |
Why Besu validator transitions do not work in a mixed-client network
Besu validator transitions cannot change the validator set of a mixed-client QBFT network. The Besu transition mechanism is Besu-specific, so while any GoQuorum node remains in the network, you cannot use it to add or remove validators in a way that every participant will follow. A GoQuorum validator set therefore cannot be altered with Besu's transition tooling while GoQuorum nodes are still running. The QBFT interoperability described in the GoQuorum README is a property of the consensus protocol, not a license to run the validator change mechanism across two clients.
The planning consequence is that the validator change must be designed as a cutover in which every validator runs Besu at the point the set changes. In practice, that means the migration plan should treat the GoQuorum-to-Besu move as one coordinated event for the validator tier, with each operator's validator node replaced or upgraded before the membership change takes effect. Your team should record which validators are on GoQuorum, which are on Besu, and who controls each node, then agree the order of operations across the consortium before any genesis or validator change is scheduled. Ask each operator to confirm its node keys, data directory and peer configuration for the Besu side before the window opens.
Confirm the exact procedure, including any required ordering, block numbers and the handling of pending votes, against the Besu add-validators documentation before you write a runbook. Treat that document as the authority for what the transition mechanism does and does not support, and check the current Besu release notes for any changes in the release you plan to deploy. Where the documentation leaves a case open, such as a partially migrated set, escalate it to the Besu maintainers or your consortium's technical lead rather than assuming a workaround will hold.
Choosing between a rolling client swap and a new Besu network
This option keeps the existing GoQuorum network running for a limited period while you plan and test the move. It makes sense when the work to replace private transaction dependencies or applications is not finished yet, and the team needs time without changing the production chain. The GoQuorum repository is archived and no longer maintained or supported by Consensys, so the bridge carries a security and patching burden that grows with time. Treat it as a holding position, not a destination.
- Validator coordination: Nothing changes on the validator set, so consortium members keep their current operating model during the bridge.
- Privacy dependencies: Tessera-based private transactions keep working on GoQuorum, so applications depending on them face no immediate change.
- Patching exposure: Known vulnerabilities in an archived codebase will not receive upstream fixes, so compensating controls and an exit date matter.
- Rollback: Rollback is trivial because nothing has changed, but the cost of staying is ongoing risk rather than a one-time event.
- Confirm before choosing: Confirm the exit date with every consortium member and the specific GoQuorum version each node runs.",
A rolling swap replaces GoQuorum nodes with Besu nodes one at a time while the chain keeps its history and its validator set. The GoQuorum README describes its QBFT implementation as interoperable with Besu, which is the basis for this path, but interoperability on paper does not settle whether your genesis, validator set and block production will carry across. Mixed-client networks also cannot use Besu's validator transitions, so validator changes during the swap must be planned separately.
- Validator coordination: Every validator operator must agree on timing, and quorum must hold at each restart, so the sequence has to be written down in advance.
- Privacy dependencies: Besu removed its Tessera privacy feature in 25.6.0, so private transactions will not work on a Besu node that replaces a GoQuorum node.
- Rollback: Besu upgrades can change database formats, so a backup taken before each node change is the only reliable reversal point.
- Transitions: Besu validator transitions are not usable to change validators in a mixed-client network, so do not plan a validator change as part of the swap.
- Confirm before choosing: Confirm with a test network that a Besu node syncs and produces blocks on your exact genesis, and confirm the Besu release that matches your JDK and host requirements.
A new network starts a fresh Besu QBFT chain, then moves state and applications across. This path removes GoQuorum dependencies entirely and gives you a chain designed around current Besu features, at the cost of a state migration and a cutover that all parties must coordinate. It is usually the cleanest end state when private transactions must be re-platformed anyway, because the privacy design can be settled before go-live.
- Validator coordination: Each organization must onboard its validators to the new chain, which is a consortium governance task rather than a node operation.
- Privacy dependencies: Private transaction flows must be redesigned on a supported approach, since Tessera is gone from Besu, and this is the largest scope item.
- State and applications: Contracts, balances and history do not carry over automatically, so you need a documented plan for what is migrated and what is archived.
- Rollback: Rollback means keeping GoQuorum running until the cutover is accepted, so a parallel run period needs its own budget and access plan.
- Confirm before choosing: Confirm which data the consortium must keep on-chain, and which records a regulator or auditor will want retained in another form.
Documented import paths and tooling to inspect during the move
No documented GoQuorum-to-Besu importer was supplied for this move, so the cards below cover what can be verified today: standard chain read access, Besu's local permissioning files, release planning and the validator documentation. Confirm any migration tooling with the vendors and against your own environment before you rely on it.
Standard JSON-RPC state access
Besu serves the standard Ethereum JSON-RPC interface, which lets your team read blocks, transactions, receipts and contract state from the running GoQuorum network and from a Besu node. Use it to build a reconciliation script that compares balances, contract storage and event logs between the two chains before any cutover. Confirm which GoQuorum-specific fields and private state your reads can reach, because public state reads will not return private payloads.
Local permissioning configuration files
Besu's local permissioning uses a node permissions file to restrict connections to known participants and an account permissions file for onboarding rules and action restrictions. Compare the rules your GoQuorum network enforces today with what these files can express. Any rule held in an onchain contract will need to be rewritten as a local file or a plugin, and every node must carry the same rules.
Besu releases for version planning
The Besu releases page lists each calendar release with its date and release notes, which is where you find breaking removals and database changes. Pin the target version against the notes before you build the new nodes, and plan the JDK requirement stated in the 26.6.0 notes into your build images. Check the notes for any change to the database format, since an upgraded database may not reopen on an older release.
Add and remove validators documentation
Besu's add-validators-without-voting documentation describes how Besu manages validator changes, but it applies only to Besu-specific transitions. In a mixed-client QBFT network that still includes GoQuorum nodes, do not use those transitions to change the validator set. Plan validator changes as a coordinated, client-by-client rollout and confirm the exact procedure with the GoQuorum and Besu maintainers and your own test network.
Node key and metrics inspection
Inventory the node key files each GoQuorum validator uses, because Besu documents that its local node key file is not encrypted and suggests a security module plugin where hardware-backed storage is required. Confirm that each key maps to a validator identity you intend to keep. Use Besu's Prometheus metrics on a test node to confirm that block production and peer counts look healthy before you move any production validator.
Replacing Tessera private transactions and GoQuorum-specific dependencies
GoQuorum private transactions depend on Tessera, and Besu no longer has that feature. Besu removed its Tessera privacy feature in 25.6.0 and removed the EEA and PRIV privacy RPC API groups in 25.7.0. Any application, wallet flow or node configuration that sends private payloads through Tessera, or calls eea_* or priv_* methods, will fail on a current Besu release. Before you choose a path, inventory every private transaction type, every participant that receives private payloads and every service that calls the privacy API. Confirm the exact Besu release you plan to target against the Besu releases page, because the removals landed in different versions.
Three options remain. You can keep private workflows on an older Besu release, which carries security and support risk you must accept in writing. You can rebuild the private layer as a Besu plugin or take on a community fork, which means owning the code and its upgrades. Or you can re-platform private workflows onto a different privacy design, such as Paladin privacy domains, which changes the data model and the application integration. The choice depends on how many transactions are private, how many organizations must see them and how much application code depends on the old API. The sibling topic on moving off Tessera private transactions covers these options in depth.
The deployment charts, scripts and Tessera sidecars built for GoQuorum are a separate migration task. Helm charts, Ansible roles or shell scripts that start geth or Quorum binaries, mount Tessera configuration, generate tessera keys or pass GoQuorum-only flags must be rewritten for Besu's command-line options and node layout. Plan the rewrite as a version-controlled change with a test environment that mirrors production topology. Ask your current maintainers to list every GoQuorum-specific flag, environment variable and secret path so nothing is silently dropped at cutover.
How the migration sequence runs with a parallel run and cutover
The sequence moves a GoQuorum network to Besu in controlled stages, so each phase produces evidence that the next one can rely on before any production node changes. It keeps the existing network serving traffic until the Besu side has matched it block for block and behavior for behavior.
Inventory nodes, validators, privacy groups and charts
Your team and the DeployOpen engineers list every GoQuorum node, validator key holder, Tessera privacy dependency, permissioning file, node key location, deployment chart and the applications that call the JSON-RPC endpoints. Privacy groups and private contract state are recorded separately, because Besu removed the Tessera privacy feature in 25.6.0 and those flows need a replacement design. The step is done when the inventory is signed off by the network owner and each item has a named replacement or a decision to retire it.
Build a pilot Besu network from the inventory
Engineers stand up a separate Besu QBFT network in a non-production environment, using the genesis settings, validator count and permissioning design agreed from the inventory. Application teams point test clients at this pilot to confirm transaction submission, event reads and account onboarding work against the Besu JSON-RPC surface. The step is complete when the pilot produces blocks under expected validator behavior and the application test suite passes against it.
Run the parallel network and compare results
The GoQuorum network keeps serving production while the Besu network receives the same transaction workload from a replay or mirrored test harness. Engineers compare block production, transaction outcomes, contract state and application responses between the two networks and log every divergence with its root cause. The step is done when divergences are either fixed or formally accepted by the business owners, and the comparison results are retained as evidence for the change record.
Confirm the cutover plan and rollback path
The team writes the cutover runbook covering the order of validator and node changes, communication to participants, the freeze window and the go or no-go criteria. It also defines the rollback path and who approves each decision. Besu's Bonsai database auto-upgrades on first start and older Besu versions cannot open an upgraded database, so the runbook must require a verified backup of every node's data before any Besu node starts on production data. The step is done when the runbook is approved and a backup restore has been tested on a copy.
Take verified backups before any upgrade
Engineers take backups of node data, keys and configuration on every node that will change, then verify that each backup can be restored in an isolated environment. Keys are handled according to your key management design, and the backup locations are recorded in the change record. The step is complete when every backup has a successful restore test and the owner signs off that rollback is possible until the decommissioning decision.
Execute the planned cutover
Operators apply the runbook in the agreed order, moving application traffic and validator roles to the Besu network while monitoring block production, peer connections and error rates. Participants are informed at each checkpoint, and the go or no-go criteria are checked before each step. The step is done when the Besu network serves production traffic, the post-cutover checks pass and the change is closed with a record of every action taken.
Decommission GoQuorum after a stable period
Once the Besu network has run in production long enough for your operations and governance teams to accept it, the GoQuorum nodes are shut down, their keys and data are archived under your retention policy, and the associated charts and Tessera components are removed. Documentation, monitoring and access rules are updated to reflect the new network. The step is complete when decommissioning is signed off and the GoQuorum infrastructure no longer appears in your inventory.
What drives the cost and duration of a GoQuorum to Besu move
This table lists the factors that change the effort of a GoQuorum to Besu move, who typically pays for each piece of work, and what to request in a written scope. Read it as a checklist: the more rows that apply to your network, the more the scope and the schedule depend on them.
| Driver | Why it changes effort | What to ask for in a quote |
|---|---|---|
| Validator and node count | Each validator and node needs a Besu build, configuration, key handling and verification, and changes must be sequenced so the QBFT validator set keeps quorum. | Per-node work list, the rolling change order, and who runs the validator restarts. |
| Private transactions and Tessera groups | GoQuorum private transactions rely on Tessera, which Besu removed in 25.6.0, so private workflows need a replacement design rather than a configuration change. | Inventory of private contracts and participants, the chosen replacement, and whether data migration is in scope. |
| Onchain permissioning dependence | Rules held in smart contracts must be moved to local node and account permissioning or a plugin, and kept consistent across all members. | List of permissioning contracts, the target rule model, and who approves the consortium-wide rule set. |
| Applications and integrations | Each application that calls GoQuorum RPC, signs transactions or reads private data must be retested against Besu's API surface. | Application inventory, owner per integration, and the test scope for each one. |
| Custom charts and automation | Helm charts, deployment scripts and pipelines written for GoQuorum must be rebuilt or retired, which adds work that is easy to underestimate. | Inventory of charts and scripts, what is rebuilt versus retired, and the handover format. |
| HSM-backed keys | Moving validator and node keys into a hardware security module through the Besu HSM plugin adds vendor setup, access control and key ceremony work. | Confirmed HSM model, plugin version compatibility, and whether key migration or new key generation is planned. |
| Testing and rollback planning | A backup taken before any Besu upgrade is required for rollback, and parallel test networks add infrastructure and verification effort. | Test network plan, backup and restore test evidence, and the go or no-go criteria. |
What usually goes wrong in GoQuorum to Besu migrations
Can an uncoordinated validator restart fork a GoQuorum network moving to Besu?
Yes, an uncoordinated restart can split a mixed-client QBFT network, because Besu's validator transitions cannot change the validator set of a network that also runs GoQuorum nodes. The Besu documentation on adding and removing validators without voting describes these transitions as Besu-specific. Prevent this by agreeing one written cutover plan with every validator operator before any node changes software. Set the restart order, restart one validator at a time, and confirm each node has rejoined, is peering with the others, and is importing blocks before moving to the next. Keep enough validators online to hold quorum at every step, and rehearse the full sequence on a copy of the network. Ask each operator to confirm they can stop and start in the same window, and record a rollback point for each step.
What happens to private transaction data when leaving GoQuorum for Besu?
Private transaction data does not move with the chain, because GoQuorum private transactions depend on Tessera and Besu removed its Tessera privacy feature in 25.6.0. Besu 25.7.0 also removed the EEA and PRIV privacy RPC API groups, so applications that call them will fail after upgrade. Prevention starts with an inventory of every private contract, the parties that hold each payload, and the applications that read it. Decide the replacement path for each workflow before decommissioning Tessera, whether that is a Besu plugin, a fork, or a different privacy design. Archive any private data you must keep, with its provenance, before the old nodes are shut down. Finally, search your application code and integration layer for EEA and PRIV method calls and confirm none remain in production. Review the Besu release notes for the versions you target.
Can you roll back Besu after a Bonsai database upgrade?
Only if you took a backup before the upgrade, because the Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and older Besu versions cannot open the upgraded database. A node that has started on a newer release therefore cannot simply be downgraded. Prevent this by stopping the node and backing up its data directory before any version change, and by recording the exact Besu version in use. Test the restore on a separate host so you know the backup is usable before you rely on it. Keep the old binary or image available until the new version has run cleanly through a full validation period. Make the backup and restore steps part of the runbook for every node, including nodes that are only being rebuilt.
What happens to smart contract permissioning rules after moving to Besu?
Rules held in a permissioning smart contract stop being enforced by Besu, because Besu removed onchain permissioning in 25.6.0. The rules must be rebuilt as local permissioning files on each node. Besu's permissioning documentation separates node permissioning, which restricts which peers a node connects to, from account permissioning, which covers onboarding, suspending accounts and restricting actions. Start by exporting every allowlist, role and suspension from the contract and mapping each one to one of those two layers. Write the resulting configuration for every node, then compare the files across all operators so the consortium applies the same rules. Test both allowed and denied cases on a copy of the network, including a suspended account and an unknown peer, before go-live.
How should node and validator keys be handled during a rebuild?
Treat node and validator keys as the most sensitive material in the migration, because Besu's documentation says the local node private key file is not encrypted. Decide the key storage model before any host is rebuilt. Besu supports a security module plugin, such as the Besu HSM plugin enabled with the --security-module option, for deployments that need hardware-backed keys. Where no HSM is used, restrict file permissions, keep key files off shared storage and out of container images and chart values, and avoid copying them between hosts without a controlled transfer. Keep a register of which key belongs to which node and validator, so the right key is loaded at each step. After cutover, retire old key material under a documented procedure and keep an audit trail of who handled each key. Read the Besu node keys documentation before you design the process.
Do GoQuorum deployment charts and build pipelines work unchanged with Besu?
They usually need changes, because Besu 26.6.0 requires JDK 25 to build and run, and GoQuorum-era charts often carry Tessera settings, privacy ports and EEA or PRIV API configuration that have no direct Besu equivalent. Start by listing every chart value, environment variable and sidecar that refers to Tessera, privacy, Clique or the removed RPC groups. Update build images and CI pipelines to JDK 25 where you compile or package Besu, and confirm the version you plan to run in the release notes before you pin it. Rebuild the deployment in a test cluster from the updated charts, then compare the running configuration with the design document. Ask your platform team to confirm who owns each chart after cutover, since ownership often lapses during a migration.
How DeployOpen scopes and delivers a GoQuorum to Besu migration
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers and air-gapped networks. For a GoQuorum to Besu move, that means the work happens on your nodes, with your validator keys, your private data stores and your change windows. We do not run the network from outside it, and we do not hold your keys. Before any engagement starts, you should expect a written scope that names the networks, nodes, validators, privacy dependencies, integrations and cutover approach in scope, along with the deliverables and timelines that follow from them.
Most engagements of this kind are fixed-scope. The written scope is the working contract: it lists what is migrated, what is retired, what is explicitly excluded, and who signs off each stage. Because the GoQuorum repository was archived on June 5, 2026, a scope should also state how the team will handle the parts of the current network that have no direct Besu equivalent, such as Tessera-based private transactions and any Helm charts or deployment scripts tied to GoQuorum. Ask for a scope that separates the consensus and node work from the privacy and application work, since they usually have different owners and different risks.
Where the client wants ongoing help after cutover, DeployOpen offers retainers for continued support, upgrades and testing. A retainer is separate from the migration fee, recurs on its own terms, and should be quoted and scoped in writing like any other work. Confirm with any partner whether the operational support covers Besu's monthly calendar releases, the Bonsai database upgrade behavior noted in the 26.10.0 release notes, and the JDK 25 requirement from the 26.6.0 release notes, since each affects how often the network must be touched.
