This is an interesting challenge!  I haven't moved it to a new server, but I did have to deal with a server name change on my development server.  Be sure to back up your CMS database prior to doing any of this!!!

I would shut down the CMS and other services on your old server and do the following:(I am assuming that you're NOT using the local MySQL db server as your CMS database!)

- Install the software on your new server with a custom install.
- Make sure you are connecting to the original CMS database.
- Select the option to connect to an existing CMS cluster and enter the name of your old CMS.
- Once the software is installed, run the Central Configuration Manager (CCM) on the new server.
- Stop the CMS.
- Right-click on the CMS and go to Properties.  On the Configuration tab, change the Cluster Name to the name of the new server.
- If the properties of any of the servers were changed from the default on the old machine, configure the properties of the servers on the new machine to match the old one.
- Restart the CMS and the rest of the servers.
- Connect to the Central Management Console (CMC).
- Go to Servers and delete all of the servers that point to the old server machine.


Now migrate the file repositories if they are on the original server.
- Copy the files from the old server to the same path on the new server.
- If the repository paths were changed in the CMC (for example, we change everything to a UNC path instead of c:\program files\...), you'll have to go to the CMC and make sure that the correct path to the files is set.  This is the MAJOR reason why you want to make sure that you have the old server up while you're moving everything.  If the file repository servers can't connect to the file repository path, they won't start and you can't easily change the path if the server's not started.

Test EVERYTHING to make sure it's running correctly prior to shutting down the old server machine!!!

I think that should cover everything. Good luck!

-Dell

A computer only does what you actually told it to do - not what you thought you told it to do.

You could use the Import Wizard to move the content of one BOE XI environment to another.

Essentially it extracts the content (Users, Groups, Folders, Objects, Security, Instances) from one CMS and Filestore and pumps it into the new BOE XI CMS envirnoment without too much trouble.

You can even take one environment out to a BIAR (Binary Archive file) and then import from the BIAR file into another environment. (Useful for DEV to TEST to PROD migrations)

Import/export works ok - especially Dev to Test to Prod.  However, if you haven't installed the Sep 2006 HotFix or SR2, exporting your whole system to a Biar file doesn't work correctly.  Everything will look fine in the CMC and InfoView, but none of the actual .rpt files will be there in the FileStore.

Tuesday night I had to follow the process I outlined above with our Dev report server as both of the drives in it were failing (fortunately, I was able to get the file stores off of it before they died completely!) and it worked like a charm!  It only took me a couple of hours and everthing was up and running correctly the next morning when folks needed to use it.

-Dell

A computer only does what you actually told it to do - not what you thought you told it to do.