Moving Exec Backup to new server

http://www.symantec.com/connect/blogs/backup-exec-install-blog-upgrades

So, your backup server is a few years old and you find yourself in need of a newer, bigger, better, faster one. Just one problem, you want/need to keep your data from Backup Exec for compliance reasons. You have the perfect server that is ready to take on this new role. It is some new 64 bit monster with Windows 2008 R2, tons of I/O capacity, memory, disk space and more. Then you ask yourself, how do I move Backup Exec’s data from the old server to the new server and keep everything in working order? Time to check the technote database! So you head off to http://support.symantec.com and start doing some queries. You may find this technote:
How to migrate (move) Backup Exec from one system to another with the same version of BE, Windows and same or different computer names.
http://www.symantec.com/business/support/index?page=content&id=TECH67768
In the last 10 years, there have been many who have followed this technote, for just this purpose. When you start reading it, there are some bold statements, and some restrictions. However, lets first review some of the components this technote will cover.

1. The Backup Exec Database (BEDB).
2. The Backup Exec Data (Job histories stored on disk, reports, and more).
3. The Backup Exec Catalogs (Catalog folder on disk).

Today the SQL instance that hosts the BEDB is Microsoft SQL Server Express 2005 SP3. This version happens to be a 32 bit version when installed on either a 32 bit server, or on a 64 bit server. That is good news for customers who want to migrate from 32 bit operating systems, to 64 bit operating systems. That means there is really no difference in the database mounted on a 32bit OS, or a 64 bit OS, so you can carry it forward to a 64 bit OS without any compatibility issues. Furthermore, the Backup Exec Data and Catalogs on disk are files that are obviously transferrable between OS’s as well. The technote above is written to help move these three items between an old and new server. However, there are a few remaining items to consider.
One of the main items to consider is the configuration of the old and new server. The steps in the technote guide you through creating a matching configuration on the new server. If it is the same operating system as the previous install, then the same components and configuration items for that operating system will get laid down by the install. This should give a relatively similar configuration. The restriction at the top of the technote mentions operating systems of different versions. This is most likely for customers who tried to go backwards. Some examples where this would be broken would be:

1. Customer installed the Deduplication option on Windows Server 2008 (64 bit), then tries to move to Windows 2008 (32 bit). This option does not install the same on Windows 2008 (32 bit), so this will cause issues.
2. Customer has Microsoft Exchange (64 bit). Tries to move their data back to a Windows Server 2003 (32 bit) machine. Selections lists in the database would fail to protect these servers since they require tools that can only be present on a 64 bit machine. 

These are just a couple examples of how this could lead to possible compatibility/supportability issues. There may also be additional issues when migrating from 32 bit to 64 bit operating systems of different operating system versions, though I am not personally aware of any. I know of customers who have successfully migrated this way, but it not a supported upgrade path as is called out in this technote:
How to migrate Backup Exec to another server with a different Windows OS version.
http://www.symantec.com/business/support/index?page=content&id=TECH129826
There is also the added difficulty of having to move to a newer version of the product, and not being able to upgrade to the current version. Here is an example. A customer has Backup Exec 12.5 installed on a Windows 2000 Server. They would like to migrate to Backup Exec 2010 R3. However, Backup Exec 2010 R3 does not support installing on Windows 2000. In a situation like this, the only upgrade path is the following technote:
How to use BEMIG to manually upgrade the Backup Exec database from a previous version
http://www.symantec.com/business/support/index?page=content&id=TECH50537
Again this technote lists similar restrictions as the previous technote. Most if not all of the restrictions have very valid reasoning. Primarily because of the work that is done during the install, with respect to these items. The Backup Exec Installation will often make some database changes in coordination with the migration scripts. It’s a carefully orchestrated flow to carry the configuration forward to the new version. Trying the steps in the technote against a server that meets the restrictions will be hit or miss. Mostly depending on the database version being migrated, and changes made in each version of the product after that version. For example, trying to migrate a database that is from the 12.5 product, using the migration(BEMIG) scripts in our 2010 R3 release will yield failures when the “Shared Storage Option” is installed. This is because the install does some of the work, and the scripts do the rest of the work during the migration sequence. The only reliable way to get upgraded when you meet the restrictions is through operating system upgrades, and the supported Backup Exec Install upgrade paths. Now, if you don’t meet the restrictions, then you are essentially using the migration scripts in the newer version of the product, to migrate your database to the new version. This is the same sequence that the Backup Exec Installer uses to migrate the database between versions. However, you should also be careful that the old configuration and new configuration match as closely as possible. Doing so will save you many hours of frustration and issues that could be avoided!
Another question I received, asked about lingering server/devices post upgrade, that are un-removable in the Backup Exec 2010 UI. This issue may happen when migrating to a server with a different server name and different hardware. It’s a difficult issue to solve for our support team, and usually requires their intervention to fully remove. For this reason, it is recommended that you migrate to a server with the same name, and similar configuration. It saves many hours of resolving configuration issues when you do. If you decide change your server name, you will not be able to carry forward a deduplication folder, or its associated jobs. You may also decide to recreate your selection lists for proper viewing. There may even be more items you find needing your attention when you do. Save yourself the headache and keep the same server name. Follow the technote and copy the data to the network, take the server offline, bring up the new server with the same name, and finish followng the technote. You will be glad you did!