The runtime migration tools and documentation support the following three migration procedures: migrating stand-alone environments, migrating network deployment environments with full downtime, and migrating network deployment environments with minimal downtime.
The procedure for migrating stand-alone environments describes the steps for backing up the environment, migrating the stand-alone profile, and upgrading the product databases configured for the profile. The procedure contains variants for the different supported mechanisms of migrating a stand-alone environment including side-by-side migration, remote migration, and operating system upgrade migration. Before migrating a stand-alone environment, determine which of these variants fits your requirements best.
For instructions on using this procedure, see Migrating a stand-alone environment.
There are two different procedures for migrating network deployment environments that differ depending on the length of your downtime migration window. The full downtime procedure is the simplest procedure and is recommended if your downtime window can accommodate the migration. The length of the migration will depend on several factors including the source version, the number of cells, clusters, nodes, applications, and the amount of data in the database. To determine the length your migration will take use the full migration process in your staging environment. It is critical that you follow the network deployment procedure steps carefully and in the order they are listed to ensure that you successfully migrate your network deployment environment.
For instructions on using this procedure, see Migrating a network deployment environment with full downtime.
The minimal downtime procedure should be used if you are unable to accommodate the migration using the full downtime procedure for your migration window and you can accommodate the downtime required for the minimal downtime procedure or in scenarios where the amount of downtime required for the migration directly impacts your business. The minimal downtime procedure is more complex than the full downtime procedure and should only be used when the length of the downtime is critical. If you are not able to accommodate minimal downtime you should consider either the manual or artifact migration methods instead of the runtime migration method. The minimal downtime procedure involves splitting the migration into two groups and migrating one group while the other is still running minimizing the downtime for the cluster. The minimal downtime occurs just prior to bringing the migrated group of nodes online in order to update the database schema and the product data.
For instructions on using this procedure, see Migrating a network deployment environment with minimal downtime.
It is critical that any production migrations are thoroughly tested in a staging environment before they are attempted in a production setting. In addition, it is important that the backup steps in the procedures are followed carefully to enable rollback in cases where the configuration data or the applications failed to migrate successful to the target environment. Manual and artifact migration methods are often used in conjunction with runtime migration to validate that a typical application or all the applications can be deployed to a version 7.5.1 environment without issue or the applications can be migrated by the development tools successfully thus providing greater assurance that backwards compatibility for the application will be maintained. If you intend to migrate a network deployment environment, it is also helpful to start with a stand-alone environment in a staging environment to learn how to use the tools and the essence of the runtime migration process before using the more involved network deployment full downtime or minimal downtime procedures.