Vendor lock-in: decide what is worth keeping before renewal

A renewal can be the right decision even when changing supplier would be difficult. The CIO’s task is to establish whether the organisation is paying for useful capability or staying because nobody can explain how to leave.

Vendor lock-in is the combination of dependencies that makes a change costly, slow or risky. Those dependencies may sit in data formats, integrations, contract terms, staff skills or the way work is organised. Some are the price of a valuable service. Others accumulate unnoticed until the renewal deadline leaves no time to test an alternative.

Treat the assessment as a choice between future operating arrangements. A cheaper replacement licence is only one part of that choice; so is the value the incumbent continues to deliver.

Find the dependency that sets the timetable

Begin with a business process that would have to continue through a supplier change. Identify its data, permissions, automations, external connections and support responsibilities. Then ask what would need rebuilding, relearning or renegotiating.

The slowest essential task may determine the exit date. It could be converting historical records, replacing a specialised integration or obtaining time from a team already committed to another programme. Put those dependencies in sequence. A migration plan that assumes every task can happen concurrently will understate the notice and overlap period the organisation needs.

Separate an export capability from an executable replacement. Exported records do not, by themselves, recreate the approvals, permissions and exception handling that made the original service useful. Equally, an export format that requires transformation is not necessarily a reason to stay if the conversion is understood and affordable.

Microsoft Power Platform’s solution model illustrates the distinction. Microsoft describes unmanaged solutions as development assets that can be exported and retained in source control. Managed solutions are deployed artefacts and cannot themselves be exported. Solutions also carry dependencies on other components and solutions.

For a CIO whose teams depend on Power Apps or Power Automate, that detail changes the renewal investigation: where are the source assets, who controls them and which dependencies must accompany a move? A package that can move between compatible environments does not establish that the workflow can run on a different vendor’s platform. Test that separate proposition.

Make the exit test small enough to perform

Choose one representative workflow with a meaningful complication: an attachment, an approval exception, a permission boundary or an external consumer. Reconstruct that workflow in a candidate destination or a controlled prototype, using suitable test data. The purpose is to expose the missing work, not to migrate the entire service before deciding.

In a hypothetical case, a team exports its customer records successfully but discovers that renewal approvals depend on undocumented automation maintained by a departing contractor. The data move is feasible; the operating process remains unresolved. A useful test would establish the approval rules, reproduce an exception and show that another member of staff can support the new implementation.

Judge the result by whether the business can complete and explain the transaction. Can users find historical context? Do the right people retain access? Can support diagnose a failed integration? Does the organisation have the rights and access it needs to keep the source material? Answers may justify replacement, a staged exit or a renewal with specific dependency repairs.

A failed test is useful evidence if it arrives while choices remain. It may reveal that a short extension and targeted remediation offer better value than either a rushed migration or a full new term.

Compare the next period, not the money already spent

Use a common planning horizon for staying and leaving. Include subscription or infrastructure charges, implementation, data conversion, parallel operation, training and support. Account for the business capability each option supplies. If the alternative omits an important function, show the cost or consequence of that omission rather than presenting the offers as equivalent.

Consider a simplified fictional three-year comparison. Staying costs £120,000 a year. A replacement costs £80,000 a year, with £90,000 of migration work and £30,000 of overlapping service cost. Staying totals £360,000; replacement also totals £360,000. The annual price difference alone would suggest a saving, but the stated transition costs absorb it over this horizon.

The example excludes taxes, financing, price changes and differences in business benefit. It assumes all transition costs are additional and counted once. If the migration work rises to £130,000 while other assumptions remain fixed, replacement totals £400,000. If the new service creates valuable capability, that benefit deserves its own evidence; it should not be smuggled into a lower cost estimate.

Show a range for untested work and explain which uncertainty could change the recommendation. Previous implementation spending is already incurred. The decision should focus on future cost, value and exposure, while recognising obligations that still have to be paid.

Renew with an explicit reason

Ask procurement to establish the applicable notice deadline, renewal mechanism, assistance available during exit, continuing access and the treatment of data after termination. Check the signed agreement and order terms for this service. Do not substitute another customer’s arrangement or a general marketing statement for those conditions.

Staying is defensible when the service performs well, the price is justified and the remaining dependency is understood. The renewal can include work to improve source control, documentation, export testing or internal skills without committing to an immediate move.

Leaving becomes more credible when the destination has passed a meaningful test, the transition is funded and the business accepts the operational trade-offs. Where cloud services form the critical dependency, develop a cloud exit plan before signing the next contract. That turns a negotiating preference into an option the organisation can actually exercise.