Some context: Those classes are intermediate mapping classes and were never officially supported to end in model definitions.
In SDN 6 there is no need for those classes to exist because the Java driver's types will get directly converted into the target entities and their properties.
Furthermore we don't support generic aggregations in SDN 6 actively on the level of repositories or Neo4jTemplate. Those mapping abstractions orient themselves strictly on the given business entity definition.
You can see, that there is some work to do to migrate this but it is -depending if my interpretation is right- not impossible and in the end even a little bit cleaner.
You can make use of the Neo4jClient to issue Cypher statements and map the results.
The Neo4jClient will respect Spring @Transactional as the repository and the Neo4jTemplate would do. Also it brings a minimal fluent API layer on top of the driver API that gives you the possibility to define the mapping as needed for your nodes an relationships. Additionally you get access to the typeSystem of the Java driver if you need more information about a returned field.
I did the custom naming with the prefixed My... intentionally to show that you have the freedom to use your own, maybe even more business focused, classes here.