Yesterday I mentioned a few approaches that can be taken with transitioning applications. I also mentioned one approach that must be taken: the hard cutover.

In this case, if data and/or apps are being moved, you will need to swing things over at some point. Whether it is a full on import into your stack or switching a common place for customers to find your app. This is also perhaps the riskiest of the transitions. You can test as much as you like, but there is only one real production environment.

Another aspect of the cutover that is a fairly common pattern for migrations is the concept of “lift and shift.” The idea being you take an application from one place and migrate it to another place by “lifting and shifting” either the underlying servers it is hosted on or copying the software onto another server. Care must be taken as well as validating the software still works in the new home. You may be able to test this in the new world, but ultimately, it would be like deploying new software for the first time.

There is a secondary aspect to this approach, and that is the underlying data that powers the applications. The advantage to the hard cutover is the delay created from when you turn off one system and turn the other one on. This delay will allow you to synchronize your data one last time to ensure it is still consistent once everything is running in the new world.

There are a few drawbacks to this approach though. The most obvious is the downtime as the apps being moved will not be accessible. The second drawback is that rolling back isn’t really an option. While you could decide to shut things down and swing back to the original setup, you will have lost any transactions that happened post transition and will need to perform a manual cleanup. In many cases, so much prep will go into the act of cutting over that the fallback may not really be considered or tested.

cab