Pattern: Lift and Shift at the End

It’s important not to approach a cloud native transformation by simply attempting a full“lift and shift” of your existing system onto the cloud. But it can be smart to move some intact pieces of it at the very end

Lift and Shift at the End

Most of your existing apps have been re-architectured and moved to the new platform.Some old stuff remains, but it is stable and doesn’t change too often.

In This Context

Companies often first approach a cloud native transformation with the belief that it simply means migrating their existing system and processes onto the cloud. This is so common that it’s earned the name “lift and shift” and it categorically does not work if you try to do this at the beginning of a transformation. An organization has to change not only its technology but also its structure, processes, andculture in order to succeed with cloud native.When organizations do a lift and shift at the very beginning, they expect it will be a quick and easy project to execute, since the applications themselves do not change significantly. In most cases, however, it ends up being a large and expensive initiative requiring triple the anticipated time and budget. This is due both to the complexity related to the underlying platform and the new knowledge required for operating on the cloud. Such a painful experience may lead to delays or even total cancellation of the following refactoring initiatives.


Move functioning and stable legacy apps as-is from data centers to the new cloudn ative platform without re-architecture at the very end of the initiative.An organization has to change not only its technology but also its structure, processes,and culture in order to succeed with cloud native. Once the cloud native transformation is close to the end, however, it could be valuable to move any remaining parts of the old system to the new platform. This avoids the extra cost of supporting the legacy platform as well as gaining at least some benefits of the new platform for the old applications.At the end of a successful refactoring, when the last few, rarely changing applications remain, the team continues to refactor them all, ignoring the piling costs and few benefits coming from such refactoring.


You can retire the old platform, shut down the servers, and end the datacenter contracts.