Changing software supplier almost never fails on the program code. It fails because nobody has the password for the server, because the domain is registered to an agency that no longer exists, or because the application depends on a service whose invoice somebody else has been paying.
So the most useful preparation is not a solicitor’s letter but a list. What belongs to you, and what merely happens to sit with you?
Six items that change hands
The source code, with its full history. An archive from one day is not enough. The history explains why a passage looks the way it does and is worth more during handover than any documentation. Have the repository transferred, not a copy of it.
The credentials. Server, database, domain, certificates, mail delivery, payment provider, error monitoring. This is where it sticks most often, because such accounts were set up over the years on personal addresses at the supplier. Check this before you give notice, not after.
The route out. How does a change reach the server? If the answer is a script on one developer’s machine, that knowledge leaves with them. The deployment route belongs in the repository so that it can be handed over.
The dependencies that carry an invoice. Paid libraries, mapping services, text messaging, licence keys. Each of these has a contract and a payer. Where that payer is the old supplier, the service will stop working at some point, without warning.
The data in a readable form. A database dump in the database’s own format is good. An additional export of the important records in a format that opens without special software is better. It is your way back if the handover takes longer than planned.
The knowledge written down nowhere. Which nightly run must not be missed. Why one particular customer gets special treatment. Which part of the code is better left alone. An hour of conversation about that is worth more than a hundred pages of documentation.
How a handover runs
A sensible order creates certainty early and transfers responsibility late.
First the inventory: what is there, what is missing, what state it is in. That takes a few days and is useful even if you then decide against the move.
Then collect the credentials and move them onto accounts belonging to your company. Only after that comes the notice, because a terminated contract rarely increases willingness to help.
Next, one small but real change made by the new team, all the way to the server. That is the actual test. It shows whether the deployment route was handed over completely, and it costs almost nothing.
Finally the ongoing care, together with a list of what the new team will tidy up in the first weeks. That list should come out of the inventory rather than out of thin air.
Making the next time easier
The three things that take the sting out of a later change cost almost nothing at the start.
Every account is registered to an address at your company rather than at the supplier. The repository lives with you and the supplier is given access to it. And the contract says what is handed over when it ends, in which format and within what period.
A supplier who is happy with that is, incidentally, a good sign. Anyone who plans for a handover from the outset builds differently, because they expect somebody else to read the code.
Whether a change is needed at all can be checked beforehand. A software audit tells you whether the application is in a state that justifies the effort. Sometimes the finding is that the supplier is not the problem and the working relationship can be repaired instead. How a handover turns into day-to-day care is under maintenance and support.
