A Guide to Switching Development Vendors — What to Confirm About Source Code and Documentation

Switching development vendors means moving the operation and further development of a system from the company that has handled it so far to a different development company. Switching vendors is not unusual in itself — it is a natural choice that can arise as a business grows or its needs change. That said, a switch requires handing over assets such as source code, documentation, and various accounts completely and accurately; proceeding without adequate preparation can leave system operations disrupted, or leave the new vendor unable to begin work. This article outlines, from a neutral standpoint, the typical situations that prompt a vendor switch, the items that need to be handed over, and the steps for making the transition smoothly.

- Slower response times: Inquiries and incident response start taking longer than before
- Staff turnover: The person who understood the project's history leaves, and the handover becomes inadequate
- Lack of transparency in quotes or costs: The basis for maintenance or additional development costs becomes hard to understand
- Technical limitations: The current technology stack makes it difficult to add features or scale going forward
- A change in business phase: Business growth requires a larger-scale development setup

The first thing to understand when switching development vendors is the overall picture of 'what belongs to your company and what needs to be handed over.' Broadly, five items are central to a handover: the full source code, the database, documentation such as design and specification documents, accounts for various services, and administrative rights to the domain and server. Without these, the new development company cannot accurately grasp the current state of the system, and a large amount of time and cost will go into investigation alone. It is best to begin taking stock of these assets early, as soon as switching is under consideration.

Copyright over the deliverables of system development (such as source code) may belong to the client or may be retained by the development company, depending on the contract. When considering a switch, it is necessary to check how the current and past contracts define copyright ownership and usage rights. In particular, a development company that reuses proprietary libraries or a common platform across multiple clients may retain rights to part of the deliverable rather than transferring them to the client. Because judgments about copyright and contract interpretation vary greatly depending on the specific contract, it is recommended to consult a lawyer or other qualified professional rather than deciding on your own when in doubt.

- As soon as you begin considering a switch, review the current contract and quote to understand the procedures required to end it, such as a notice period
- Create an inventory list of the assets that need to be handed over (the five items in the table above)
- Share the handover scope and current system configuration with the new development company in advance, and request an assessment and quote
- Request, in writing, that the current vendor provide a handover schedule and the necessary materials
- Transfer ownership and administrative rights for infrastructure such as the domain and server to your own company (or confirm the process for doing so)
- Once the handover is complete, follow through on the procedures to end the contract with the previous vendor, such as canceling a maintenance agreement

Rather than unilaterally announcing a switch, one option is to first explain your current concerns and the reasons you are considering a change to the existing vendor, and discuss whether there is room for improvement. If you do decide to proceed with the switch, it is best to reach specific agreement — while avoiding an emotional conflict — on the timing of contract termination, the scope of materials to be handed over, and the support arrangement during the handover period. When requesting cooperation on matters not specified in the contract, keep in mind that such requests may not be legally enforceable; seeking a realistic landing point, such as requesting paid handover support if needed, tends to lead to a smoother transition. For the basic clauses worth confirming at contract time, see the basics of development contracts, and for points to check at acceptance, see the acceptance testing guide.

When selecting a new development company, it is worth confirming whether they can accurately understand the existing system's structure based on the handed-over documentation and source code. Aligning in advance on how maintenance costs are calculated and how future additional development will be quoted — with reference to the guide to system maintenance costs — makes it easier to avoid trouble after the switch. For a broader look at how to approach ordering system development, see the guide to ordering system development as well.

Switching development vendors is not unusual, but how smoothly operations continue afterward depends heavily on whether five categories of assets — source code, database, documentation, accounts, and infrastructure access — are handed over completely. Taking stock of these early, as soon as a switch is under consideration, and reaching specific agreements with the current vendor while avoiding emotional conflict, is key to a smooth transition. When in doubt about copyright or contract interpretation, it is best to consult a professional rather than deciding on your own.