You're not unhappy with your agency. Until you want to switch.
Maybe because your business is growing, because you need different expertise, or because an acquisition is on the table. Only then do you discover that the domain name is registered in the agency’s name, that the code is only accessible to their developers, and that nobody knows exactly how the ERP integration works.
Suddenly your webshop turns out not to be quite as much yours as you thought.
That's vendor lock-in. And it happens more often than many organisations realise.
How does vendor lock-in happen?
Vendor lock-in usually is not the result of a single decision. More often it is the outcome of various technical and organisational choices that pile up over the years.
Each choice can look sensible on its own. But together they can make an organisation increasingly dependent on its current supplier.
Hosting and domain management
Only when you want to switch do you discover that the domain registration and the hosting are in your agency’s name. From that moment on, you are no longer the owner, you are a user.
That does not have to be a problem, as long as it is clear who owns the environment and the organisation has access to the systems the e-commerce platform runs on.
Dependency arises when a supplier uses its own software, infrastructure or licences that are not transferable. For example, when only the current supplier can carry out updates or has access to essential parts of the hosting environment.
Another agency cannot simply take the platform over. Systems first have to be migrated, replaced or set up from scratch.
Connections and integrations
E-commerce platforms are often connected to various systems, such as an ERP, PIM, CRM, payment provider or logistics partner. For B2B companies this is usually the most sensitive point. Customer-specific pricing agreements, configurators and ERP integrations are rarely standard, but custom work on top of custom work. That layer in particular is the hardest for a new party to understand, and therefore the hardest to transfer.
An agency may use its own connectors, middleware or technical solutions for this.
When those solutions can only be used or maintained by the current agency, dependency arises. In case of a switch, integrations may need to be rebuilt or replaced.
The more business-critical processes depend on these solutions, the bigger the impact of switching.
Vendor lock-in is not only noticeable during a migration. Dependency can also show up in day-to-day operations, when simple changes can only be made by the current supplier. That slows processes down and limits flexibility.
Ownership of code
Who actually owns the code your e-commerce platform runs on?
The code may, for instance, be managed in the agency's repositories, without the organisation having full access to the source code, version history and technical documentation.
When the code is not fully available or transferable, another agency will struggle to take the platform over. Moreover, the dependency is not only in the code, but also in the knowledge. When only one or two developers know how the platform is built, the situation becomes fragile. In case of illness or departure, changes slow down and releases get stuck.
The organisation may then have invested in developing the platform for years, while in practice having insufficient control over the technology the business runs on.
During an acquisition or due diligence, it suddenly becomes clear how much control an organisation actually has over its e-commerce platform. If the code is registered in the agency's name or is not fully transferable, that represents a risk for a buyer. It can have a negative effect on company value or lead to additional questions during the acquisition process.
Data
A migration lives or dies by the availability and quality of data.
Product information, customer data, orders, content and other important data must be fully accessible and exportable.
When data is missing, scattered across different systems, or can only be exported in one specific format, a migration becomes more complex.
In the worst case, data has to be restored, converted or rebuilt by hand before another party can take the platform over.
The less control an organisation has over its own data, the greater the dependency on its current supplier.
How it can work instead
Vendor lock-in is not an inevitable consequence of choosing an e-commerce platform. The way the platform and the collaboration with an agency are set up largely determines how much freedom you keep as an organisation.
An open-source platform such as Magento offers a solid basis for that. The source code is available, and organisations can decide for themselves where the platform is hosted, which parties work on it, and how the technical environment is set up.
That does not mean vendor lock-in is automatically ruled out.
Dependency can arise with an open-source platform too. For example, when accounts are in the agency's name and custom work can only be maintained by the original developers.
So the difference is not only in the technology you choose, but above all in the choices you make around ownership and transferability. Here is what that looks like in practice:
Hosting and accounts in the organisation's name
Instead of depending on a supplier for access to hosting, domains and repositories, these stay in the organisation's name. An agency can manage the environment, but the organisation always keeps access and ownership itself. That way a switch can happen without first having to build a completely new infrastructure.
Fully transferable code
When the full source code, version history and documentation are available, another technical party can understand, maintain and further develop the platform. Not because you want to switch tomorrow, but because transferability is part of healthy technical ownership.
Control over your own data
Product information, customer data, orders and content remain accessible and exportable. That way the organisation stays the owner of its own data and does not depend on a single supplier to access business-critical information.
Why we deliberately choose Magento
At elgentos we deliberately choose Magento and an open-source approach.
Not because open source automatically makes vendor lock-in impossible, but because it gives organisations the option to stay the owner of their platform, code and data.
We believe customers should stay with us because the collaboration delivers value. Not because leaving is technically impossible, unnecessarily expensive or risky. With our fixed-fee support agreement, Magento Total Care, the focus is on long-term collaboration and predictable results, not on billing as many hours as possible.
That is why we build e-commerce platforms that are transferable.
When an organisation grows, needs a different technical partner, or decides to switch for any other reason, that has to be possible without replacing the entire platform first.
The freedom to leave is, as far as we are concerned, a precondition for a healthy collaboration.
