You don't have to go to the lengths you're talking about to get a decent installation set up from where you are right now. I would do this in a couple of stages:

 - set up DB2 on the new server, set up your DB2 database user etc., then move the existing databases over. Then simply point the current installation at the new location of the database. This can be done manually by editing the conf files, or just by rerunning the CLM setup and entering the new information.

 - work out which applications you want to run on what servers, and install appropriate apps of the latest CLM on your the new application servers. Just install, don't start them or anything yet. Don't even worry about names of servers yet.

 - install and set up a reverse proxy server. This server will provide a single URI for everyone to connect to, and then pass the calls to the appropriate back end server. Set up the proxy rules to pass the correct paths to the appropriate CLM app server. There are examples of how to do this in the jazz wiki, and this is the single most important step to having a scalable CLM system.

 - work out what URI you want to use for the whole CLM system, and set the proxy up to use this URI, with appropriate certificates etc.

 - work out which applications currently do not use this URI, and plan to perform a rename operation on those

 - now stop your existing servers, and copy your old installation(s) over to each of the new servers, putting the files into a separate temp directory

 - for each machine, starting with the JTS application server, perform a CLM upgrade or rename/upgrade operation. Use the old server file copy as the previous installation, and check the conf files after the upgrade to make sure that all the new locations are in the new app server file system. I like to set up the index caches in their own directories outside of the installation so that future upgrades are easier.

Note that once you have your proxy in place, it is possible to point it to the existing installation and do the rename on the existing system, however doing it on the new system means you have your old CLM to easily fall back to. Leave your old servers and the old DB2 server (including the backup files) intact until you have everything upgraded and tested out. If worse comes to worst, you can just drop the new servers and fire up the old ones again, and do over.Speaking of which, you can follow these steps and do a trial upgrade/rename using a completely different URI then blow everything away and do it for real once you feel confident.

There's no need to do any sort of export/import on anything - it will all still be there and linked up after the move.

**UPDATE**: the one other thing I would probably do (depending on how many users you have) is set up a separate LDAP server for the users, and point each of the applications to that central LDAP server. Make sure you use exactly the same uid for the users so that it will match up with the data that's currently in CLM. This will make user management across the multi server infrastructure much simpler.

You can do the LDAP and the DB2 changes as separate steps before or after the main move, however once again there's benefit in leaving your original install completely as-is so you can easily roll back if you need to.