A Lift and Shift (according to Techopedia) is “a particular technique in software migration where an application or code base is taken out of one environment and placed in another environment, without significant underlying design change.” It often happens when a big company buys a little company, and wants to rehost or replatform the little company’s application. Or it happens in any company when they want to change platforms or move an application to the cloud.

Straightforward, right?

Sounds like a pretty straightforward operation. After all, you have a spec for everything you need to build, and the spec is the existing system. Many teams undertake a lift and shift without a design team, let alone any time allocated to Discovery.

But in our experience it takes more than developers to achieve the goals of a Lift and Shift. The reason is that developing functionality is expensive (because development time is expensive), even if the feature set is bounded and well-understood.

Save time and money by prioritizing the easiest work with the greatest return

As a Product Owner in a Lift and Shift, you need to prioritize the features that require the least effort and deliver the most value. How do you decide which features have the most value? The best way to do this is to go through a subset of the framework of Discovery, where you interview users to find out what they are getting the most value out of. And then you talk to the development team implementing the features to figure out what features are the most difficult to build and maintain. This leads you to a roadmapping and bundling process to determine what should be released, and when.

An opportunity arises with a Lift and Shift that you don’t have when you build a new service or system from the ground up. Because you have a functioning site, you can A/B test existing functionality to determine what changes when you functionally delete a piece of the system. And what’s more, you can do that test without building anything. You just turn off the thing that’s working in the existing framework for a few days or weeks until you can see the effect of not having that thing. If the effect is negligible, then that feature or function is a candidate for elimination. You can lift and shift without that feature, and forego building and maintenance. An even less invasive approach to the same question would be to review the historical stats before and after the implementation of the feature, to see whether it made a positive or negative impact at the time.

Lift and Shift hidden costs

A notable way that Lift and Shift is more difficult than de novo development is that, typically, a migration of users from one system to another is something that a lot of people need to know about and plan for in advance. Sometimes those people who need to plan are your users. (Even if you don't intend for them to notice a difference, you typically need to inform them in case they are using your system in a way that you didn't foresee, and that causes you to impact them. Many clients of SaaS scrape screens, for example, and details of the screenscrape may change in a Lift and Shift.) Sometimes the people who need to be informed are your operations and support staff. In the event that something needs to be planned for, it also needs to have a committed delivery date. Committed delivery dates have a very short page in the Agile development handbook, and there are handwritten notes in red pen all over that page. Budget extra time for anything that has a committed delivery date. 

When can we shut down the old system?

Maybe never. During a Lift and Shift, one of the project milestones is turning off the old system. After all, operating and maintaining the system has some expense. Our experience is that the time allocated to run the two systems concurrently is always underestimated, usually by *years* (not months). The reason it’s underestimated is that the proximal gain of thousands of dollars per month is always outweighed by the cost and risk of having to reactivate something that has been decommissioned, at significantly higher cost. But executives often fail to consider the cost of returning (or ‘rolling back’) to a system that has been superseded by a new one. Operational changes and complexities (like keeping old and new systems in sync), user goodwill, reputation of the operating team are all at stake when a rollback is attempted. Rollbacks usually don’t go well. As with committed delivery dates, we find again that product management with extreme attention to detail saves you money in the long run.

Staged execution

Many clients opt to roll out a Lift and Shift in segments, migrating users with the simplest needs to the new system before the other users, so that 

1. they can kick the tires of the newly live system with smaller impact
2. to smooth the support burden in helping users through the changes, if there are any
3. to delay the development of the most costly features, leveraging a bet that some requirements may disappear during the delay

We think that all of these are good reasons for staged implementation of a Lift and Shift, as long as they don’t introduce lots of new dependencies. A good scenario for such a strategy is when you have two tiers of service, and the lower tier is the larger earner for the company. You know you will have to migrate the simpler (lower) tier of service, but perhaps there is a chance that the higher service tier will be eliminated. Each user’s experience is independent of the rest, and so there are few dependencies. The users on the higher tier can continue to occupy the older platform while the users on the lower tier can be migrated to the new platform.

An example of a bad scenario for staged implementation of a Lift and Shift is when the cost and complexity of supporting two different user bases on two different platforms is quite heavy. 
During a staged implementation, not only is a good Product Owner necessary to facilitate, orchestrate and document interim process changes; but also a Design companion can be indispensable when there are discrepancies in user experience to redress and rationalize.

Identify the right team for the Lift and Shift

We often meet clients who estimate that a Lift and Shift can be done in half the development time as the original development, without product or design contributions. Our experience is that a Lift and Shift project is successful because of the functional savings that can be accomplished by a Discovery-type engagement phase early in implementation.

Conclusion

A Lift and Shift is an opportunity to deliver precisely the features and functions that your users need most, that have the greatest pay-off compared to their complexity. Doing this kind of assessment, and orchestrating a successful migration, are skills of an integrated product development team. Don't let the savings pass you by.