Hi Chris -

It is not safe to reuse a database in the way you suggest above (importing 3.X into a populated 4.X database). The import code will not remove what was populated for 4.x so you will end up with a mix of 3.X and 4.X states of data. Fortunately, it is also unnecessary. to do this exporting and importing as the repotools -addTables can convert a 3.X repository to a 4.X repository. Here are the steps I was thinking you'd take to update your staging server with the latest production data from your 3.0.1.4 environment, upgrading it to 4.X and flipping the DNS switch to make the staging environment the production one:

1) shutdown the 3.0.1.4 production server
2) backup the final state of the 3.0.1.4 production databases (jts, applications' repositories, data warehouse)
3) shutdown your 4.X staging server
4) update your 4.X staging environment teamserver.properties files to point to the final 3.0.1.4 production databases
5) run the repotools-jts -addTables and -upgradeWarehouse commands as well as the repotools -addTables commands for CCM and QM ie. repotools-ccm -addTables, repotools-qm -addTables
5) recreate all the indices in your 4.X staging environment ie. repotools-xxx -reindex all
6) do whatever DNS magic is necessary to ensure only the 4.X environment will respond to the Public URLs you established for your production environment
7) bring up your new production environment

I have done similar steps in setting up test environments but I have not done this in a production environment. Krzysztof - do you agree with the above proposed steps?

Let me know if you have any questions - thanks!

Gail