Since all migrations are unique to a deployment, it is strongly recommended that the entire migration process be planned in advance.

Not all steps in the migration processes apply to every deployment. Follow only the steps which apply to the deployment being migrated.

Perform all steps in the migration procedure for every instance of each subsystem being migrated. Always follow the steps for migration in the order which they are presented in the manual, even if not every step needs to be performed.

Perform each subsystem migration as a separate migration. Wait until one subsystem migration is complete before starting the migration of the next subsystem.

On Linux and UNIX systems, make sure that the file owner (user and group) and the file permissions are correct when the file is copied between two instances. Also make sure that the target machine allows the file transfer.

While the migration procedure refers to extracting data from a hardware security module (HSM), no Certificate System tool can extract public/private key pairs from an HSM because of Federal Information Processing Standard (FIPS) 140-1, which protects the private key portion of an entry. Contact the HSM vendor for information on how to extract data from an old HSM. Extracted keys should not have any dependencies, such as nickname prefixes, upon the old HSM.

It is possible to change the names of migrated Certificate System subsystem instances, but greater care must be taken when extracting and renaming certain portions of the data. Because port numbers are stored in the server.xml file, which is unaffected by subsystem migration, port numbers can be changed between instances without difficulty.

All examples assume that the new passwords are the same as the old passwords.

The chmod command used in the examples have the permissions 00600 (octal, no sticky bit permissions, user read/write permissions, no group permissions, no other permissions). These are the recommended permissions, but are not required.

It is not possible to migrate TPS data from Netscape Certificate Management System 7.0 to Red Hat Certificate System version 7.1 or later.

The default key-splitting scheme used by the DRM subsystem in Certificate System 7.1 and later is not the scheme required by the DRM subsystem key recovery feature in previous versions. Currently, there is no way to migrate from the old key-splitting scheme to the new scheme. Therefore, DRM instances in Certificate System versions older than 7.1 cannot be successfully migrated to versions 7.1 or later.

In Certificate Management System 7.0, the RA subsystem was deprecated and replaced by the TPS subsystem, so it is not possible to migrate RA subsystems into Certificate System versions 7.0 or later. All RA request queues should be processed by the older-version servers into their existing CAs before beginning any CA migrations.

Certificate Management System 4.2 contained a third-party OCSP responder called ValiCert Certificate Validation Authority (VATM). It is not possible to migrate data in this component.

Certificate Management System versions 4.1 and 4.2 contained platform-dependent migration utilities to extract Certificate Server 1.0 data from AIX, HP-UX, Solaris, and Windows NT [Intel] platforms. No migration utilities are available to migrate data from Digital UNIX, IRIX, or Windows NT [alpha] platforms.