Hydrogen’s hidden software market is worth Britain’s attention

British technology companies should treat hydrogen infrastructure as a potential market for software that manages the transition between fuels. Germany’s approved hydrogen core network makes that opportunity concrete, but does not establish its commercial size. My view is that the strongest opening lies in helping operators coordinate existing gas assets, conversion schedules and future hydrogen customers, provided suppliers can demonstrate value before large transport volumes arrive.

Key pointers

• Start with an operator’s conversion problem and budget owner before designing a hydrogen software product.
• Ask how asset records distinguish current fuel, planned conversion and approved operating status.
• Test whether existing systems can accommodate the transition before commissioning replacements.
• Compare incumbent software suppliers, specialist developers and integration partners against the same operational scenario.
• Tie development spending to funded projects and customer commitments.
• Require a business case that survives delayed hydrogen demand.

Germany exposes the transition problem

The revealing detail in Germany’s plan is a pipeline that could not be converted.

The regulator required the application to change because part of the JAGAL pipeline was still needed for the natural gas network. A new hydrogen pipeline had to be proposed instead. That is a documented collision between the requirements of the existing network and the proposed one. Bundesnetzagentur’s account of the amended application

For a software business, this is a more useful starting point than the headline investment total. It suggests a specific question to investigate with operators. Can their planning systems show what happens to existing customers when an asset is reassigned, and carry the resulting decision into schedules and asset records?

There are concrete projects against which to test that question. NaTran’s November 2024 account identified GRTgaz Deutschland’s involvement in converting a MEGAL pipeline between Medelsheim and Gernsheim, work between Waidhaus and Rothenstadt, and a new pipeline between Rothenstadt and Forchheim. These were stated project plans, not evidence that every section is now operating. Kernnetz project details

The opportunity I see is in managing coexistence and conversion. That does not mean assuming methane and hydrogen will share every pipe, or that adding a fuel field makes an existing system suitable.

Where British companies could earn their place

For UK software companies and engineering consultancies, Germany offers a specific overseas customer problem to investigate. It does not establish an equivalent British rollout timetable.

My strongest commercial hypothesis is that operators will pay for dependable coordination between systems before they pay for an entirely new hydrogen platform. A supplier should test that hypothesis across three areas.

Asset and conversion records. Propose a record that distinguishes what a pipeline carries today, what it is intended to carry later, and which engineering approvals remain outstanding. The acceptance test should be whether an operator can trace a proposed conversion back to its dependencies and authorised decisions.

Forecasting and scheduling. Demonstrate how a postponed customer connection or unavailable pipeline changes the proposed operating plan. Start by asking which decisions existing tools already support and where staff still reconcile conflicting information.

Metering and commercial reconciliation. Investigate how measured quantities, reserved capacity and contractual records will be checked against one another. Treat measurement suitability and settlement rules as requirements to establish with the operator, rather than capabilities a general software team can assume.

The commercial process is becoming more tangible. FNB Gas’s account of capacity reservations describes entry and exit capacity, a cluster structure and a standardised reservation process. Those are identifiable business records around which suppliers can investigate integration work. They are not proof of an unmet software requirement. Hydrogen capacity reservation process

A small British supplier should pursue a bounded assignment, such as checking reservation data against an approved connection schedule. It should expand only after demonstrating a measurable improvement in that workflow.

Connect the records before replacing the systems

An illustrative design would connect asset records and conversion plans with customer connection dates and capacity reservations. Proposed changes would pass to an operator for approval, with an audit trail recording what changed and why.

I would keep that initial service outside direct operational control. Its first job should be to identify inconsistent records and support decisions. Any move into controlling equipment would require a separate engineering and assurance case.

The buyer should name an owner for each input. Engineering owns the asset’s approved status; the commercial team owns customer commitments; the project team owns the conversion schedule. Those are proposed responsibilities to agree during procurement, not a description of every German operator’s organisation.

The critical demonstration is a delayed conversion. Ask the supplier to show which records become inconsistent, who receives the exception and how an approved correction reaches downstream systems.

Compare delivery approaches before supplier logos

The available evidence does not establish a verified shortlist of hydrogen software products. Naming familiar cloud or enterprise vendors would add confidence without adding proof.

Buyers can still compare several credible procurement approaches.

| Approach | When to investigate it | What the supplier must demonstrate | Main cost questions |

| --- | --- | --- | --- |

| Extend the incumbent system | Existing records and workflows remain usable | Fuel-specific changes, historical records and export work in the proposed configuration | Configuration, licence changes, testing and future upgrades |

| Commission a specialist developer | A defined workflow remains unsupported | Domain understanding, operator acceptance and maintainable interfaces | Discovery, development, assurance and ongoing support |

| Use an independent integration provider | The main problem is disagreement between existing systems | Reconciliation, exception handling and clear responsibility for failures | Interface maintenance, monitoring and change requests |

| Build with an internal team and open-source components | The operator can retain engineering ownership | Support arrangements, documentation and a credible handover process | Staffing, hosting, maintenance, security and exit |

These are editorial selection criteria, not verified product capabilities. UK providers should compete on the same evidence as international suppliers, including who resolves an incident after implementation.

Price the work rather than the infrastructure headline

The €18.9bn network estimate cannot responsibly be turned into a software market forecast by assigning an arbitrary percentage to IT. The evidence contains no software procurement total or basis for that calculation. Approved infrastructure investment estimate

A useful quotation should instead separate discovery, data preparation, interfaces, licences or hosting, testing, training, support and eventual handover. The buyer should also price its own engineering and operational staff time.

Require bidders to distinguish reusable product development from customer-specific work. Otherwise, an apparently attractive licence proposal may depend on a large integration programme whose maintenance remains unpriced.

For suppliers, the same discipline prevents speculative development from being mistaken for contracted demand. A funded discovery assignment is stronger evidence of a market than a large pipeline investment figure.

The strongest objection is that demand may disappoint

The case against this thesis is substantial. Hydrogen demand could develop slowly, projects could move, and existing software suppliers could accommodate the necessary changes. There may be considerable engineering work without a large new standalone software market.

The financing model explicitly anticipates limited early usage. KfW explains that initial customer numbers are expected to be too low for network fees to cover operators’ investment costs fully, which is why the amortisation account bridges the shortfall. KfW’s explanation of early revenue gaps

Timing is also conditional. FNB Gas says individual approved measures may be deferred where they are needed later, up to 2037. Implementation flexibility

That objection should change the product strategy. Build around decisions an operator must make during conversion, including delays and continued natural gas service. Do not make the entire business case depend on rapidly rising hydrogen throughput.

Even that approach needs a paying customer. Complexity creates possible work; it does not guarantee a procurement budget.

Editorial analysis

Britain’s most credible opening is to sell a demonstrable improvement in how operators manage a changing network.

I would favour a supplier that can show a conversion decision moving accurately through asset, project and commercial records over one presenting an expansive hydrogen platform without a funded operational use case.

The market could become large, but its size remains unproven. The immediate decision for a British technology leader is smaller and testable. Find an operator with a funded conversion project, agree one costly coordination problem, and establish whether the existing systems can solve it before building anything new.

FAQ

Does Germany’s investment establish the size of the software opportunity?

No. The regulator’s €18.9bn figure is the expected investment cost of the approved network, not a disclosed software budget. A software market estimate would need evidence about actual procurement scope and spending. Approved network investment

Does managing two fuels mean blending them in the same pipeline?

Not in the argument made here. The German plan includes converting existing natural gas pipelines and constructing new hydrogen pipelines. The proposed software opportunity concerns coordinating assets and responsibilities while those networks develop. Network construction and conversion plan

Should a UK business replace its existing asset software now?

My recommendation is to test the existing system against a specific conversion scenario first. Ask whether it can preserve historical records, distinguish planned from approved changes and exchange the required data. Replacement should follow a demonstrated gap and a costed business case.

What should a small British software company do first?

Seek a funded discovery assignment with an operator, engineering contractor or industrial customer involved in a defined project. Propose a narrow deliverable, such as reconciling connection dates with conversion schedules. Agree the data owner, acceptance test, support responsibility and handover terms before developing the service.

Sources

• Bundesnetzagentur — Hydrogen core network and detailed approval figures
• Bundesnetzagentur — Approval of the hydrogen core network, 22 October 2024
• FNB Gas — Hydrogen core network and capacity reservation developments
• KfW — Hydrogen core network financing and the amortisation account
• NaTran — Kernnetz project, 18 November 2024