From JBoss EAP 7.1 Migration Guide:

5.7.4. Migrating from Hibernate ORM 5.0 to Hibernate ORM 5.1
While JBoss EAP 7.0 included Hibernate ORM 5.0, JBoss EAP 7.1 now includes Hibernate ORM 5.1. This section highlights the changes needed when migrating from Hibernate ORM version 5.0 to version 5.1. For more information about the changes implemented between Hibernate ORM 5.0 and Hibernate ORM 5.1, see the Hibernate ORM 5.1 Migration Guide.

Hibernate ORM 5.1 Features

The Hibernate ORM 5.1 release includes many performance improvements and bug fixes. It also introduces the following new features and improvements.

In Hibernate Query Language (HQL), you can define a join to an entity, not just a mapped association.
In addition to providing the ability to load a single identity by identifier, the API now also supports loading multiple entities of same type by identifier by using the Hibernate native API Session interface.
This release offers improvements in CDI integration, including solutions to the issue that occurs when Hibernate attempts to access the CDI BeanManager too soon. For more information, see HHH-8706 and HHH-10477.
Previous releases of Hibernate interpreted all null column values for an @Embeddable to mean the @Embeddable itself should be null. In this release, applications can dictate that Hibernate should instead use an empty @Embeddable instance by specifying the hibernate.create_empty_composites.enabled opt-in setting.
When defining an Envers audit query, you can now refer across one-to-one and many-to-one associations.
For more information about the new features available in Hibernate ORM 5.1, see ORM 5.1 feature release.

Oracle Byte Array Mapping Changes

Previous versions of Hibernate mapped byte[] and Byte[] data to Oracle’s LONG RAW data type using the JDBC LONGVARBINARY type. Although Oracle continues to provide the deprecated LONG RAW data type for backward compatibility, Oracle advises against using LONG RAW and recommends users convert to the BLOB data type. For this reason, Hibernate now maps byte[] and Byte[] data to the BLOB data type for Oracle databases. However, to provide backwards compatibility with existing applications, this mapping change is limited to the Oracle12cDialect. Existing applications that use the Oracle12cDialect and want to continue to implicitly map byte[] and Byte[] data to the LONG RAW data type can enable this behavior by setting the newly introduced hibernate.dialect.oracle.prefer_long_raw configuration setting to true. The default setting is false, meaning Hibernate will map byte[] and Byte[] data to the BLOB data type.

Schema Management Tooling Changes

Schema management tooling changes are mainly focused in the following areas:

Unifying the handling of hbm2ddl.auto and Hibernate’s JPA schema-generation support.
Removing JDBC concerns from the SPI to facilitate true replacement for Hibernate OGM, a persistence engine that provides Java Persistence (JPA) support for NoSQL data stores.
The schema management tooling changes should only be a migration concern for applications that directly use any of the following classes:

org.hibernate.tool.hbm2ddl.SchemaExport
org.hibernate.tool.hbm2ddl.SchemaUpdate
org.hibernate.tool.hbm2ddl.SchemaValidator
org.hibernate.tool.schema.spi.SchemaManagementTool, or any of its delegates

A new set of RHAMT Rules should be added to address the app migration issues detailed above. Please let me know if you need further info for the "when"s and "perform"s.