We’re currently migrating a large-scale legacy Hibernate project with 900+ HBM XML mappings to modern JPA, and we’re facing significant challenges with the transformation process. We’re seeking community suggestions and experiences on the best approach for handling this volume of mappings.
Complex bidirectional relationships not properly handled
Cascade settings and fetch strategies often missing or wrong
Custom type mappings not translated correctly
OneToMany/ManyToOne relationships losing important configuration
Scale Problem: Manual fixing 900+ entities is not feasible
2. Runtime HBM Transfer
Approach: Using Hibernate’s built-in HBM support at runtime
Current Status: Works when we set unsupported features to WARN level
Problem: We cannot run with unsupported features in production
Limitation: This is a temporary solution, not a long-term migration path for our scale
3. HBM to ORM.XML Plugin Research
Finding: Most plugins we’ve found indicate that “legacy HBM.XML to ORM.XML conversion is coming soon”
Status: No reliable, production-ready tools currently available for enterprise scale
Need: A working solution that can handle 900+ complex mappings
Our Requirements
Source: 900+ HBM XML files with complex entity relationships
Target: Either JPA annotations or ORM.XML (we’re flexible on approach)
Scale: Must be automated/scriptable - manual conversion is not viable
Constraints: Must preserve all mapping semantics including:
Cascade configurations
Fetch strategies
Composite Id preservation
Custom type converters
We understand this is a significant undertaking and are looking for practical suggestions from the community on how to approach this systematically. We’re willing to invest in the right tooling or approach rather than attempting something that won’t scale to our requirements.
I believe there is support for Hibernate ORM doing the HBM to orm.xml conversion and dumping that to files already. It uses the same code as that “Runtime HBM Transfer” you mentioned. So while the feature is experimental, it seems to work for you, and you technically would run it at dev time, not in prod, so probably fine if you check the files?
I have no idea how to use this though, because AFAIK it’s undocumented.
You could use HbmXmlTransformer manually in your app’s code like this and dump the resulting objects as XML files somewhere (JaxbEntityMappingsImpl is a JAXB-serializable object).
Thank you for your assistance with our HBM.xml migration issue. We are focused on migrating our HBM.xml files to JPA Annotations rather than ORM.xml for the following reasons:
Migration Strategy Considerations:
ORM.xml approach: Requires maintaining both ORM.xml mapping files AND POJO entity classes separately when schema changes occur, since there’s no ORM2Java tool available
JPA Annotations approach: Only requires maintaining the JPA Entity classes, simplifying our maintenance workflow
Current Challenge:
We can use ejb3='true' in Hibernate Tools to generate JPA Annotations, but many relationships and configurations are missing in the generated entities. We’ve searched online for tools that can convert HBM.xml to JPA Annotations but haven’t found comprehensive solutions.
Questions:
Tool Recommendations: Do you have any recommendations for tools or approaches to convert HBM.xml to complete JPA Annotated entities?
Hibernate ORM Release Cycle: We have several questions about the release lifecycle:
Why was version 7.0 released and then moved to EOL status?
Version 6.6 is currently in “Limited Support” - how do you determine when versions move to EOL?
Is our understanding correct that when Hibernate releases a stable version 8, then version 7 will move to Limited Support?
Some older versions remain in Limited Support - what’s the criteria for this?
For Limited Support versions, do security vulnerabilities get fixed, or only in Supported & Stable versions?
Planning Timeline:
If version 7 will be supported until FY26, we may not need to rush the HBM.xml transformation
Do you have information on when version 8 development starts?
How many minor versions does a major version (like 7.x) typically include?
Documentation Request:
Could you point us to documentation explaining the release cycle? This would help us understand when we need to upgrade Hibernate in our projects.
Any suggestions and guidance would be greatly appreciated.
By default, as soon as there is a newer stable version in the same major. So 7.0 is EOL as soon as 7.1 is out.
Some older versions remain in Limited Support - what’s the criteria for this?
Limited support is driven by corporate contributors. Basically if a group of contributors is making money out of Hibernate and volunteers to support an older version, that version is in limited support.
Community support comes without any guarantees in terms of timelines.
Thank you for answering most of my questions. I have a follow-up question regarding security vulnerabilities in Limited Support versions.
Security Vulnerability Questions:
Direct Security Fixes: If a Hibernate version is in Limited Support and a security vulnerability is discovered in Hibernate itself, does that get fixed and released for the Limited Support version?
Dependency Security Updates: If a Hibernate dependency (such as ANTLR) has a security vulnerability, does the Hibernate team update that dependency in Limited Support versions?
Security Response Process: Since Limited Support is maintained by corporate contributors or paid support, are security vulnerabilities handled differently compared to Stable versions?
Context:
We’re trying to understand the security implications of staying on a Limited Support version versus upgrading to a newer Stable version. This will help us assess the risk/benefit of delaying our migration timeline.
Specific Example:
If Hibernate 6.6.x (currently in Limited Support) has a dependency like ANTLR that gets a security CVE, would that dependency be updated in the 6.6.x branch, or would the recommendation be to upgrade to the latest Stable version?
Understanding the security maintenance policy for Limited Support versions will help us make informed decisions about our upgrade timeline.
releases may be delayed until a significant need arises;
bugs will only be fixed if they are considered significant enough or in the context of paid support;
pull requests against this version might be rejected for bugs that are not considered critical enough;
bug reproducers using this version will be given lower priority.
Obviously, a security vulnerability is a significant need which will usually result in a fix release. The latest stable version will also receive such fixes. Depending on the availability of upstream security fix releases for dependent libraries, dependency version update will be done.
One big advantage of commercial support though, is that Red Hat/IBM can also create custom builds for e.g. ANLTR with fixes, even if there is no upstream fix release for the major-minor version that Hibernate ORM uses.
In short, you should IMO always consider commercial support if your product requires stability. The alternative is to live on the edge and always upgrade to the latest stable version.