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.
Table 3-1 highlights the advantages and disadvantages of each migration approach:
Approach |
Advantages |
Disadvantages |
When used |
|---|---|---|---|
Easy fallback to earlier version, you need not 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 24/7 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 down time, 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 these sections:
This guide
does not discuss other parallel migration approaches; such as running
two systems in parallel where you must maintain both 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 verion 15.0 first. Upgrade the production system after testing. See Chapter 6, “Ensuring Stability and Performance” for more information about testing.
