Cutover Without Replication

The issues for the cutover without replication approach are described in the following sections:


Upgrade all databases to release 12.5 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 are able to schedule sufficient downtime.


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 back off, 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 7, “Test: Ensuring Stability and Performance” for more information on testing.

NoteYou might want to validate over a 3-day 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:


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


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

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


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

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