Look beyond the subscription
A valuable commercial service can be the right choice. The useful question is whether you understand its costs, dependencies and realistic exit options.
Where dependencies accumulate
A small dependency can become critical when nobody documents how it works. Review the whole implementation.
Supporting detail
- Data that cannot be exported with its relationships and attachments.
- Paid or restricted APIs and closed authentication integrations.
- Proprietary formats, workflow engines, plugins and page builders.
- Cloud-specific services, egress fees and undocumented deployment steps.
Open source can still lock you in
Source access helps, but an open-source platform can still depend on proprietary add-ons, a single hosting provider, one developer or an unsupported custom fork.
Test an exit before you need one
Export representative records, restore a backup elsewhere, rebuild a key integration and ask another qualified maintainer to follow the documentation.
Reduce dependence gradually
Prioritise the dependencies with both high business impact and poor portability. Use phased coexistence, acceptance criteria and a rollback path.
Common questions
Does vendor lock-in mean a product is bad?
No. A dependency may be acceptable when the value is clear and the cost of leaving is understood.
Does self-hosting remove lock-in?
No. Proprietary extensions, undocumented changes and specialist operating knowledge can still make an exit difficult.