Your company has entered into a service contract for the maintenance of its internal ERP system, CRM, production management system, etc. While reviewing the contract, you found that although the cooperation with the supplier has been working well and swiftly for many years, you are not sure what would happen should the contract be terminated. Can you hand over the system to someone else for maintenance? Does the current supplier have to help you with this? And is it even technically feasible? What is your "exit plan"?
Exit and vendor lock
Exit is an often overlooked element of a service contract ↗. If your contract does not address it, your current supplier will not usually be obliged to assist you in any way with the transition to a new supplier. And it may not even be well possible, because you have already gotten vendor locked and you simply need your current supplier.
Causes of vendor lock
Vendor lock (i.e. dependence on a particular supplier) is a situation where you cannot simply switch to another supplier. At least not without incurring unreasonable costs or spending an unreasonable amount of effort.
Causes of vendor lock might be legal:
- Insufficient licensing rights. That is, a situation where you do not have the authority to service the software other than with the help of the original supplier. Remember that unless you agree to this, you are not legally entitled (with exceptions) to modify the software, nor are you entitled to the source code. Both of these are the very basis of exit.
- Closed software. Nowadays, no one creates software from scratch, but instead uses existing third-party programs. These can be directly part of the code or needed for its compilation (compilers). Special rules apply to the use of third-party programs. Or you may even have to buy them separately.
- Improper termination of contract. You need to be able to terminate the contract in order to exit. Ideally, so that the notice period is neither too long nor too short to select and train a new contractor.
- Lack of supplier cooperation. In order for a new supplier to take over your system, they will usually need help from the original supplier. And since the exit may not have taken place during a period of amicable cooperation (you probably parted ways for good reason), providing assistance should be a supplier's obligation, not an option. The cooperation can consist of training, handing over approaches, documentation, etc. The specific scope will always be differ from case to case and should be set in the exit plan.
The causes for vendor lock might also be technical:
- Technological debt. The contractor did not think about the long-term operation of the system during development and used temporary solutions that increase the cost of further maintenance. Or the system has not been updated for a long time, and it has become so outdated that it is no longer worthwhile to rewrite the entire system.
- The use of incompatible technologies. For the system to work, it is necessary to use technologies that only work in conjunction with certain products.
- Insufficient documentation. Lack of documentation. If the system is to be taken over by a new supplier, it will need sufficient documentation in addition to source code interoperability. This can be either at the level of the code itself (comments) or in the form of separate documents (list of software, description of its architecture, description of code generation, etc.). The scope of these documents will again vary (more on this below under documentation).
What if you have already concluded the contract?
Although the exit is important at the end of the service contract, it is most important to discuss it at the contract negotiation stage. But if you didn't get around to it then and are dealing with an exit in an existing contract, don't despair. A solution can always be found.
The ideal is to first determine what you specifically need to achieve. Do you need to change software or software vendors? Open a service contract and ask questions. Do you have sufficient licenses to take your existing data with you when you change software? What options do you have for exporting them? And how long do you have to use your existing software?
If you want to stay with your current software but are not happy with your supplier, can you change him? Do you have sufficient licenses to hand over the software to someone else for maintenance? If so, will your current supplier provide you with the necessary assistance and documentation that the new supplier requires?
How exactly do we help with exit?
You know what you want to achieve. We know what to look out for. We start by asking you the right questions. Together, we'll firm up how an exit can work, where your position is strong and where the stumbling blocks may lie. We'll review your current service contract and highlight opportunities to improve your position so that you receive better results.
Once we have planned a specific course of action together, we will help you communicate it with the supplier. We have a lot of experience in negotiating service contracts, so we can advise you on what is standard and where the limits are being crossed.
And because we focus on software law, we have contacts with the best software vendors. We can connect you with industry experts who can advise you on what to look out for and how much it pays to invest in an exit. You'll get a contrarian view of the vendor's arguments so that they can't lead you around by the nose. Contact us ↗.
What a quality contract should address?
If you're just negotiating a contract and need advice, you've come to the right place. We've compiled a list of essential exit-related points that you, as a customer, shouldn't forget.
And because each software is specific, we wrote the list in two versions. Because as a customer, you can't always get everything. For example, if you buy standard (boxed) software or SaaS and you don't have a very strong position, you usually don't get to see the source code and the ability to modify the software.
If you are comissioning a tailor-made software
- Assignment of copyright ownership - to make the software truly yours.
- Hand-over of all source code - you are not entitled to it automatically
- Code quality - from the beginning, ask for codes to be annotated, with history, etc. And if you don't understand IT, it's okay to hire outside supervision. Even on a construction site, you have a supervisor who oversees quality.
- FOSS components involved - not everything is custom developed for you by the supplier, where they help themselves with for example open-source components consider their licenses and whether they suit you.
- Carefully maintained documentation - both technical development documentation and user manuals.
- Transferability of traffic, if your software supplier runs the software (hosting, cloud) - especially for possible change of hosting and data migration.
- Consultations and training - you never know how smoothly a potential new supplier will be able to jump into the shoes of the original supplier. So negotiate a certain number of hours of work from the original contractor that you are entitled to at the end of the collaboration and fix their price. These hours can then be spent training your users or handing over and explaining the work to the new supplier.
- Support and maintenance - No software can be operated without regular maintenance, repair and updates. And the easiest way to support and maintain software is by its creator. So think about the cost and the length of time you can commit to the supplier for support and maintenance. There will be interference with the code, even in these areas - transferability, documentation, quality, assignment of property rights.
- Require a timeframe for problem resolution - The response could also be just an email, so "resolution" is the magic word you are looking for in the contract. Also demand regular updates that respond to security threats, changes in the environment in which the software is operated, and other external influences. Otherwise, your software will soon become obsolete and you will have to re-develop it for a significant budget.
If you are obtaining „just“ a license, or a software, which is provided to you as a service (SaaS).
- Price change - the terms of licenses, unless they are "forever", are subject to change. If you are unable to abandon the software, it can get really expensive eventually
- Time period for terms negotiation - if you have a short-term license, think about how far in advance you need to negotiate renewal terms and whether the time is long enough to switch to another solution
- Data - Generally, you will not get the source code, so make sure that you have at least all your data at the end of the collaboration, even the data that is not in the databases. And don't be fooled by the fact that the software is running on your own servers. That says nothing about the data being readable and accessible to you.
- In what format will the supplier deliver the data to you?
- Will he help with their migration? And what kind of migration will you consider successful?
- Backups - if you're dealing with data, who is actually responsible for the backups. Is it the supplier or you? How often are backups done and how many are kept. And can you request data recovery from a backup? If so, for free or for an additional fee?
- SLA (software availability) - How much time do you need the software to be available? 99% or 97%? In a calendar year or a month? And how quickly do you need the provider to respond to problems?
- Monitoring - if you laboriously negotiate an SLA, it's important to monitor compliance. Usually, a third-party service is used for this purpose, which continuously monitors the availability of the service and its outages.
- Obligation to update the software - the vendor should issue fixes for known vulnerabilities, issue security updates and similar updates. If the supplier provides an update to any other customer, the supplier should also provide you with the same update.
- Compatibility - a commitment that the software will be available and compatible with the environment in which you use it for at least some time.
Do you need help working out a service contract ↗ or a development contract ↗? Drop us a line ↗ and we'll take care of all the items mentioned above.
Exit plan
The culmination of your exit strategy should be an exit plan. It should be developed collaboratively by both parties and the final version should be agreed upon by both sides, just like any other execution.
The exit plan should detail at least:
- course of termination of cooperation,the detailed scope of the activities to be carried out by the contractor on termination of the contract,
- a timetable for each step.
Is your software solution ready for exit? Whether you are on the customer or supplier side, don't hesitate to contact us ↗.
