The best migration strategy for you depends on such factors as the cost of the effort, the type of business you do, the size of your databases, and available resources.
The following table highlights the advantages and disadvantages of each migration approach:
Approach |
Advantages |
Disadvantages |
When used |
|---|---|---|---|
Easy fallback to earlier release. You do not need to rebuild previous release databases. Minimal system down time. |
Can be complex in OLTP environments. Replication Server must be set up, requiring extra hardware and software. |
This approach is best for large 7x24 production databases, maintaining high availability, when:
|
|
Can be executed with minimal resource demands. |
Highest risk. Requires down time for critical migration tasks. Recovery can be time consuming in a production environment. |
This approach is good for resource-constrained environments. It is appropriate for large organizations only if you are able to schedule sufficient downtime, for instance, a long weekend. |
|
Low risk with low development overhead. Especially conducive to testing. |
May require additional resources—either more memory or a second system. Requires tighter coordination with application groups and database owners. |
If neither of the other two approaches seems appropriate, you can use a phased cutover. |
For more information on these approaches, see the following sections:
This migration guide does not cover other parallel migration approaches;
such as running two systems in parallel where you have to maintain
both the systems simultaneously, or transaction duplication where
you use one front-end to drive two parallel back-ends. These system operational
approaches include factors too site-specific to detail effectively
in this guide.
Whenever possible, upgrade test and development databases to release 12.5 first. Upgrade the production system after testing. See Chapter 7, “Test: Ensuring Stability and Performance” for more information about testing.
