A couple of days ago I mentioned some cutting over techniques along with a few pre-requisites in order to take advantage of the techniques.

The reason for the prerequisites is because, from the integration standpoint, these are techniques that are common when migrating or upgrading your apps or the underlying routing infrastructure (think cloud migration).

The first of these is the blue/green deployment model. As a refresher, you start off with your original service and the replacement service being fronted by a common gateway that can do traffic shaping. Then you slowly turn the knob from service A to service B, observe for any issues, and either turn back or all the way over to perform the cutover exercise.

This allows you to test and verify with real traffic, while limiting the exposure of your external users. It also means that your end users won’t know the difference.

I will caveat that this is also one of the most complex to pull off from two angles: the first is the underlying data, and the second is if there is any underlying data that is being injected in-flight.

The data must either be accessed from a common location, or synchronized between both old and new locations. Depending on the underlying data, how it is accessed, and the agreements in place, this could make this approach a non-starter.

The second is how reliant the application is on the underlying infrastructure. Gateways these days will inject headers and access keys/tokens to the app. Sometimes the app just verifies the headers are present, and other times it is dependent upon the data contained within. This can be remediated as a part of the refactoring required when the apps are conveyed, but only if you recognize that you cannot “lift and shift” the custom app into its new home.

cab