Switching software vendors: the transition plan, and what to get from the outgoing agency

Published 26 October 2026

Switching software vendors means moving a live system from the agency or supplier that built it to a new one — or to your own team — without losing the code, the accounts, the data or the knowledge on the way. It goes best in a fixed order: secure what you own before giving notice, agree a transition plan, pay for an overlap in which the new team learns from the old one, and move responsibility one area at a time. Below: what to do before giving notice, a vendor transition plan template with an example, what to get from the outgoing vendor, the questions to ask, what the new team needs first, and what to do when the old vendor will not help.

Incoming-and-outgoing of vendors generate a complex form of relationship in which the participating organizations cooperate and compete simultaneously.

— Raza, Clear and MacDonell, a study of one government project’s switch from one vendor to another (ICGSE Workshops 2015)

Before you give notice

The outgoing vendor is most helpful while the contract is still running and the relationship is still good. Everything you can secure before notice, secure then.

Read the contract. Who owns the code — a signed assignment, not the invoices (see who owns the code); what the vendor must do at exit; the notice period.
Take over the accounts. Domain, DNS, hosting, cloud, the repository, app stores, analytics, payments: the client as owner, with two of its own people as admins. The website handover checklist goes through them in the order that avoids lock-outs. The second most-voted answer to “what should I ask the previous programmer?” on Stack Overflow: “Be sure to ask for all login information for the web servers, domain registrars, database servers, email servers, and anything else you can think of” (Stack Overflow, 2009).
Take a copy of the code and the data. The full repository with its history, in an account you own, and a database export you have restored once.
Map the system. Someone who has done “a lot of digital transformation projects”: “we lost the entire Product Information Management (PIM) system, forcing us to manually redo a lot of data. Don’t be that guy.” Their advice: “Make sure your system is fully mapped out and that you understand how it works before replacing the team” (Hacker News, 2024).
Then give notice, with the transition plan attached.

Vendor transition plan template

Copy it into Word, Google Docs or Confluence. Square brackets are yours to fill in.

VENDOR TRANSITION PLAN

System:     [name]
From:       [outgoing vendor], [lead]
To:         [incoming vendor or team],
            [lead]
Client:     [owner], [technical lead]
Notice:     [date]; contract ends [date]
Cut-off:    [date]
Questions:  [outgoing vendor], until
            [date]

1. ALREADY IN THE CLIENT'S HANDS
   Accounts:  [list], client as owner
   Code:      [repository], with history
   Data:      [export], restore tested
              [date]

2. THE OUTGOING VENDOR DELIVERS
   By [date]:
   - requirements as delivered, and
     the change requests since
   - open work: each item, its status
     and where it is
   - known defects; incidents of the
     last [12] months
   - build and deploy instructions
   - third-party services, licences
     and renewals

3. KNOWLEDGE TRANSFER
   [sessions, hands-on work] - see the
   knowledge transfer plan

4. RESPONSIBILITY MOVES
   [area]   from [date]

5. CHECKS
   [incoming team] rebuilds and
   deploys from the instructions:
   [date]
   Outgoing vendor's access removed,
   keys changed: [date]

6. PAYMENT
   [last payment] on the client's
   confirmation of section 2

Section 3 is the knowledge transfer plan. Section 6 matters more than it looks: the last payment is the client’s only lever at the end.

Vendor transition plan example

The company website from the website handover checklist, a year after launch. The client moves it from the agency that built it to a new one:

VENDOR TRANSITION PLAN

System:     Company website (WordPress)
From:       Agency A, project lead
To:         Agency B, lead developer
Client:     Marketing lead, IT lead
Notice:     2 May; retainer ends 31 May
Cut-off:    31 May
Questions:  Agency A, until 30 June

1. ALREADY IN THE CLIENT'S HANDS
   Accounts:  domain, DNS, hosting,
              WordPress, analytics,
              Search Console, tags
   Code:      the client's GitHub
              organization
   Data:      backup in the client's
              storage, restore tested
              28 April

2. THE OUTGOING VENDOR DELIVERS
   By 16 May:
   - change requests since launch,
     CR-4 to CR-11, with the site map
     version each changed
   - open work: CR-12 (event pages),
     half done; branch and notes
   - known problems; incidents of the
     last 12 months
   - deploy instructions, updated
   - plugins, licences and renewals

3. KNOWLEDGE TRANSFER
   Two sessions, 9 and 10 May,
   recorded; Agency B deploys with
   Agency A watching, 20 May

4. RESPONSIBILITY MOVES
   Content changes   from 13 May
   Deploys           from 20 May
   Hosting, uptime   from 31 May

5. CHECKS
   Agency B rebuilds the site from
   the repository: 14 May
   Agency A's users removed, keys
   changed: 31 May

6. PAYMENT
   Agency A's May invoice on the
   client's confirmation of section 2

Section 1 took one afternoon, because the site was set up in the client’s name at launch. Without that, it is the first and slowest part of every switch.

What to get from the outgoing vendor

Ownership and access

Every account in the client’s name, with the vendor’s access removed or dated.
The signed assignment of the code, if it is not already in the contract.

Code and build

The full source with its history — not a zip, and not access to the vendor’s repository.
Build and deploy instructions, proven: the top answer to the same Stack Overflow question is to “give him/her a naked (just bought) machine, let him/her demonstrate a checkout and rebuild” (Stack Overflow, 2009).
Secrets and keys listed by where they are kept, then changed.

What was agreed and what was built

The requirements as delivered: the version, the change requests since, what was accepted.
The decisions and the reasons for them.
Open work, item by item: done, half done, not started.

Operations

Known defects and their workarounds; incidents and problems from the last twelve months.
Monitoring, backups, scheduled jobs, and what renews when.
Third-party services and licences. The UK government’s model contract has the supplier keep a register of “Sub-contracts and other relevant agreements (including relevant software licences, maintenance and support agreements and equipment rental and lease agreements)” throughout the contract, for exactly this moment (Model Services Contract, Schedule 21).

The software handover document is the same list as a document the outgoing vendor fills in.

Questions to ask the outgoing developers

From the answers to “Taking over a project – what should I ask the previous programmer?” (Stack Overflow, 2009):

“If you could go back and redevelop this system, what would you do differently”
“What are the parts of the system that are too complex to be documented?”

And from the questions that come up later, when nobody is left to answer them:

What breaks most often, and what do you do then?
What is half finished, and where is it?
What did the client ask for that was never built, and why?
Which decisions were made on a call and never written down?
Who at the client knows the business rules?
Why is this part built this way? — the question one commenter, about an exiting agency, doubted anyone gets answered: “You’ve gotten an exiting agency to cooperate? Like answer your questions of “why’d you do this that way?” And the like?” (r/agency, 2023)

What the new team needs first: the requirements

The new team can read the code; what it cannot read in the code is what the system is supposed to do. A study of six software projects that a German financial services firm moved to vendors in India found extra costs for the client in four areas — “(1) requirements specification and design, (2) knowledge transfer, (3) control, and (4) coordination” — and found them “substantially higher” when the work needed client-specific knowledge (Dibbern, Winkler and Heinzl, MIS Quarterly 2008).

When nobody wrote the requirements down, the code becomes them. An answer to a developer facing a large codebase with no requirements and its author leaving: “There are requirements. You have 250,000 lines of requirements :-( I can guarantee that your users will be very unhappy if the behaviour of the application changes” (Software Engineering Stack Exchange, 2017). Another commenter’s advice, for a system a contractor left behind: talk to the people who hired the contractor — “They might even have specs that they prepared for the contractor or other design documentation” (Hacker News, 2015).

So hand the new team the requirements baseline as delivered, with the change log and the decisions, before it estimates anything. If that record does not exist, writing it is the first piece of work — a short discovery phase on an existing system — not something to skip on the way to the first feature.

Rewrite, or carry on?

A new team may propose a rewrite. One commenter on why that can happen: “framing the codebase as terribly written and a total disaster achieves two things politically. It helps set up blame for any issues in the future on the previous developers and their “terrible codebase” and opens the door for a much more enjoyable and lest risky greenfield rewrite” (Hacker News, 2018). A software engineer, on the next person to inherit a codebase: “Without context, they’ll step on the same landmine you successfully avoided” (HackerNoon, 2026).

A rewrite can be right. Ask for its reasons in writing, and decide after the new team has read the requirements and the decisions, not after a first look at the code. If it goes ahead, the old system is the specification: one answer suggests “a test suite that I could run against both the old software and the rewrite to confirm that the rewrite is behaving the same” (Software Engineering Stack Exchange, 2017).

When the outgoing vendor will not help

The outgoing vendor is losing the work, and that can show. One manager who moved an outsourced project in-house: “Have plenty of slack in the schedule, as nearer the end of the transition the vendor will have less motiviation to help you out. […] Some companies deliberatly make their code difficult to understand so that it is hard to migrate away from them” (Software Engineering Stack Exchange, 2012). The same answer suggests paying for help rather than expecting it: “you may want to arrange a consultant from the vendor to work in house for 6 months to a year”.

What keeps the vendor engaged is what the contract and the payments say: an exit clause written at the start (the statement of work template has one), the overlap paid for, and the last payment tied to the delivery list.

If the vendor keeps the code, the client’s options depend on who owns it. Where the vendor owns it, source-code escrow is the usual safeguard: a copy deposited with a third party and released on named events. UK government guidance gives as examples “the insolvency of the owner of the software, or the owner’s failure to meet contractual obligations to develop or maintain the software” (Model Services Contract buyer guidance). A deposit is not a handover, though. An escrow provider says so itself: “A software escrow agreement gives you the right to access source code, but access alone isn’t enough” (Escode). And one developer who received code from escrow when a vendor went out of business: “It was written in C and came with no documentation” (Hacker News, 2022). This is general information, not legal advice.

Cloud accounts and data

Cloud accounts move, but not cleanly. AWS: “To transfer ownership of your AWS account, you must have the root user’s email address and password” (AWS), and when an account leaves an agency’s organization, “IAM access roles created by the management account are not automatically deleted” (AWS). Google Cloud: after a project moves, “The project remains linked to the original billing account”, and “Roles granted at the source organization or folder level are lost” (Google Cloud). Azure, moving a subscription to another directory: “All role assignments are permanently deleted” (Microsoft).

In the EU, the Data Act (applying since 12 September 2025) makes cloud providers let customers leave: a notice period that “shall not exceed two months”, a transition of 30 days, “a minimum period for data retrieval of at least 30 calendar days”, and no switching charges from 12 January 2027 (Regulation (EU) 2023/2854). It covers cloud services (“data processing services”), not the agency’s own code, and services mostly custom-built for one customer are partly exempt.

How long a switch takes

There is no standard length; the example above took a month because the accounts were already the client’s. Public contracts give the outer bounds: the US federal continuity clause allows “up to 90 days” of phase-in and phase-out (FAR 52.237-3), and the UK model contract’s termination assistance can run “no longer than 24 months after the expiry” of the contract.

The cost does not end at cut-off. A study of one transferred Ericsson product found releases that came twice a year took eight months, then a year (Jabangwe and Šmite, 2012). And taking work in-house is no guarantee either. A former contractor whose client did exactly that: “over the 6 years they stewarded this the product was essentially stagnant, with no major changes or additions made” (Hacker News, 2024).

Where Specroot fits

This is the problem Specroot works on: the requirements as delivered — every version, every approved change, and who accepted it — kept as one record from the start, so it can go to the next vendor with the code instead of being rebuilt from the old one’s memory. Specroot for agencies and consultancies.