Migrating 6.x (Win) using readdb

Hi,

a DP6.11 installation on Win 2003R2 x86 shall be migrated to 2008R2 x8664 (and later upgraded to 7.03, think of it as preparations for going to 8.1/9.0). When reading up on the procedures documented to do so, most of them are involved and don't really fit what I had in mind:

• Migrate to a new machine with identical name, IP-address etc. The machine is rigged up in an isolated environment so nothing can go wrong;
• As part of the migration, move the installation from C:\Progra~1\OmniBack to a dedicated drive and directory (say O:\OmniBack);
• Get the machine into a state where it can be swapped with the old CM in a short time window, and have everything working as before.

The documented procedures try to port to a new CM under a different name and IP. Some modified versions use a new machine with same name/IP like I want, but make absolutely clear that changing the drive letter is a no go. Most procedures propose to do classic IDB maintenance (purge, writedb, readdb) before the migration just to be sure. Now the question I couldn't get out of my head was: When I already have the writedb dump, why can't I use that to migrate to the new 64bit system and leave all the winomnimigrate.pl madness alone? According to some postings here, writedb, reinstall and readdb is the only documented way to move the IDB to another drive letter - so why not base the entire migration on this?

I came up with the following steps performed on a test machine:

1. Install 2008R2 on machine with exact same name (it will end up in uppercase, but that isn't really a problem), domain name (so the FQDN is identical, botched that on first attempt) and IP address.
2. Install 6.11 (Code & Data) to O:\OmniBack
3. Patch up to the exact same state as the source installation
4. Create CDB extension files (using CLI or GUI) like on the source installation so the readdb will actually fit (this can be used to reduce the number of extensions if necessary)
5. omnisv stop, omnisv start, omnitrig -stop
6. Restore a writedb dump from the source machine using omnidbutil -readdb -cdb<cdbdumpdir>-mmdb<mmdbdumpdir>
7. omnisv stop
8. Rename O:\OmniBack\Config to something else
9. Copy Config directory from source installation to O:\OmniBack\Config
10. Create directories for DCBFs in O:\OmniBack\db40 as wanted (reflecting the number of dirs used on the source).
11. Copy source installation DCBF files over to these directories
12. Copy source installation MBF files over to O:\OmniBack\db40\msg
13. omnisv start, omnitrig -stop
14. Add the newly created DCBF directories (on O:) to Data Protector using CLI or GUI
15. omnidbutil -remap_dcdir
16. Remove old and wrong DCBF directory references from DP using CLI or GUI

After a final reboot of the system, the installation should be migrated to the new drive, directory, OS and architecture in a single step. On my test system, I don't see anything wrong with the result. I could also upgrade it to 7.00 and patch up to 7.03 b107 without a hitch. It's just still in an isolated VLAN and doesn't talk to anything but other test clients...

Am I missing something, or isn't that a way better way to migrate than all the involvment with winomnimigrate, specifically if you want to keep the name and address? Any issues others ran into after following such a procedure?

Thanks,

Andre.