Surviving and Thriving on a Lift and Shift Project
Published on by Dan Klco
Recently, while helping a colleague with a challenging project, I was reminded of my three least favorite words to hear when starting an engagement: lift and shift.
Once the flashbacks to nightmare projects of yore subsided, yet another reason for this project’s challenges were clear.
Lift and shift, for those fortunate enough to not be familiar with the term is a phrase used by salespeople and product owners to describe a project to move an application in its entirety to another platform. To the salesperson or product owner, this means “easy” after all something already exists, so just copy it, right?
If you are an experienced consultant or sales engineer, the hairs on the back of your neck should now be standing up.
Aside: I should preface this with this is my anecdotal experience, but I’ve yet to see a scenario to the contrary.
Why are Lift and Shift Projects Hard?
What is it that’s so challenging about “lift and shift” projects? Lift and shift projects share a few characteristics which make them challenging:
Legacy Peculiarities
Users are used to the behavior of the existing application (see Hyrum's Law). This can include whole business processes built off objectively bad application behavior because that's "just how it works".
Changing this behavior and the associated business processes is not in scope for a technology project. This means as you work on the lift and shift you will have to make architectural and implementation compromises to fit existing behavior instead of best practices.
Documentation Woes
Maintaining documentation is pretty much no-one's idea of fun. Keeping documentation up to date during the course of a project is hard enough, but keeping the same documentation up to date over the course of upgrades, bug fixes and enhancements over years of maintenance.
This assumes there ever was documentation. Often the initial implementation may only include user documentation or the documentation may have been lost since the implementation was completed due to organizational changes or user turnover.
Disconnected from Value
"Lift and shift" projects by definition aren't taking advantage of the new features of the new platform or improving the user experience. Therefore, the project is seen as more of a cost or complexity savings than providing customer value.
While there's nothing wrong with projects to save costs, this can make it harder to engage stakeholders who aren't interested in changing their business processes or tooling just to save the organization money.
Anti-Agile
As you are replacing an existing system, there’s generally not enthusiasm for the cost and business impact of running two systems. Thus at least at a leadership level, these projects are often planned as big bangs. Iterative, agile delivery of small units of functionally, as a contrast requires additional costs to run both systems and the disjointed experience of using both.
All of this inflexibility is antithetical to agile delivery as it strips the team of the autonomy to make decisions based on the state of the project.
Lift and shift projects are challenging, but after all, if our jobs weren’t challenging it could be done cheaper. So what do you do to maximize your chances for success in your lift and shift project?
Ways to Make a Lift and Shift Project Better
I’ve participated in several lift and shift projects, here is what has worked best:
Define and Document the Scope
Business Analysis or the rescue! By defining a scope and getting agreement to the scope from the business you have a definition of dive instead of an open ended commitment which could always be expanded.
If you have not already, make sure to understand the contract or Statement of Work (SOW). These scope definitions may require amendments to the SOW or could be handled as a part of the project delivery. But should be formalized in some manner.
Break Down and Deliver Parts
Paradoxically, given my previous recommendation is very waterfall-y, agile delivery is critical to delivering a lift and shift project. By delivering the work in multiple iterations, the team will have the chance to learn and improve. Even better, as the business sees the delivered product it builds confidence and familiarity with the new system.
Ideally, the business may even find that some of the critical requirements becomes less important as they understand the capabilities of the new platform.
Build Alignment
Ultimately, the success or failure of the project will come down to the business alignment on the need for successful delivery. Business Owners and other key team members may have many reasons to be skeptical or hostile to the lift and shift including fears of irrelevance, historical failures, or lack of a feeling of control. However, involvement in a successful project and learning new skills is a boost for everyone’s careers so in the end the most reticent opponents can be converted.
The implementation team should work closely with the account team to both woo and involve key customer team members to build a shared sense of responsibility for the success of the project. Early and often delivery of demonstrable progress will build credibility and critical confidence in the team and solution.
Wrapup
Lift and shift projects certainly have their challenges, but with awareness of the these challenges and working to remediate them, you can lift and shift even the most complex application successfully.