Changing software vendors without losing the system

Deciding to change vendor is rarely the hard part. By the time the question is asked out loud, the answer is usually settled.

What goes wrong is the sequence. A change of vendor handled in the wrong order costs months, and in a few cases costs data. Handled in the right order it is an ordinary project.

Before anything: two facts to establish

What does the contract say about notice and renewal? This determines the calendar of everything else. A missed notice window commits you to another full term of an arrangement you have decided to end, and it is the single most expensive administrative oversight available in this situation. Many contracts also allow mid-term termination against an indemnity that is smaller than the remaining term, which is worth comparing rather than assuming.

What do you actually hold today? Not what the contract says you own: what is in your possession. The source code, in a repository you control. The credentials to hosting, domains, certificates and third-party services. Up-to-date operating documentation.

If the answer is “the contract says the code is ours”, you hold nothing. A clause without a transfer has never restarted a system, which is the whole reason the exit is negotiated at signature rather than at departure.

The six steps, in this order

One. Secure what is yours, while the relationship is still normal. Ask for the export the contract provides for, as a routine matter rather than as a signal. Ask for the credentials to be transferred into accounts in your name. Ask for the deployment documentation. These are all reasonable requests inside a working relationship, and they are difficult requests inside an ending one.

Two. Verify what you received. Open the export. Deploy the code somewhere else, or have somebody do it. This is the step that gets skipped, and skipping it means you discover the gap after the announcement, at the moment you have no leverage at all. An export that produces an unreadable file is an export that did not happen.

Three. Agree the transition terms in writing. Number of days of assistance, at what rate, over what period, and who the successor contact is. Doing this before the announcement makes it a commercial conversation. Doing it after makes it a favor.

Four. Announce, plainly and without grievance. Whatever the reasons, the outgoing vendor still holds knowledge you need for a few weeks. A departure conducted with courtesy gets you a better handover than a departure conducted as a verdict, and this is true even where the grievance is entirely justified.

Five. Run the two systems in parallel, briefly. Long enough for the new arrangement to prove itself on real work, short enough that nobody has to maintain two of everything. This is where the incoming vendor earns their fee, and where you find out whether the documentation was real.

Six. Close the old one deliberately. A written confirmation that access has been revoked, accounts closed, and any remaining copies of your data deleted. This step exists because it is otherwise never done: a vendor relationship that simply stops leaves credentials live and data sitting somewhere, sometimes for years.

The step that must never be skipped

Step two. Verification.

In our experience of being the incoming vendor, this is the step whose absence costs the most, and it is skipped almost every time because it feels like paperwork on a decision already taken.

Everything else can be recovered from, slowly and expensively. A migration launched on the belief that you hold a working copy of the system, when you hold an archive that does not build, is the one failure mode with no recovery path except going back to the vendor you are leaving, from a position where they know exactly how much you need them.

The verification is not sophisticated. Somebody other than the outgoing vendor deploys the system from what you were given, following the documentation, and it runs. That is it. It takes a day and it is the difference between a project and a hostage situation.

What the incoming vendor should be asked

Two questions, and the answers are diagnostic.

How do you plan to learn this system, and what will that cost? Every incoming vendor needs a discovery period, and a vendor who claims otherwise is either not going to do it or has hidden it in the price. A vendor who quotes it explicitly, as a bounded paid phase with a deliverable, is telling you they have done this before.

What will you hand over if we leave you? Asking this at the start of a relationship is not hostile, it is symmetrical. A vendor who has just benefited from a predecessor’s poor handover and cannot commit to a better one has told you what the next transition will look like.

The cost that nobody quotes

Changing vendor has a real cost that appears in no proposal: your own team’s time. Explaining the business rules again. Testing again. Re-establishing the working relationships. On a small system this is a few weeks. On a system several people depend on daily, it is a significant internal project.

This is worth naming out loud, because it changes the decision in both directions. It argues against changing vendor over an irritation, and it argues strongly for making the current arrangement renegotiable so that irritations can be fixed rather than escaped. The point of holding your code, your data and your credentials is not to leave. It is that a relationship you can leave gets renegotiated, and one you cannot gets endured.

Further reading

• The exit clause you negotiate before you need it: what step one is possible because of
• Who owns the code your contractor writes: whether there is anything to secure
• Modernize or renegotiate: the decision before this one
• When one person is your only backup: the same dependency, with an invoice attached
• Handing over the code and the team: what a handover looks like when it is a deliverable