Cutover without replication

Method

Upgrade all databases to release 15.0 at the same time. A cutover without replication is common in small organizations for development or production servers. It may be used in larger organizations when you can schedule sufficient downtime.

Fallback

Base fallback on the amount of time needed to restore earlier databases. For example, if users need the system Monday at 8 a.m. and the restoration takes 8 hours, the validation test must pass by Sunday at midnight.

NoteRemember to include client fallback time in the calculation.

You can use dump database or bcp out before an upgrade to prepare for fallback.

Plan a way to capture transactions after cutover to be used in case of fallback. If you go into production and then need to fall back, you will have to restore all the transactions that occurred after the last dump/load.

Application test suite

For a development system, simple validation may be adequate. However, for a production system, the test suite must address both update correctness and performance acceptability.

See Chapter 6, “Ensuring Stability and Performance” for more information on testing.

NoteYou might want to validate over a long weekend, if possible.

Fallback after cutover

Consider making daily bcp dumps of the databases. You can then load the dumps into the earlier server to fall back. Keep in mind:

Bridging

There should not be any user impact during migration. The more stringent the validation test is, the less likely you will have bridging issues.

Environment

Be sure to account for any increased release 15.0 memory requirements that apply to your configuration. For more information, see:

NoteFor a production system, execute the performance suite during off hours.

Scheduling

For a development system, you may want to add a short period to the development schedule for release 15.0 issues.

For a production system, be prepared to postpone or fall back, if needed.