Seperation between business logic and the technical realization of a system is always a good idea.
Regardless how well these both things are separated, you have still to refactor your project to use the current technologies.
There is always something to do. The migration from Hibernate to JPA needs some effort, because the HBM files have to be converted into annotations.
In real life we have not only to consider the framework and technologies, but also architectural decisions.
Also the global architectural style evolves over time. The funny thing here: it is not really an evolution - and more a circle.
So to stay tuned you have either try to follow the current architectural style or wait for about ten years to come in the next (forgotten)
hype. Sample from java space:
JDK 1.0 started with a native toolkit called AWT. The advantage should be: the applications are portable between different OS and
JDK 1.2 Swing was introduced, which is no more native :-). Reason: a common look and feel and more power was needed.
In the time of JDK 1.3 a native widget toolkit called SWT was introduced. It should provide a native look and feel for the given OS.
Now the question: does Eclipse look like a native application :-).
In 1990-1995 only HTML (ultra thin clients) are possible.
1995-1996: Applets are used for WebClients
2006-XXXX: Why not applets and webstart (JNLP) again? This requires the renaming of applets to something more soundful like "richlet" to generate a new hype for an old technology.
JDK 1.0: custom ASCII based protocols were used for the communication between applets and server
<JDK 1.1 CORBA ist state of the art. It is language and platform neutral
JDK 1.1: RMI was introduced. Is more lightweight than CORBA in Java space. It is heavily used.
JDK 1.2/1.3 CORBA were reintroduced because of platform neutrality. Application servers are using CORBA now.
JDK 1.4: ASCII based protocols (SOAP) are reintroduced - because of platform neutrality.
JDK 1.4/1.5 RMI was improved, so RMIC is not needed any more.
The REST-services become also popular :-).
JDK 1.0: Everything started with plain, lightweight java classes. They haven't a special name yet.
JDK 1.1: JavaBeans a "component" based development model was used. Tools like Java Studio provided a notion of wireing together different JavaBeans in visual way - without coding. Java Studio died because of lack of acceptance.
JDK 1.2/EJB 1.0: Serverside component model was introduced. It should simplify the programming model.
JDK 1.3/1.4/EJB 2.0: Second Edition of EJBs are introduced. Now it should be much more simpler.
Java SE 5/Java EE 5: EJB 3.0 were introduced now it is as simple as JDK 1.0. For more details see JDK 1.0 + Annotations :-)
Of course in every circle the overall quality is improved. But from the birt-eye view, you have only to wait for about 10 years, to rich the next hype of an already existing technology (of course reintroduced under another more "cool" name).