Changing software development vendor: a transition plan

Direct answer

When you change software vendor, the order of the steps matters more than the speed. Decide whether to switch at all, secure your own access to the code, hosting and accounts before you announce anything, request the handover material from the outgoing vendor, hold a knowledge transfer with a named contact, decide how long the two teams overlap, and prove that the new team can build and deploy on its own before you release the old one. This page is a guide to that sequence. It is not legal advice, it does not cover contract terms or disputes, and it makes no claim about how long or how much a switch takes, because that depends entirely on the state of the system and the relationship.

Decide whether to switch at all

Before starting a transition, separate three questions that are often mixed. Is the problem the vendor, or is it the scope, the communication or your own decision-making? Would the same problem follow you to a new vendor? And is the system worth keeping, or does it need replacing? The table further down the page is a prompt for that conversation, not a verdict.

Secure access before the announcement

Check, before you say anything to the outgoing vendor, that you can reach the assets yourself: the code repository, the hosting and cloud accounts, the domain, the database, third-party accounts and any secrets the system depends on. If any of these sits in the vendor's name, you want to know now, not during a difficult conversation. Who owns the code and accounts after a custom build explains what to look for, and the access removal checklist covers the final clean-up. If something is not in your hands, that is a question to settle before the switch, not after.

What to request from the outgoing vendor

Ask for the handover material in writing and check it against a list rather than accepting a folder of files. The full list of what to expect is in the software handover checklist, and what documentation should contain is in what documentation to receive with custom software. We do not repeat those lists here. The point at this stage is to ask early, ask specifically, and keep a record of what was requested and what was received.

Knowledge transfer with a named contact

Documentation records what was written down. Sessions capture what only lived in someone's head. Agree with the outgoing vendor that a named person is available for questions and for a set of live sessions, and agree what those sessions cover. The developer knowledge transfer sessions guide sets out how to plan and run them.

The overlap period is a decision, not a duration

Decide whether the two vendors work in parallel for a while, and if so what each is responsible for during that time. Do not treat the overlap as a number to fill in. Treat it as the period between two events: the new team's first successful deployment, and your confidence that the questions have stopped arriving. Be clear who is responsible for the live system at every point, so that nothing falls between the two.

Test that the new team can build and deploy alone

Do not release the outgoing vendor until the new team has, without help, built the system from the repository, deployed it to a test environment, run its tests, made a small change and deployed that change. This is the practical proof that the handover was complete. If a step fails, the missing knowledge has just appeared, while you can still ask for it.

Payments, unfinished work and in-flight changes

Settle in writing what happens to work in progress: what is finished, what is half-done, what change requests were agreed but not started, and what has been paid for. Decide who owns each open item from the day of the switch. This is a practical inventory, not a legal exercise; if there is any dispute, take advice from a qualified professional rather than relying on a general guide.

Write the exit plan before you need it

The best time to plan an exit is at the start of a relationship, when nobody is upset. Whichever vendor you use next, agree in writing that you hold the repository and accounts from the beginning, that documentation is kept current, and that a handover would follow a known list. An exit plan of this kind costs little to write and makes any future change less stressful. It is the same set of habits whether you stay with a vendor or leave.

Where LATYNEX fits, and when it does not

If you have decided to move, LATYNEX can be the new team: we read the handover material, run the build-and-deploy test, tell you what we found and agree one scope and one price in writing for what comes next. We are a remote, English-language vendor; see how to choose a software development agency for questions to ask any candidate, including us.

LATYNEX is not a takeover or rescue service, and this page is not a promise of one. We are not the right fit for a contract dispute, which needs a lawyer, or for a system nobody can access, where the first step is regaining access, not choosing a builder.