Onboarding a New Development Partner: A Handover Checklist

Onboarding a new development partner goes well when you do four things in order. Settle ownership and data questions in writing first. Move code, accounts and knowledge in a controlled sequence. Let the new team work alongside the old one for a short period. Sign off only when the new partner has shipped a real change on its own. This guide walks through each step as a vendor transition checklist for a Swiss business, with the legal points that catch teams out.

TL;DR

• Before anyone touches code, confirm in writing who owns the copyright, where data is processed, and who holds each account.
• Transfer the full repository with history, then rotate every credential. Do not rely on a zip file or on shared passwords.
• Run old and new partners in parallel for a short period, with ownership shifting step by step rather than on a single day.
• Agree scope, communication rhythm, milestones and acceptance criteria before the first sprint, not during it.
• Declare the handover done when the new partner has deployed a change on its own, not when a checklist is ticked.

What to clarify before the new partner starts

Most failed handovers are not technical failures. They come from questions nobody asked in week one. Get answers to these before the kickoff.

Why you are switching. Write down the two or three reasons: missed deadlines, a departed key developer, a stack nobody can maintain, cost. The new partner needs this to avoid repeating the pattern, and you need it to judge success later.

What actually exists. List every product, environment and third-party service that makes up the system: production, staging, the domain registrar, the hosting account, payment and email providers, analytics, CI/CD, monitoring. Teams are usually surprised by how many of these sit under the old vendor’s name or credit card.

Who is allowed to decide. Name one person on your side who can approve scope and one who can approve spending. A new partner with five sources of instructions will reproduce the confusion you are trying to leave behind.

What the old contract says. Check the notice period, the handover duties of the outgoing vendor, confidentiality clauses and any limits on sharing code with a successor. Your legal contact should read this before you promise the new partner a start date.

Check ownership, data protection and contract terms

Switzerland has a few rules that surprise founders. Settle them early, because they can block the new partner from legally working on your product.

Who owns the source code

Having the code on your server does not mean you own the rights to it. Under Swiss law, copyright in software is not automatically transferred to the commissioning party outside employment relationships, and handing over a copy of the source code does not automatically carry the right to use it. A business that holds code without an explicit assignment may lack the right to modify it, redistribute it or host it elsewhere.

The Federal Supreme Court has taken the same line. According to a University of Geneva analysis of the ruling, a software development contract does not automatically imply transfer of copyright to the client. The client has to point to an explicit provision, and an obligation to return source code does not establish the transfer by itself.

In practice: find the clause in your old contract that assigns copyright or grants usage rights. If it is missing or vague, ask your lawyer to have the outgoing vendor confirm the rights in writing before the new partner starts. Then make sure your contract with the new partner states the assignment or licence clearly from day one. Third-party and open-source components deserve a short list of their own, with their licences.

Personal data and the data processing agreement

If the system handles personal data, the new partner will touch it in testing, support or migration. A Swiss IT procurement checklist from the law firm Wicki Partners points to the questions to answer:

• Is personal data processed at all, and does the GDPR also apply?
• Does data leave Switzerland, and where does it go?
• Is a data processing agreement in place?
• Who holds the rights to the stored data?
• Can the provider demonstrate its technical and organisational measures?

Ask the new partner to put its answers in the contract. Also decide how production data is handled during the transition. Staging environments with anonymised or synthetic data are safer than copies of live customer records on a developer’s laptop. If your data is subject to special confidentiality duties, as in banking or health, involve your data protection lead before any copy is made.

Build the transition checklist

This is the core of the handover. Treat each line as something with an owner and a done date.

Area	What to hand over	How to confirm it is done
Source code	Full repositories with complete history, branches, tags and CI configuration	New partner builds and deploys from the repository you own
Accounts	Hosting, domain registrar, app stores, payment, email, analytics, monitoring	Every account lists your company as owner, with named admin users
Credentials	API keys, database passwords, deploy keys, signing certificates	All rotated; old values no longer work
Infrastructure	Environment diagrams, infrastructure-as-code, backup and restore procedures	New partner performs one restore test
Documentation	Architecture notes, data model, runbooks, release process, known issues	New partner can follow the runbook without calling the old team
Knowledge	Walkthrough sessions, recorded demos, open ticket backlog with context	Questions list is closed or consciously parked
Legal	Copyright assignment, data processing agreement, licence list	Signed and filed

Hand over code, accounts and credentials securely

Send the whole repository, not a snapshot of the main branch. Old branches and commit messages explain why things are the way they are, and you will want that the first time something breaks. If you transfer a repository between organisations on a platform such as GitHub, check what stays attached to it, such as webhooks, deploy keys and secrets, because inherited integrations can keep running on the old vendor’s credentials. A vendor handover checklist from Trio makes the same point about secrets being the most commonly skipped item.

A workable order:

1. Inventory first. One shared document lists every account and secret, with the current owner.
2. Move ownership of accounts to your company. The old vendor should be a user in your account, not the other way around.
3. Give the new partner named, individual access through your password manager or identity provider. Never share one login across people.
4. Rotate secrets once the new partner is working, then revoke the outgoing vendor’s access in the same sitting.
5. Log the changes so you can show who had access when.

You can record who owns what, per account and environment, in your own handover sheet. If you want a template to adapt for the handover scope and the service levels that follow it, this checklist product is one starting point.

Transfer knowledge, not only files

Code explains what a system does. It rarely explains why. Schedule three kinds of sessions with the outgoing team, even if the relationship is strained, and consider paying for them in your exit terms:

• Architecture walkthrough: components, data flow, third-party dependencies.
• Operations walkthrough: how releases happen, what breaks, who gets alerted, what the monthly routines are.
• Backlog walkthrough: each open ticket, with the reason it exists and any customer promise attached.

Record them. New team members will watch those recordings months later. The same logic applies when AI components are part of the system: prompts, model configuration, evaluation data and deployment settings need documenting like any other code. A piece on knowledge transfer and operational continuity for AI deployments covers that side in more detail.

Agree how you will work together

A clean technical handover still fails if the working agreement is vague. Settle these before the first sprint.

Scope. Describe the first piece of work, not the whole roadmap. Pick something small and real, such as fixing a known bug or shipping a minor feature, so both sides learn each other’s habits cheaply.

Responsibilities. Write down who owns production incidents, who approves releases, who talks to users, and who handles security patches. If you also keep an in-house person, define the boundary with the partner.

Communication. Choose one channel for daily questions and one weekly meeting for decisions. Agree response times. Ask who your contact will be for the whole engagement, and whether that person is the one doing the work. Continuity of people matters a great deal in the first months, so ask directly how the partner staffs the engagement and what happens if someone leaves.

Milestones and acceptance criteria. For each milestone, write what “done” means in observable terms: deployed to production, tests passing, documentation updated, you can demonstrate the feature. Vague acceptance language is where scope disputes start.

Service levels after launch. If the partner will run the system, define what is monitored, how fast they respond to incidents, and what is included each month. Our own monitoring plan, Run & monitor, is CHF 750 per month; ask any partner to spell out the equivalent so you compare like with like.

Reduce downtime with a staged takeover

The riskiest approach is the switch-over weekend: the old vendor leaves on Friday and the new one starts on Monday. A staged plan, roughly in three phases, is safer. This structure follows a 90-day transition plan published by Howdy, adapted here as a general pattern. Length depends on system size, so treat 90 days as an upper range for a complex product and plan shorter for a simple website.

Phase 1: stabilize access and read

The new partner gets read access, reviews the code, sets up its own local and staging environments and reads the runbooks. Nothing changes in production. Your goal is that the new partner can name the three riskiest parts of the system.

Phase 2: parallel run

The new partner starts making small changes, reviewed by the outgoing team where possible. Ownership moves gradually: first staging, then deployments, then incident response. Keep a short list of anything the new partner says is unclear, and close it with the old team while they are still reachable.

Phase 3: cutover

The new partner owns releases and incidents. Rotate remaining secrets, revoke outgoing access, and switch the support terms to the new service levels. Keep the old vendor reachable for a defined period of questions, in writing in your exit agreement.

Protect the business during the switch

• Freeze non-essential releases for the days around cutover.
• Take a full backup and test that you can restore it before access changes.
• Tell your support team who to call during the transition.
• Schedule cutover away from your busiest trading days.

Confirm the new partner is ready to own the product

A signed-off checklist proves that documents changed hands. It does not prove the new team can run the product. Use outcome tests instead:

1. Deploy test: the new partner ships a small change to production without help from the old vendor.
2. Restore test: they bring up the system from backup in a clean environment.
3. Incident drill: they walk through how they would respond to a failed payment integration or a database outage, using the runbook.
4. Access audit: you can list every person with access, and the outgoing vendor appears nowhere.
5. Documentation check: a doc that was wrong or missing was corrected by the new partner during the process.

After sign-off, hold a review at 30 and 90 days. Compare against your original reasons for switching: delivery speed, defects, communication, cost. Fix problems while the relationship is young.

How we onboard as the new partner

At Ampersand, we are a small Zurich studio, and senior engineers stay involved from the first conversation to handover. That is designed to avoid rewritten requirements and mid-project staff changes, and to leave you able to run your own product rather than locked in. If you are moving a product from another vendor, we can help with audits, migration of legacy systems, advisory and ongoing support. Our Guidance plan for senior technical advice is CHF 799 per month. You can see the options on our pricing page or start from our homepage.

FAQ

How long does onboarding a new development partner take?

It depends on system size. A simple website may take a couple of weeks, while a complex platform with many integrations can need up to around three months of staged transition. Plan for a parallel period rather than a hard cutover, and define the end by outcome tests such as an independent production deploy.

What should be in a vendor transition checklist?

At minimum: full repositories with history, account ownership, rotated credentials, infrastructure and backup documentation, runbooks, a walkthrough of the open backlog, and signed legal documents on copyright and data processing. Each item needs an owner and a way to verify it is done.

Do I own the code the previous agency wrote for me?

Not automatically. Under Swiss law, copyright in custom software does not pass to you just because you paid for it or received the source code. Check your contract for an explicit assignment or usage licence, and have a lawyer confirm the position before the new partner starts.

What if the old vendor will not cooperate?

Start with what your contract requires: handover duties, notice periods and code delivery. Secure the accounts you own directly, such as the domain and hosting, and let your lawyer handle disputed items. Ask the new partner to audit the code first, so you know what is missing before you negotiate.

Sources

• Wicki Partners: Checkliste IT, Beschaffung und Vertragsprüfung
• Baker McKenzie: Copyright pitfalls in outsourcing software development, a Swiss legal perspective
• University of Geneva: Early termination of a software development agreement
• Trio: Software vendor handover checklist
• Howdy: Switching development vendors with a 90-day transition plan