...I couldn't have been more mistaken. The migration was a big deal. After working on a few of these projects, I can verify that the amount of moving parts in a machine composed of various portfolios, frameworks, third-party vendors, and a variety of stakeholders made the planning for such an initiative a formidable undertaking.
That's actually a pretty interesting article. Anyway, so it dawned on me that, on the lowest level, for example, the Sun Java System Application Server has a sun-application.xml file and JBoss has the jboss.xml file (and that all of these servers have one or more server-specific files that need to be migrated). Until this dawning of realisation, I had thought that the only question one would need to ask is whether a server supports a particular specification (e.g., J2EE 1.4) or not. So, even if you're dealing with two application servers that support J2EE 1.4, that does not mean that you're home and dry as soon as you've created Ant scripts and hooked them up to menus inside NetBeans IDE 4.1 (as I've been doing in my recent blog entries). For example, click here to see a recipe for frustration.
So you can imagine how happy I was to discover the Migration Tool for the Sun Java System Application Server 8 Download! Here's a nice summary of the various issues involved (taken from a 110-page document called "Moving from WebSphere Server 4.0 to the Sun™ ONE Application Server 7", which I found on the aforementioned Migration Tool's whitepaper site, and which, according to its summary, only "provides an overview"):
J2EE Application Migration Issues
The varying degrees of compliance to J2EE standards can make migrating applications from one
application server to another a daunting task. Some of the challenges when migrating J2EE