Your management software runs in the cloud, documents are accessible and work is moving along. Then prices change, you need an integration the platform does not support, or the service no longer meets the business's needs. One question becomes important: how difficult would it be to switch?
Freedom of choice depends on more than being able to cancel a subscription. It depends on which data you can recover, how applications are built and what it would take to keep working elsewhere. Examining these factors before choosing a cloud service helps identify vendor lock-in: dependence on a supplier that makes change costly.
A platform may be easy to leave contractually but difficult to replace operationally. To assess the risk, separate three layers:
The contract cuts across all three: it defines what information can be recovered, what assistance is available and what happens when the service ends. Dependence may concern the infrastructure provider, the software vendor or the implementation partner. They are not necessarily the same organisation.
Consider a hypothetical example: a small business exports customers and orders from its management software as CSV files. The files open, but do not explain how to connect each order to its attachments and approval history. The export has succeeded; reconstructing the process still requires work.
A useful check starts with a limited set of representative data: examine identifiers, relationships, dates, measurement units, attachments and field meanings. Then try importing them into a test environment. Success means being able to use the information correctly, rather than simply obtaining a downloadable file.
A backup answers a different question too: it may let you restore the original service without enabling you to rebuild it on another platform. Recovery and portability need separate checks.
A managed database or a specialised cloud service can reduce operational work and accelerate a project. Rejecting them on principle can add more work and complexity than it removes. The Government Digital Service guidance on technical lock-in recommends balancing a service's value against the ability to change it.
For a small business, the useful decision is to make the trade-off explicit: what benefit do we gain today, which component would need replacing tomorrow and what effort would be acceptable? Every component need not work identically across every cloud. What matters is recognising where a dependency could constrain an important decision.
An application deployed in a container may still depend on a particular database, identity system or messaging service. Moving the application package does not automatically transfer those behaviours or the configuration that connects them.
Using multiple providers can be appropriate, but introduces more to manage: skills, access, networking, monitoring and costs. Before introducing a second platform, establish which specific problem it solves and how its operation will be verified. The number of clouds in use does not, by itself, measure freedom of choice.
For custom software, also clarify usage rights, source code availability and dependencies on third-party components. Different parts of a solution may have different licences and may not be transferable in the same way.
The European Data Act, applicable since 12 September 2025, includes measures to facilitate switching between data processing services. From 12 January 2027, switching charges, including data egress charges, are due to be removed within the scope of these rules.
This does not make the entire migration free: adapting an application, checking information and training users still require work. Scope, conditions and any exceptions must be checked for the particular service. On this article's publication date, 13 November 2026, the January 2027 change is still in the future.
For a credible estimate, separate data retrieval and transformation from application changes, rebuilding integrations and the period when old and new environments need to coexist. Include validation, operational handover and documentation updates.
Compare that estimate with the costs and benefits of staying. Switching may not make sense today but may still warrant preparation. Documenting a dependency also provides a stronger basis for deciding to keep it.
Choose an important workflow, such as viewing an order together with its documents, and check how it could be reconstructed outside the original platform. Use a separate environment and suitable test data: carrying out the check does not require changing the live service.
Record what works, what is missing and which changes are needed. Scope, responsibilities and success criteria are also central to AWS guidance on an exit strategy, developed for financial services. Its sector-specific obligations should not automatically be applied to every small business.
We can start with the systems that support your work and the integrations connecting them. We compare what can be exported with what you actually need to operate, identifying dependencies to examine before a new investment or a cloud migration.
Where changes are needed, we assess system integration, software adaptation or a gradual transition. Let's assess how transferable your solution is: the aim is to make a better-informed choice, whether changing or staying is the right decision.
