"Handing over software is not like handing over house keys." This is the opening phrase of our new episode of Law in a Nutshell ↗, in which we shone some light on the question linked to associated with the exit of the software solution, switching suppliers and service contracts.

Clients are more and more often entering the phase of "generational change" - a supplier has a solution that has been in operation for 10-15 years and now they are in the phase of deciding what will happen to it next, looking for a new supplier.

Do you have experience of looking for a new supplier? What are the things you need to look out for? How to prepare for the whole situation? These are the questions we discussed with our colleague Pavel Čech ↗.

The basis is the service contract

The document you should open in connection with the exit is the service contract ↗. This is the document that will govern how support, repairs, updates, or assistance will be provided.

So when you switch to a new supplier, it is the service contract that you will want to conclude or revise. However, you will also need to look at the development agreement (if there was one), as this is probably the basis on which the supplier developed the software for you. And, ideally, handed it over.

"Exit is dealt with in a situation where the cooperation with the supplier is functional. But we are puzzled by the thought, what if the supplier were to go out of business?"

Not sure if you have a service contract or if it contains everything you need? Do not hesitate to contact us ↗. Or take a look how we would write a service contract ↗.

In the podcast we illustrated the whole situation using the following example

You are a client coming to us and saying: "We have a major system here where we have all the data, if it doesn't work, we're out. We've broken up with the current supplier. What are we supposed to do? How do we prepare?" Or you come as a precaution, the relationship with the supplier is working, but you want to be prepared.

Exit plan

We focused on everything the client should resolve in the documentation and in the relationship with the supplier before the exit. But we started with the most fundamental thing - the exit plan.

"Wouldn't it be nice if all the interactions, the whole process that has to occur in the event of termination of the contract, was written down in advance?"

The exit plan describes the organisational prerequisites, the technological prerequisites and the timetable for what will happen in the event of an exit.

It's a non-violent way to start negotiating an exit.

As Pavel says in the podcast, "Just sit down at the table with the supplier and figure out what you would need to do if you wanted to change suppliers." 

How to handle the relationship with the supplier?

You can hear the answer to this question in the podcast. But be sure to remember the basic information that Pavel mentioned in the podcast, "The question with the exit is how much it's all going to cost."

How to set up the relationship to eliminate the risk of vendor lock in the future? What should be addressed in the documentation? What if you don't have a plan but already have a service contract in place?

You can play the full episode on these mediums:

   Spotify ↗        Apple Podcasts ↗        YouTube ↗

Would you rather read about the topic of exit?

We have also summarized the whole issue in a new article Exit of a software contract from the customer's perspective ↗.