Switching developers? Here’s how to protect yourself from a vendor lock-in
Published on December 18, 2020
Last modified on March 19, 2024
Published on December 18, 2020
Last modified on March 19, 2024
Estimated reading time: 9 minutes
Choosing a developer for your website, webshop, app, or software is often compared to getting married—be it with a freelancer or a full-service development company, it’s a relationship that you just don’t rush into.
Software development in itself tends to be a long process already, and the partnership doesn’t stop once the system is finished and deployed. Ongoing maintenance and future updates all need to be taken into consideration, and the best person to do it is usually the original developer or team who built it in the first place.
Needless to say, a client-vendor relationship in IT is, much like a marriage, difficult and costly to separate once established—even more so if you find out that you’ve been locked in.
Vendor lock-in is often talked about in the context of cloud services, but it’s a prevalent reality in software development, too. It’s also sometimes called “client lock-in” or “proprietary lock-in”— either way, it refers to a situation where a client gets unwittingly stuck with their current supplier because the alternative of switching to another one involves unreasonably high costs or some significant interruption in the business operations.
It’s not that switching suppliers is an everyday thing in software development. Ideally, the development team you chose to work with right from the initial planning to the development of your system would also be your stable partner for your future needs, and you shouldn’t have to worry about getting locked in.
But what if you get in a position where the only way to save your project is by switching suppliers?
At 1902 Software, we’ve seen our fair share of companies who wanted to replace their developers due to various reasons—like slow response to small jobs, too many errors in the system, underperformance, too-often ignored emails, etc.—but found themselves unable to turn their project over to us without first going through a grueling process to get a full copy of their system (including the source code), disrupting their business, and sometimes also having to pay a hefty unexpected fee because of some form of lock-in.
In software development, vendor lock-in can look like one or more of these scenarios:
Sometimes, it’s only when the client is ready to switch to another software development company that they find out that the copyright for the source code and other project materials are actually owned by the developer. Even if they are given a copy of the source code, the lack of ownership can limit, and sometimes even prevent, them from further development or modification of their system—as a result, they will eventually have to start all over again with the new supplier.
If the website or webshop is built on a proprietary system that’s owned by the development company, the client is completely dependent on this company for any modifications, upgrades, or fixes—no matter how small they may be. And in case the client needs to change to another developer, they will have to start from scratch with another system as well.
This problem can manifest on a smaller scale, too, with proprietary modules installed in otherwise open-source systems. For example, even if your webshop is developed with Magento Open Source, it will still take some effort to switch to another developer if the webshop uses modules that are proprietary to your developer. In these cases, the client will then be required to pay for the modules either in full, or through a monthly subscription. Alternatively, the new developer will have to find a different module or custom-develop modules with the same functionality.
In another variation of the previous scenario, a system may be open source, but the developer may still refuse to share the source code because they claim to have made significant modifications to it, and now consider it proprietary software.
In some more petty scenarios, the developer may promise to provide a copy of the website but in reality it’s just a copy of the database, some XML files, and some images. That will not be enough for the new supplier to take over the continued support of the system. In this scenario, the client will either have to stay with their current supplier or more or less start all over again with the new supplier.
We have also experienced how a supplier deliberately sent an incomplete system (with missing source-code files) just to add hassle and to further delay the migration process.
To be clear, switching to another developer or software development company will never be as simple as a single file transfer. There will always be some time and effort involved in the coordination and passing on of project knowledge from the old to the new supplier. However, it shouldn’t bring such trouble for the parties involved and there shouldn’t be unnecessary costs or delays from the supplier’s end.
You should of course be vigilant in choosing a software developer for your project in the first place, so that you don’t find yourself in a difficult situation later. At the same time, however, it wouldn’t hurt to prepare yourself for the worst-case scenarios—right from the start of your collaboration with your developer, here are the things that you need to consider:
We recommend that you don’t get your hosting from your developer. Choosing to host with your developer means that all your site’s files will be on their server where they have full control. In the event that you want to change your supplier (developer or hosting), it can be difficult to ask for full access to your files and database since suspicions will arise that you’re looking for a new supplier. As a result, they might make it difficult for you to leave by prolonging the process or making excuses for not giving you the necessary access — after all, they don't want to lose a client.
If you host with a separate company from your developer, switching to a new developer is easy to do. You only need to contact your hosting provider and ask them to change your hosting account’s password and your previous developer can no longer access your system.
Along the same line, if you want to switch hosting providers, all you need to do is to copy your system to another hosting provider and update your DNS settings — without having to explain yourself to anyone.
You are not in the pocket of either supplier.
Carefully read your project contract or your supplier’s terms and conditions before starting the project. It should be clear that you as the client have full ownership of the source code and project materials, and that you get the original decompiled source code in case you decide to change suppliers. All these should be made available to you within seven working days upon your request to minimize business disruption as much as possible.
It often happens that clients with non-technical backgrounds leave everything up to their developer, including domain registration, hosting setup, etc. While your developer can certainly assist you with these things, make sure that at the end of the day, all credentials are with you and that all services, modules etc. are registered under your company name. This avoids complications with transferring account ownership down the road (not to mention the complications you might have if you are selling your company, your website, or webshop, when the buyer finds out that you do not have full ownership to all the digital assets).
Make sure that your developer informs you in case there are modules that need to be installed on your website or webshop to extend its functionalities. As much as possible, it’s better if the module is purchased by you (in your name) from a third-party vendor than if you use a proprietary module from your current developer. In case your developer has to build a custom module not available as a commercial version you can license, make sure that you retain ownership of that module even when you switch suppliers.
Note that when software development companies build software, websites, or webshops, they often reuse the same set of modules or libraries to save time. You cannot expect to get full ownership of these modules or libraries because the software developer would then have to redevelop these components again from scratch each time they do a new project.
Instead, make sure that you have the right:
If a software development company does not agree to these, get out of the door as fast as possible because you are heading for a lock-in!
At 1902 Software, you will always get full rights to the source code and related materials resulting from the development of your project. Right from the project planning stage, we already list all modules to be used in your website or webshop for your approval. We also ask clients to purchase all third-party products, modules, or services needed for the project under their names and simply grant us developer access so that we can work with them.
As mentioned above, we do have a set of modules and libraries that we reuse in our projects—but our clients retain the right to use, modify, and include these modules or libraries if they develop or change the website or webshop, either on their own or through another company or freelancer. They also have the right to transfer these rights to anyone who buys the system or company.
Although most of our clients tend to stay with us for a long time, the ones that do switch to other suppliers find it easy due to our seamless turnover process that’s designed to provide the least hassle to our clients.
At 1902 Software there’s no lock-in!
If you’re looking for a stable software development company, or a development team to take over a stalled software project, contact us today and see how we can help.
AUTHOR
Peter Skouhus
A Danish entrepreneur who owns 1902 Software Development, an IT company in the Philippines where he has lived since 1998. Peter has extensive experience in the business side of IT development, strategic IT management, and sales.