How product thinking accelerates lift-and-shifts
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.
