RClassic or RNext? Why specialist maturity determines the right standard generation

An anniversary with a paradigm shift

20 years of BiPRO – this anniversary was at the heart of BiPRO Day 2026 at the Dorint Kongresshotel Düsseldorf/Neuss. With around 500 participants, over 40 speakers, and more than 300 member companies, the association has long become the central authority for digital standards in the insurance industry. However, alongside a retrospective, and artificial intelligence, another forward-looking topic dominated the presentations: the relationship between the established standard generation RClassic and the newer generation RNext.

For IT managers in insurance companies, brokerage firms, and software providers, this poses a strategic question: Which standard generation is the right choice for which purpose – and is "RNext replaces RClassic" even the right way of thinking?

What RNext does differently technologically – and what it doesn't

RClassic is based on SOAP and XML, RNext on REST/OpenAPI and JSON, supplemented by modern architectural principles such as Domain-Driven Design and Microservices. At first glance, this looks like clear technological progress. On closer inspection, however, this picture becomes more nuanced: SOAP is a mature, established technology with decades of practical experience – as is REST. The mere tech stack comparison of SOAP versus REST offers hardly any noteworthy advantages in itself, as long as the backend is not already working with the most modern technology. The real value of RNext therefore lies less in the protocol change itself, but in the architectural principles and the better connectivity to the broader API economy.

More decisive than the transmission technology is therefore another aspect: the specialist maturity of the data models.

Why RClassic often remains the better choice for complex specialist requirements

RClassic has mature data models that are established across all lines of business and the entire product landscape of an insurance company. For companies with deep, complex specialist requirements – with multiple services, numerous specialist functions, and a broad product variety – this is a decisive advantage. The standards cover scenarios here that have been refined over years in practice.

RNext cannot currently offer this specialist depth to the same extent. For many lines of business and product constellations, the coverage that RClassic brings, which has grown over many years, is simply missing. Those who operate an insurance company with a broad product range and complex business processes today therefore often still find RClassic to be the more practical basis – regardless of the fact that the underlying transmission technology SOAP/XML is "older" than REST/JSON.

A possible path forward: RClassic data models on RNext technology

Within the BiPRO e.V., there is intensive discussion about whether the strengths of both worlds can be combined: mapping the functionally mature RClassic data models onto the technological basis of RNext. This approach would preserve the decades of functional maturity of the existing models, while simultaneously opening up access to modern, API-based architectures – without companies having to sacrifice the functional depth of their processes for a pure technology change.

For IT managers, this is an important signal: the development may not be towards a complete replacement of RClassic by RNext, but towards a convergence – proven specialist functionality meets contemporary technical implementation. Those who keep this path in mind avoid hasty migration decisions that sacrifice functional capabilities for the sake of a pure technology change.

Why the topic remains relevant nonetheless

Even if RClassic is the functionally more mature choice in many areas, there are good reasons to engage with RNext:

• New fields of activity: For new integration scenarios, especially those with partners outside the classic insurance industry, RNext is often the more obvious choice. However, should the discussed convergence prevail and a common, functionally mature data model emerge that is used by both technologies, this distinction becomes less relevant: Then, the choice of standard generation would no longer be decisive, but the common functional basis on which RClassic and RNext are equally based.
• AI automation as a driver. Artificial intelligence was the dominant topic of the anniversary BiPRO Day. Automated, AI-supported processes can often be integrated into modern automation pipelines more straightforwardly with JSON-based REST interfaces than with SOAP/XML – provided that the functional coverage for the respective application case is already given.
• Young talent and recruitment. SOAP interfaces are no longer a familiar standard for many younger developers, which can complicate the long-term maintenance of RClassic systems. However, software development itself is undergoing fundamental changes: This argument is strongly rooted in traditional development paradigms, where know-how still largely has to reside in the developer's head. In the future, however, development will increasingly be AI-supported – and AI systems master SOAP, XML, and the associated frameworks just as reliably as modern REST stacks. The argument about young talent thus loses weight and should not be overemphasised.

Practical courses of action for insurers and IT service providers

Instead of a blanket "RNext instead of RClassic," a differentiated approach depending on the specialist application case is recommended:

• Specialist maturity before technology trend: For lines of business and products with high complexity and established processes, RClassic should not be prematurely replaced simply because the underlying technology appears newer.
• Deploy RNext specifically for new application cases: For new integrations, especially with partners outside the industry or in the context of AI automation, RNext is often the more suitable basis.
• Coexistence as the rule, not a temporary solution: Middleware solutions that can serve both RClassic and RNext in parallel enable both standard generations to be used where they play to their respective strengths.
• Actively follow the convergence discussion in BiPRO e.V.: The consideration of operating RClassic data models on RNext technology in the future could be the most strategically sensible answer in the medium term to the tension between specialist maturity and technological modernity.

Conclusion

A differentiated rather than blanket view of RClassic and RNext is worthwhile. RClassic still offers the more mature foundation for complex specialist requirements that have grown across many lines of business and products – and the pure technology change from SOAP to REST in itself brings little, as long as the backend is not modernised anyway. The really exciting development therefore does not lie in a hard switch, but in the possible convergence: proven RClassic data models on the technical basis of RNext. Those who carefully follow this discussion within BiPRO e.V. will make more robust architectural decisions for tomorrow.