When adopting new technology, many leaders worry about “vendor lock-in.” While this concern is understandable, I find it more useful to shift the conversation towards the cost of change instead. I talked about that a little at the DPGA Annual Members Meeting in Singapore last year, and it’s time to expand on that.

These discussions often arise when organisations consider working with a new technology provider. Leaders recognise that new technology models require new management approaches. The move to on-demand cloud services, for example, isn’t just a technical shift—it also transforms how costs are managed. But resistance to change is often shaped by years of frustration, where past decisions (and sometimes limited market options) have constrained flexibility.

Learn lessons from the past rather than focusing on the risk of the new

Often these conversations emerge when discussing working with a new technology provider. There’s a recognition that new modes of technology require new management practices. The shift to on-demand cloud services is a change in cost management as much as a change in technology architectures. But it’s also a reaction based on years of frustration that past technology decisions (and perhaps limited markets) have long constrained organisations’ freedom to act.

Human biases often lead us to focusing on the risk of the new rather than learning the lessons of the past and moving forward.

That’s why it’s crucial to watch out for “Status Quo bias.” Ensure that you think about the risks you currently carry and the costs/inefficiencies that you currently face at the same time as the implications of change. Don’t let fear of the new blind you to the problems with your existing situation.

Think beyond binary blockers to change

Vendor lock-in is often set up as a binary–we’re either locked in or we’re not–whereas the reality is that it occurs to different degrees and in different ways: whether it’s expensive to extract your data from a particular flavour of cloud storage is a very different consideration to whether you’ve organised your operational model around a particular product’s description of “best practice.” And often what we think about as lock-in to a particular vendor, is really lock-in to an intermediary or an issue with the way a system has been customised for our use.

Use service design techniques to map all components. Map all the components of what you’re doing. This lets you anchor your cost of change thinking in the ultimate value to be delivered. Score the elements of your map on how hard they are to change vs how hard they should be to change. This visual mapping helps identify where real lock-in risks exist.

Build real visibility of how your services work

I remember well a conversation from my time in government where we were discussing the need for a simple API to be added to an existing system. We sat in the room with the firm responsible for the core software and the systems integrator who held the contract and operated the software. The product vendor agreed the change was relatively simple and could be completed in a matter of weeks. The integrator named the same price tag and timeline, but that was purely for a series of scoping meetings. The reasonable position was probably somewhere in between, but the real challenge (and source of cost) was our lack of visibility into what it would really take, and the contractual arrangements that we’d set up.

Don’t buy something you don’t understand. There are many aspects of your tech that are better bought than built, but invest in understanding what’s genuinely valuable about those pieces. This understanding will give you leverage in negotiations and help you avoid situations where you’re at the mercy of a third party’s assessment of complexity.

Recognise that the right trade-offs will change

At a very technical level, good cloud architects are used to considering the trade-offs between building a custom system up using basic components that are effectively the same across cloud providers (virtual servers, managed databases, storage) which requires software engineering effort but doesn’t commit to one provider or what might be an experimental (and therefore rapidly changed or dropped) service, and choosing a “higher level” service that is more bespoke, probably less reliable, but will let you spend more of your time on the direct service you want to offer or the experiment you need to run.

Set yourselves up to make changes over time. Your day one trade-offs are not your day 1000 trade-offs - can you create a team that will adapt as those trade-offs change? In a fast moving environment those decisions are made regularly, and in a disciplined software development organisation effort is made to ensure that courses can be changed – switching custom code out for open source alternatives or vice versa, switching to commodity components from custom ones where the use is stable enough to make longer commitments.

Change is about a lot more than your tech and suppliers

But thinking about the cost of change is also a prompt to think about it beyond the purely technical, and versus alternatives. How many of our staff are impacted if we change a certain user interface? What’s the cost of not changing?

Be multi-disciplinary. Your commercial team’s efforts to create flexibility can easily be undone by a technology decision that’s hard to reverse, or a design choice can tie you in to an expensive technology solution. Ensure people across disciplines are discussing the consequences of decisions before and while they are made. It works best when we don’t separate out technology costs from the rest of our work.

Looking at practical solutions

Certain aspects of your cost of change can be tested or calculated. We can test what happens to our software if we try to run it in a new environment, or switch off certain components. We can ensure we can make changes in appropriate ways: handling a database upgrade invisibly, while making a lot of noise about changes with real consequences for users.

When we think about the cost of change at both the whole system and granular levels we can consider mitigations in a balanced way: where is it worth investing in a proof-of-concept alternative to a system to deepen your understanding? where might you actively seek multiple suppliers in order to keep your options open?

GOV.UK Pay is a tool for reducing risk and cost of change. It allows organisations in the UK public sector to build their payment capabilities around a known and stable system that’s managed in the public interest. It doesn’t remove the need for commercial providers of the underlying card and payment management services, but instead it takes care of that complexity and the variance between different providers on behalf of teams running user-facing services. That makes it easier to consider having multiple providers in parallel (e.g. for different payment methods, or currencies, or to ensure resilience) and means that if you need to move from one provider to another there’s no technical work to do.

Finding balance

All change comes with a cost. While we can’t predict every change we will need to make, we can equip ourselves with a holistic understanding of where those potential costs lie. We can use that understanding to target our energy and investments, and revisit that regularly. Done right, embracing new technologies and new suppliers can be an opportunity to build the right flexibility in the right places.