A lift-and-shift is when a product, or suite of products, is moved from one tech stack to another. It could be a change in hosting, elements of underlying infrastructure, programming language, one or more third-party services, or a combination of some or all of these.
You may also hear them referred to as migrations, replatforming, or upgrades with an assigned version number (e.g. v2).
They are commonplace in tech. Organisations who manage to avoid them seem to be the exception. They are significant, and require a lot of thought, people, energy, planning, and, of course, time.
This article explores why they come around as often as they do, what organisations can do to soften impact, and how product management skills and techniques can help to successfully navigate them.
Why are lift-and-shift exercises so commonplace?
🌐 Tech moves on
Much like user needs and the marketplace in which we operate, the technological landscape rarely stays still. The choices you made when you built out your MVP may no longer be the best choices. The languages you selected may prove more difficult to hire for. Your tech stack as a whole may no longer be the most cost efficient or performant.
📆 Commercial agreements pass their use-by-date
Those who have a heavy reliance on third parties - particularly those who outsource to managed service providers, or other wide-reaching systems - can often find themselves at risk of vendor lock-in, drowning in inertia. They can up their prices. They can up the friction. They can retire products. They can go out of business.
🆕 Change in leadership or technical direction
A new senior hire or a change in ownership often results in a burning desire to make changes, and platforms and languages are rarely safe from the eager, enthusiastic gaze of a new CTO, or the impositions of a new bureaucracy-laden FTSE100 org.
Fictional New IT Director: “Our OKR for 2024 is to move off Java”
📈 Scale
The best of all the reasons, and possibly the only one I’d welcome with open arms. If your MVP start-up tech stack begins to creak, you’re probably doing something right, but addressing this is critical all the same.
We recently helped Risksmart, a Manchester-based regtech startup, rapidly redesign, develop, and launch a ‘version 2’ of their state-of-the-art risk and compliance management platform in 10 weeks, enabling them to migrate their early customers off their MVP, and onboard new customers, faster. Read more in our Risksmart case study.
How to make them easier
📚 Diligence and discipline
Boring, I know. But you can avoid lift-and-shifts - or at least defer them and make them a lot easier - by taking this threat seriously. You could argue these are more technology and procurement concerns than those of product managers, but ignore these at your peril:
- Your tech stack
- What technologies do you use?
- What versions are you on?
- How far behind the latest versions are you?
- Are any technologies at risk of becoming obsolete?
- If we started again, would we choose something different?
- Commercial agreements
- What external dependencies do we have?
- Which hinge on commercial agreements?
- When do they expire?
- How much do they cost?
- How healthy are our supplier relationships?
- Are any at risk of becoming obsolete?
- If we started again, would we choose something different?
- Volume and performance metrics
There are two schools of thought here:
- Build for scale from the off
- Don’t build for scale, and cross that bridge if and when
I’ve seen both and I lean towards the latter, but either it's still sensible to ask yourself these questions from the off, and regularly review and update the answers:
- How much volume can your current tech stack handle?
- What are your current volumes?
- What is acceptable performance?
- How long until you hit your limits?
- What will you do when you hit your limits?
🤝 Don’t over-outsource
Perhaps somewhat ironic coming from the co-founder of a tech consultancy, but I’ve seen many organisations box themselves in a corner by handing off too much of their estate to managed service providers or wide-reaching third-party components, or by not maintaining enough of an in-house product engineering capability.
Perhaps the most difficult balance to strike, but without monitoring and capping these variables, it's easy to get stuck in a pattern of regular lift-and-shifts. Our team augmentation service may help here - where you're looking for a lighter touch approach to bolster your delivery capability over the short-to-mid-term.
And how to soften the impact of lift-and-shifts?
📣 Be open and transparent about what and why
What is the driver for the lift-and-shift? If it’s to ensure that you can grow as per your forecasts, then say that. Make it clear. Reference those metrics that emphasise the challenges you’ll encounter if you don’t do it.
But also be clear on scope. Is it your entire tech stack? Is it just one specific integration? Is it solely a move from language A to language B?
As ever, clarity and focus is key.
⏳ Realistic timelines
To be clear: lift-and-shifts are rarely completed in months. Quarters: maybe. Years is the usual currency. It’s okay to set aspirations, but be very wary of putting a hard and fast deadline in place, unless of course the commercial or organisational landscape necessitates this. Even then, I can’t stress enough how important it is to use those core principles of product development to derisk:
- Ruthless focus and prioritisation
- Delivering a viable product at the earliest possible point
- Regular, short feedback loops
And have a plan B in place if that date isn’t met. And a plan C whilst you’re at it.
👥 Dedicated teams
Without having one or more dedicated teams focusing on this, it will take longer, and quality will likely slip.
You could create dedicated teams solely for the lift-and-shift, or - and my preferred approach - have established teams pick up the elements of the lift-and-shift within their gift.
And it’s okay for the team to work on other elements alongside the lift-and-shift. In fact, I would encourage this. Yes, there’s an argument that this could lengthen the exercise, but that effect is wholly countered by the boost in morale that variety brings - not to mention the positive impact teams can have on their products and the wider org as they make improvements to them alongside their lift-and-shift contributions.
🗣️ Regular comms
It’s too easy not to do this. Make sure you give lift-and-shift work the visibility it warrants. Remind people why you’re doing this. Make it simple to see the progress your making: if there are six repos that need to be rewritten in another language, report your progress as “two out of six”.
As ever, if in doubt, overcommunicate.
🤹 Central coordination
Often one of the biggest gaps - particularly in newer organisations - is somebody who can pull this together. A lift-and-shift that doesn’t span multiple teams is a rare thing indeed, so having somebody who can bring alignment and focus is vital. This could be one or more dedicated delivery leads. It could be a working group formed by members of the teams involved, or “heads of” and “principals” from outside of the teams.
🔄 Breathing space with third parties
Be crystal clear on the commercials here: When do you need to get off their products? What happens if you don’t? Ensure that you have contingency in place, even if that triggers financial penalties.
🌊 Don't boil the ocean
It can be tempting to roll in improvements alongside the lift-and-shift - either as sweeteners for senior stakeholders (“it’s not just a lift-and-shift - it’ll unblock features a, b, and c for us”), or whilst in the process of working through the changes themselves (“well we’re in the same area, so we might as well do that error handling overhaul we talked about last month”).
Don’t be fooled by this.
Do everything you can to decouple improvements from the core work. Yes, there will be some instances where you can score wins, but other than perhaps getting rid of features or code, they should be the exception.
🎁 Deliver it properly
If you can deliver iteratively - and you almost always can - then you should. It is the best way to reduce risk bar none. Slice the work up like you would anything else, and deliver it in discrete chunks. Not only will this help you deliver value earlier, but it will also help you track and show progress as you go.
Two other approaches which can significantly derisk are beta testing and the strangler pattern:
- Beta testing
Run the new elements of your tech stack alongside your legacy elements. You can do this with or without user awareness, but it’s another great way of rolling out changes in a controlled manner to help you minimise risk and monitor performance ahead of switching all users over, all the while surfacing that additional value early and often.
How the beta phase works, from GDS
- The strangler pattern
Where you can do the lion’s share of the lift-and-shift work and put it into production whilst insulating some or all crucial integrations or touchpoints. This is another great way to de-risk as you go. This also has applications beyond software development - you can change elements of a service - even offline elements - all the while keeping external touch points the same.
An overview of the strangler pattern, from AWS
So how does a product mindset help?
🎯 Focusing on outcome
It can be a bit of a morale sapper, but even if the outcome is “no reduction in service”, this is still something you can measure and work towards. Ideally, the outcome also serves up some improvements that, again, you’re able to call out, measure against, and rally around. Is it savings in operational costs? Performance improvements? Maybe trimming away some unused elements of your products as you go may give you a better experience.
🗺️ Visualising the work to be done
“We can’t see the wood for the trees” will be felt even if nobody actually utters the words. When you’re in the midst of it, and you’re dealing in quarters rather than weeks and months, it’s very easy to lose sight of the big picture. Not only can the why be elusive, but oftentimes the what can slip away also. Story maps or high-level architecture diagrams can be highly effective here at outlining exactly what the breadth and depth of the transition is, whilst providing a perfect one-page view of where you’re up to, and what comes next.
🚫 Visualising the work NOT to be done
This could be a parking lot next to your story map or high-level diagram. It could be part of your story map where you include things and then cross them out. Being explicit about what won’t be done can be one of the most powerful, impactful mechanisms that there is, and can avoid no end of confusion and frustration in the process.
🧩 Breaking the work up into chunks
Many product people excel at ensuring work is delivered in small increments - there are many, many reasons for this. To shorten feedback loops. To derisk. To deliver value as early as possible. To instil confidence. To enable agility. There’s no reason at all why this shouldn’t be applied to a lift-and-shift.
🍰 Slicing into releasable deliverables
A solid understanding of the wider organisation can be incredibly helpful here. Balancing potential disruption with risk minimisation isn’t easy, but having awareness of sales, ops, customer experience, and a deep appreciation of customers can really help when deciding how best to roll out wide-reaching changes.
🕵️♂️ Championing technical discovery
It may sound counterintuitive, but those with a good product head on their shoulders are probably the best advocates for any kind of discovery, including technical discovery. Are there different options that could be unpicked using spikes or proofs of concept? How else could you creatively derisk earlier?
🚧 Unblocking the team(s)
This is par for the course for me in any product team, but given that there may be a little less traditional product management to do whilst a team works on the typically more technical work that a lift-and-shift entails, one of the best ways to make an impact may be to plough the road. To remove the obstacles. To muck in.
📢 Communicating progress
Be it weeknotes, show and tells, or something a bit more formal and rigorous, product people are usually well versed in sharing and aligning. This can be all the more critical for something as potentially disengaging as a lift-and-shift.
Whether it's helping to keep the team pointing in the right direction, aligning with other teams, keeping stakeholders and the wider org up to date, or managing upwards, comms is another area where we can really add value.
🛡️ Supporting organisational readiness
Comms - and particularly show and tells - will help here, especially if there is a significant change in user experience as a result of changes. This is often where a product manager’s appreciation of customer and internal user touch points, as well as the wider organisation, can really pay dividends.
In summary
In the fast-paced world of tech, lift-and-shifts are much more than the name suggests. From tech advancements to shifting commercial landscapes, the reasons behind these moves are many. To stay ahead, organisations must embrace diligence, discipline, and above all else, focus. The fundamental skills that product people bring to the table can and should play a pivotral role here.
