Which enterprise blockchain platform fits your consortium network
If your team is choosing a platform for a permissioned or consortium network that it will run for years, start with the design you need. Fabric suits channel-based, chaincode-led consortium designs where participants share channels, private data collections and business logic written in Go, Java or Node.js. Besu suits teams that want an Ethereum-compatible EVM client with proof of authority consensus, using QBFT for private networks. Corda suits regulated bilateral and multi-party workflows built on flows and notaries, where transactions go only to the parties involved. GoQuorum is archived, so do not select it for a new network. Check its status in its repository before relying on it for any existing deployment.
Fabric's strongest case is the ordering and identity model. Raft is the recommended crash fault tolerant ordering service, and the BFT ordering service added in v3.0 matters only if your consortium cannot assume that ordering nodes are trusted to run honestly. Fabric CA handles enrollment, renewal and revocation for member identities, so pair the choice with a plan for who operates the CA and how certificates are rotated. Confirm which line you will run: v2.5 is the long-term support release for production users, while v3.x brings newer features and requires migrating Kafka ordering to Raft and moving channels to the v2.x lifecycle first.
Besu's advantage applies when your developers, tooling and smart contracts already target the EVM. It is an Apache-2.0 Java client that also runs on public networks, which keeps a path open if your use case later needs one. The condition is maintenance discipline: Besu ships releases roughly monthly, requires JDK 25, and has removed Tessera privacy, onchain permissioning, Clique and several privacy RPC groups. Any private transaction design must be rebuilt on current features, and rollback after a Bonsai database upgrade needs a backup taken beforehand. Corda fits when legal finality and counterparty-level privacy outweigh tooling familiarity. Its CorDapps are written in JVM languages, and Corda 5 is maintained by R3 under Apache-2.0, so confirm the current support position for the version you plan to adopt.
Enterprise blockchain platform by scenario: which one fits your situation
This table maps common situations to the platform most likely to fit, with the condition that drives each choice. Read each row against your own counterparties, data rules and Ethereum skills, then confirm the flagged points with the vendor or in a pilot before committing.
| Scenario | Best fit | Why and what to confirm |
|---|---|---|
| A consortium that needs channel-level data isolation between members | Hyperledger Fabric | Fabric separates data through channels and private data collections, and it has no native cryptocurrency. Confirm how your membership service provider and channel policies will be governed across members. |
| A team that already writes Ethereum tooling and needs a permissioned EVM network | Hyperledger Besu | Besu is a Java Ethereum client that runs private networks on QBFT or IBFT 2.0 proof of authority. Confirm that your contracts and tooling work on the Besu version you plan to run, and plan for JDK 25. |
| A regulated workflow between a few counterparties that needs strict privacy | Corda (confirm edition and maturity) | Corda is designed for strict privacy between transacting parties, with a notary that checks uniqueness without global broadcast. Confirm which Corda line fits, since the Corda 4 open source tags and the Corda 5 runtime are separate codebases. |
| A team migrating off GoQuorum | Hyperledger Besu (confirm migration path) | GoQuorum is archived, so it should not anchor a multi-year network. Besu is an Ethereum client with proof of authority options, but its privacy path changed when Tessera and the EEA and PRIV APIs were removed. Confirm how your private transactions and permissioning will be re-created in a pilot. |
| A Kafka-based Fabric network that must upgrade to a current release | Hyperledger Fabric with Raft ordering | Fabric v3.0 removed Kafka and Solo ordering, so Kafka networks must move to Raft and all channels must use the v2.x lifecycle first. Plan this migration in a pilot and back up the ledger and MSPs before upgrading. |
| A network that needs Byzantine fault tolerance in the ordering layer | Hyperledger Fabric v3.x (confirm readiness) | Fabric v3.0 added a BFT ordering service based on SmartBFT. Confirm that the BFT option is supported for your deployment and that your operators can run it before choosing it over Raft. |
| A consortium that expects Besu's node permissioning and account permissioning to govern access | Hyperledger Besu | Besu's local permissioning files restrict node connections and account actions per node. Confirm how these files will be kept in sync across all member nodes and who approves changes. |
| A team planning to stay on the long-term support line for production | Hyperledger Fabric v2.5 (confirm support window) | The Fabric documentation names v2.5 as the long-term support release for production users. Confirm the support window and the upgrade plan with the vendor before the line changes. |
How each blockchain platform is built and licensed
Each card covers one platform's license, programming model and release posture as it stands in the supplied sources. Read them together with the release lines and maintenance status, because a platform's license is the least of the questions for a network you expect to run for years.
Hyperledger Fabric
Fabric is an Apache-2.0 permissioned ledger from LF Decentralized Trust. It maintains two lines, v3.1 (latest v3.1.5) and v2.5 (latest v2.5.16), and the documentation names v2.5 as the long-term support release for production users. Transactions follow an execute, order, validate flow, and chaincode can be written in Go, Java or Node.js. Check which line your upgrade plan targets before you choose a language and runtime for chaincode, because v3.0 removed Solo and Kafka ordering and the v1.x lifecycle.
Hyperledger Besu
Besu is an Apache-2.0 Ethereum client written in Java and hosted under LF Decentralized Trust. For private networks it supports the QBFT and IBFT 2.0 proof of authority protocols, and the Besu documentation recommends QBFT as the enterprise-grade option. Clique is no longer supported. Confirm the JDK 25 requirement with your platform team before you plan build and runtime images, since Besu 26.6.0 requires it to build and run, and Besu ships releases roughly monthly.
Corda
Corda is an open source blockchain project for business, licensed under Apache-2.0. The corda/corda repository holds the first architecture, covering Corda versions 1 through 4, while the corda-runtime-os repository holds the second architecture that forms the basis of Corda 5, developed and maintained by R3. Smart contracts and the platform itself are built on Kotlin and the JVM, and distributed applications are called CorDapps. Confirm which architecture your network will run before you commit developers to a codebase.
GoQuorum
GoQuorum is archived, so it receives no new development from its maintainers. Treat any existing GoQuorum network as a migration decision, not a supported platform choice. Check the GitHub repository for its last release and the date it was archived, and confirm with your own engineers which security fixes, if any, were shipped before the archive. Plan the migration path and its testing window with your own team and the platform you select.
Privacy, consensus and governance across Fabric, Besu and Corda
This table compares Hyperledger Fabric, Hyperledger Besu and Corda on license, governance, privacy, consensus or ordering, programming model, identity and permissioning, and release cadence. Read each row against your own network design, since a row that looks equal on paper can still differ in the controls you must operate yourself.
| Capability | Hyperledger Fabric | Hyperledger Besu | Corda |
|---|---|---|---|
| License | Apache-2.0 (hyperledger/fabric repository) | Apache-2.0 (besu-eth/besu repository) | Apache-2.0 for the corda/corda repository; Corda 5 under Apache-2.0 per its runtime repository |
| Governing body | LF Decentralized Trust, where Fabric is a Graduated project | LF Decentralized Trust, where Besu is a Graduated project | R3 develops and maintains Corda 5; confirm current governance terms for Corda 4 and 5 with R3 |
| Privacy model | Channels separate ledgers between member groups; private data collections hold data visible only to authorized organizations | Private networks run on permissioned peers; Tessera privacy was removed in 25.6.0, so confirm your replacement privacy design before you plan | Transactions shared only with parties involved, supported by peer-to-peer flows and a notary that checks uniqueness without global broadcast |
| Consensus or ordering options | Raft (crash fault tolerant) recommended; BFT ordering via SmartBFT added in v3.0, tolerating failures below one third of ordering nodes | QBFT recommended for enterprise use; IBFT 2.0 also supported; Clique and Ethash no longer supported | Notary service validates transaction uniqueness and sequencing; confirm notary cluster options and fault tolerance with your Corda distribution |
| Programming model | Chaincode in general-purpose languages such as Go, Java and Node.js; execute, order, validate flow | Ethereum smart contracts and Ethereum tooling; Besu is an execution client and needs a consensus client on public networks | CorDapps with flows for negotiation between participants; smart contracts written in Java or other JVM languages |
| Identity and permissioning | Fabric CA issues enrollment certificates and handles renewal and revocation; LDAP can serve as the user registry | Node permissioning restricts connections to known participants; account permissioning governs onboarding and suspension | Identity and network membership are managed within the Corda network; confirm the identity service and certificate authority for your deployment |
| Release cadence | Parallel lines: v3.1 (latest v3.1.5) and v2.5 LTS (latest v2.5.16), both patched in June 2026 | Calendar versions shipped roughly monthly; 26.10.0 released October 16, 2026 | Corda 4 open source last tagged release-os-4.14.3; confirm the support window and upgrade path for your version |
| Upgrade and rollback | Four-step guide: back up ledger and MSPs, roll orderers, roll peers, then update channel capability levels | Bonsai database auto-upgrades on first start and older versions cannot open it, so back up before upgrading | Confirm upgrade procedures and compatibility between Corda releases with the vendor documentation |
How privacy and consensus work on each platform
Fabric separates privacy from ordering. Channels are separate ledgers shared only by the organizations joined to them, so an organization outside a channel cannot see its transactions or state. Inside a channel, private data collections let a subset of members keep sensitive values off the shared channel ledger, with only a hash recorded on the channel for other members to verify. Ordering is handled by a separate service, and its consensus choice determines how the network behaves during outages.
- Raft (crash fault tolerant): Fabric's recommended ordering option keeps working while a majority of ordering nodes is available. A five node cluster tolerates the loss of two nodes, but it does not defend against nodes that lie.
- SmartBFT (Byzantine fault tolerant): Added in v3.0, this ordering option tolerates failures of fewer than one third of ordering nodes, which suits consortia that do not fully trust every orderer operator. It is a newer option, so confirm its operational track record with your team before committing.
- Visibility of orderers: Ordering nodes see transaction content on the channel they serve, so the orderer operator's identity and access controls matter as much as channel design.
- Membership and identity: Fabric CA issues enrollment certificates and handles revocation, so who can join and act is governed by your membership service provider configuration.
Before you design, confirm which organizations must be excluded from which data, who operates the orderers, and how many ordering nodes you can afford to lose at once.
Besu is an Ethereum client, so its privacy model follows the Ethereum account and transaction model rather than channels. On private networks it uses proof of authority consensus, where a set of validators produces blocks. Access control is handled by permissioning rather than by isolating ledgers, so the question for a consortium is which nodes may connect and which accounts may transact.
- QBFT for enterprise networks: Besu supports QBFT and IBFT 2.0 for private networks and recommends QBFT as the enterprise-grade option. Clique and Ethash are no longer supported, and Besu 26.4.0 removed Clique, so pure Clique networks cannot start or produce blocks on current releases.
- Node permissioning: Each node's permissions configuration file restricts which peers it connects to, keeping the network closed to unknown participants.
- Account permissioning: Local rules control onboarding, suspending accounts and restricting actions, which lets a consortium remove a misbehaving participant from transacting.
- Removed privacy features: Besu 25.6.0 removed Tessera privacy and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. Private transaction confidentiality therefore has to come from a design outside the client, so confirm your approach with the vendor before you rely on it.
- Upgrade caution: The Bonsai database auto-upgrades on first start, so take a backup before upgrading if you may need to roll back.
Confirm which node and account permissioning rules your governance model needs, and whether your confidentiality requirement can be met without the removed Tessera feature.
Corda does not broadcast transactions to every node. Each transaction is shared only with the parties to that transaction, which is the core of its privacy model. A notary service validates that each state is used once and that transactions occur in the right order, without needing to see the full business content of every deal. Participants coordinate through flows, which handle the peer-to-peer exchange and negotiation needed to build and sign a transaction.
- Data shared only with parties: Counterparties receive the data needed to verify a transaction, and other network members do not see it.
- Flows coordinate counterparties: Flows manage messaging and negotiation directly between nodes over a peer-to-peer network, so the design does not depend on a shared global ledger.
- Notary validation: The notary checks uniqueness and sequencing of transactions without global broadcast. Notary availability and operator choice affect whether transactions can be finalized, so treat the notary as a critical dependency.
- Version context: The corda/corda repository holds the first architecture for Corda 1 through 4, and Corda 5 is built on the second architecture in corda-runtime-os. Confirm which line matches your needs and its support status.
- CorDapps and JVM code: Smart contracts are written in Java or other JVM languages, so your review and testing processes for contract logic apply directly.
Before you choose, map which parties must see each transaction, decide who operates the notary, and confirm the Corda line and support window with the vendor.
The maintenance status that matters for a multi-year network
Release history, removed features and support lines decide whether a network is still viable in year five, because a permissioned ledger is upgraded, not installed once. Each platform has moved features out of its codebase in recent releases, and a consortium that built on a removed feature faces a forced migration on the vendor's timetable. Before committing, read the release notes for every version since your planned go-live, and check the open issues for the components you depend on, such as the privacy layer, consensus mode and RPC methods your applications call. Besu uses a year.month scheme and ships roughly monthly. Its release history shows the risk clearly: Tessera privacy and onchain permissioning were removed in 25.6.0 (June 4, 2025), the EEA and PRIV privacy RPC API groups were removed in 25.7.0, and Clique consensus was removed in 26.4.0 (April 22, 2026), so pure Clique networks can no longer start or produce blocks. The 26.10.0 release (October 16, 2026) also auto-upgrades the Bonsai database on first start, and older versions cannot open that database, so the rollback plan depends on a backup taken before the upgrade. Confirm which consensus protocol your network uses (QBFT or IBFT 2.0 are the supported options for private networks) and which RPC groups your applications call.
Fabric runs two maintained lines in parallel. The v3.1 line (latest v3.1.5, June 18, 2026) carries newer features, while v2.5 (latest v2.5.16, June 17, 2026) is the long-term support release that the Fabric documentation names for production users. Fabric v3.0 removed Solo and Kafka consensus and the v1.x legacy chaincode lifecycle, so a network still on Kafka ordering must migrate to Raft and move every channel to the v2.x lifecycle before upgrading. Ask which line your consortium will hold for the life of the network, and plan the upgrade path to 3.x as a funded project rather than a patch. Corda splits into two codebases, and the difference matters for planning. The corda/corda repository holds the first architecture (Corda 1 through 4), and its most recent open source tag is release-os-4.14.3. The second architecture lives in corda-runtime-os and forms the basis of Corda 5, which R3 develops and maintains under Apache-2.0. Confirm which line your vendor supports and whether the Corda 4 tag will receive further work for your timeline. For GoQuorum, do not rely on secondhand reports: check the archival status directly on the project's repository and in the vendor's own notices before you accept it as a candidate.
What upgrading and rollback demand from your team
Fabric upgrades are a staged, rolling procedure, and the v3.0 line carries removals that must be handled before you start. The Fabric upgrade guide describes 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. Before moving to v3.0, your team must confirm that no channel still uses Solo or Kafka ordering, since v3.0 removed both, and that every channel runs the v2.x lifecycle, since the v1.x legacy lifecycle is gone. Kafka networks need a planned migration to Raft. Staff who own the MSPs and the Fabric CA should be the ones verifying the backup, because it is the only rollback path. The Fabric Gateway client API works with both v2.5 and v3.0, so application teams can upgrade on their own schedule, which lowers the coordination load on the network team. Run the full sequence on a test network first, because a capability-level change is hard to reverse on a live channel.
Besu upgrades are simpler to schedule but harder to undo. The Bonsai database upgrades automatically on first start, and older Besu versions cannot open an upgraded database. That makes a backup taken before the upgrade the only rollback path, so your operators need a documented, tested restore procedure and a known-good backup window for each node. Because Besu ships roughly monthly and the release notes call out database changes, the team should read each release note for database and consensus changes before scheduling, and confirm that the JDK version on each host meets the stated requirement (the Besu 26.6.0 release notes state JDK 25). Rolling the upgrade one validator at a time on a private test network, with a restore drill included, shows whether your staff can recover a node in practice. Ask your implementation partner or internal platform team to confirm the rollback steps against the exact release you plan to run.
How to choose a blockchain platform and run a pilot
This sequence turns the comparison into a shortlist decision backed by your own participant model, data rules, failure requirements and a tested pilot. Each step produces a written artifact that the shortlist review can check.
Define participants and their trust relationships
Start by listing every organization that will run a node or submit transactions, and who must be able to see, approve or reverse what. Map which parties trust each other enough to share an operator, which need independent operators, and whether any outside party must join later. This step decides whether you need a permissioned network with a fixed membership list, or a network that admits participants through governance you still have to design. Done means a signed-off participant register with each party's role, operator and onboarding and exit rules.
List the data that must stay private
Classify the transaction fields, balances and documents that cannot be visible to every participant, and the metadata that could reveal them even when payloads are hidden. Then compare how each platform isolates data: Fabric uses channels and private data collections, Corda limits transaction visibility to the parties involved, and Besu's privacy features have been removed, so private data on Besu needs a separate design that you must validate yourself. Done means a data classification table with a named isolation mechanism for each class, and a note on any gap that needs your own compensating control.
Decide whether an EVM toolchain is required
Determine whether your developers, auditors or existing contracts depend on the Ethereum Virtual Machine, its tooling and its Solidity ecosystem. If they do, Besu is the candidate to test first, and you must confirm which consensus and permissioning features your release supports. If they do not, Fabric's chaincode in Go, Java or Node.js or Corda's JVM CorDapps may fit your team's skills better. Done means a written statement of the languages and tools your team will maintain for the next several years, and the platforms that match it.
Match ordering or consensus to the failure tolerance
Translate your availability and integrity requirements into a fault model. Fabric offers Raft, which is crash fault tolerant and continues while a majority of ordering nodes is available, and a BFT ordering service added in v3.0 that tolerates failures of up to, but not including, one third of ordering nodes. Besu offers QBFT for private networks, and Clique is no longer supported. Ask each vendor or project to confirm the exact failure behavior in the release you plan to run. Done means a table of required fault tolerance, the consensus option that meets it, and the number of nodes and operators that implies.
Check release status and removals in each repository
Read the current release notes and the removed-features list for every candidate, not only the feature pages. For Fabric, confirm which line you will run (v2.5 is documented as the long-term support release for production) and the migration steps required for any v1.x or Kafka dependency. For Besu, review the removals of Tessera privacy, onchain permissioning, proof of work and Clique, and the JDK requirement in the release notes. Check whether Corda 4 or Corda 5 is the right line for your needs, since the open-source Corda 4 tag and the Corda 5 repository follow different architectures. Done means a dated record of the version, support status and removals for each candidate, reviewed by someone who will own the network.
Run a time-boxed pilot with an upgrade and restore
Deploy the shortlisted platforms on a test network that mirrors your participant model, consensus choice and privacy design. Run a normal transaction load, then perform a version upgrade following the vendor's documented steps, and restore the ledger and identity material from a backup into a clean environment. Record what broke, how long each step took in your environment, and whether rollback was possible. Note that Besu's Bonsai database auto-upgrades on first start and older versions cannot open it, so take and test a backup before any upgrade. Done means a pilot report with pass or fail results for upgrade, restore, failover and key rotation, and the staffing hours you actually spent.
Bring the evidence to the shortlist decision
Assemble one pack for the decision: the participant register, data classification, EVM and language requirement, fault tolerance table, release and removal record and pilot report. Add the questions that remain open, and assign an owner and a confirmation source for each one, such as the vendor, the project maintainers or your own security team. Vendor support, paid editions and any DeployOpen implementation scope should be quoted from written requirements rather than assumed. Done means a shortlist decision that names one platform, the conditions it depends on, and the open items with owners.
Questions buyers ask before hiring help with a blockchain network
What drives the cost of building a Fabric, Besu or Corda network?
The cost is driven by how many organizations join, how many nodes and channels or flows you run, and how much integration sits around the ledger. Services work is paid for by the hour or by fixed scope: design of the network and governance model, build and configuration of ordering or validator nodes, smart contract or CorDapp development, integration with your core systems, security hardening, and documentation. Recurring cost comes from upgrades, monitoring, key rotation, backups and the staff who keep the network running. Ask any provider to split a quote into one-time build and recurring operations, and to name who holds each role after handover.
Can our team run a blockchain network itself, and what skills does it need?
Yes, if you have engineers willing to own the stack long term. Besu and Corda run on the JVM, so Java or Kotlin skills matter, and Besu also needs an understanding of Ethereum execution and consensus clients. Fabric chaincode is written in Go, Java or Node.js, and operators need to manage the Fabric CA, MSPs and HSM-backed keys. Identity and key custody are the skills most often underestimated. Before deciding, list the people who will handle orderer or validator operations, certificate renewal, rolling upgrades and incident response, and confirm that at least two of them can do each task without outside help.
How long does an enterprise blockchain network take to deliver?
Timeline depends on the number of participants, how far each one's onboarding and approval process has to move, and how much custom code is required. Node deployment is usually the shortest part. The longer work is agreeing on governance, identity, permissioning rules and the business logic that goes into smart contracts or flows, and then testing the network with every party. Any duration should come from a written scope that lists the participants, the environments and the acceptance tests. The Fabric upgrade guide itself describes a rolling, four-step process, so ask how upgrades are scheduled around your change windows.
What does our organization have to provide for a blockchain project?
A consortium project needs more from the client than from the vendor. You need named participants with authority to sign governance decisions, infrastructure in your own cloud accounts, data centers or private networks, and a decision on who holds signing and node keys, including whether an HSM is used. You also need a change control process that every participant accepts, since a network upgrade touches every organization. Confirm these items before scoping, because missing participants or unresolved key custody are the most common reasons a fixed-scope plan slips.
Can a consultant help with licensing and governance decisions?
A technical implementation partner can explain how each platform's license, governance and maintenance status affects your build, but it cannot give legal advice or make the consortium's decisions for you. Apache-2.0 is the license for Fabric, Besu and Corda's open-source repository, and the Linux Foundation's LF Decentralized Trust hosts Fabric and Besu, which is relevant to how you document ownership. Governance questions such as voting rules, membership and data-sharing agreements belong to your legal counsel and the participants. Ask a provider which governance artifacts it will draft as technical inputs and which must come from your lawyers.
What should a written fixed-scope quote for a blockchain network include?
A usable quote lists the platform and the release line you will run, such as Fabric v2.5 or v3.1, Besu on a named release, or Corda 5, and the number of participants and environments. It should separate design, build, integration, security testing, documentation and handover. It should name the deliverables and acceptance criteria, the client responsibilities from the previous question, the support or upgrade retainer, and the assumptions behind each estimate. Ask what is excluded, how change requests are priced, and how upgrades to newer releases are handled. Fabric v3.0 removed Solo, Kafka and the legacy chaincode lifecycle, so the quote should state whether that migration is included.
What switching platforms later costs
The cost of moving a network after launch is rarely the software licence. The expensive part is that a ledger, its identities and its application code are all tied to one platform's design. Before you commit, price the exit as carefully as the entry. Moving a live network means migrating ledger history or agreeing a cut-over with every participant, re-issuing or re-enrolling identities, rewriting the smart contract layer, and changing every client application that talks to the network. Each of these needs people with the right skills, and the testing and sign-off that come with a financial network are usually the largest line items, not the code itself. The programming models differ enough that a move between them is a rebuild, not a port. Fabric chaincode is written in general-purpose languages such as Go, Java and Node.js and runs inside the execute, order, validate flow. Besu runs Ethereum Virtual Machine contracts, so Solidity logic and its tooling belong to the Ethereum ecosystem. Corda uses CorDapps, which pair states and contracts with flows that manage negotiation between participants over peer-to-peer messaging. Business logic written for one of these does not carry over to another without redesign, and the flow or endorsement logic is where most of the cost sits. Ask each vendor or community what a supported migration path looks like and whether it covers data as well as code. You can lower exit cost now by fixing your permissioning, identity and data model early. Write down who may join the network, which certificate authority or identity source issues their keys, which channels or private data collections hold which records, and how node and account permissions are assigned. In Besu, that means keeping the node permissions and account permissioning files under version control. In Fabric, it means documenting MSP definitions and the Fabric CA identity registry. A clear model makes it possible to move client applications and identities in steps. Confirm migration paths with each vendor or community before committing, and test a rollback with a real backup, not a planned one.
How DeployOpen scopes and delivers blockchain platform selection and implementation
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For enterprise blockchain platforms, we start from a written scope that reflects your privacy model, consensus requirements and maintenance horizon, then carry that scope through build, testing and handover.
How we scope
- Written scope names the platform, the network type and the participants before any work starts.
- Scope records privacy requirements, such as channel or private data design, and the ordering or consensus model you need.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We deploy the chosen platform into your infrastructure, with node, identity and certificate layout documented.
- Configuration covers node and account permissioning, key management and any hardware security module integration you specify.
- Security testing of the network, applications and APIs runs against the agreed scope before go-live.
How we hand over
- Handover includes architecture, runbooks, backup and restore procedures, and an upgrade plan for your chosen release line.
- Upgrade documentation covers the vendor's ordering-service migration and rollback steps, including pre-upgrade backups.
- Compliance readiness evidence is prepared for your assessors, who issue any audit report or certification.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can track vendor release lines and schedule upgrades in your maintenance windows.
- Confirm response expectations, upgrade scope and testing cadence in writing with your quote.
