Skip to main content
Buyer guide

How to Switch Web Development Agency: A Safe Handover Guide

By Obaid Tariq, Founder & Lead Engineer · Published · Updated

Disclosure: AI Dev Planner is a development agency that takes over projects from other teams, so we have an interest in this question. We say below when switching, or switching to us, is not the right move. See our disclosure policy. This guide is general information, not legal advice.

The short answer

To switch web development agency safely, check your contract first, list every account and asset the project uses, and move each one into your business’s own name before the old team’s access ends. Get a written copyright assignment for the code, a recorded handover walkthrough, and proof the new team can deploy. Then remove old access and rotate every credential.

This guide covers the switch itself. To vet the replacement, use our guide on how to choose a software development company, which has the questions to ask, the full contract checklist and a scorecard. If you are also reconsidering the hiring model, see agency vs freelancer vs in-house.

How do I migrate from one web development agency to another safely?

The risk in a switch is rarely the new team’s skill. It is losing access to something you did not know you depended on: a domain renewing on someone else’s card, an API key in a personal account, a deployment that only works from one developer’s laptop. Work through these steps in order, whether you are leaving an agency or a freelancer.

  1. Read your contract before you say anything

    Find the clauses on ownership of the code, notice periods, termination, handover, outstanding payments and confidentiality. They decide what you can ask for and when. Our guide to choosing a development company has a full contract checklist; here you only need to know where you stand.

  2. List everything the project touches

    Use the access and assets inventory below. For each item write down whose account it is in today. Anything in the outgoing supplier's name is a handover task; anything in yours is just an access change.

  3. Line up the new team, but do not give them access yet

    Vet the replacement first. Share a written brief and, under a confidentiality agreement, enough of the inventory for them to plan the takeover. Access comes after you have given notice.

  4. Give notice in writing and agree a handover plan

    Keep it factual and polite. Give the notice the contract requires, state the cut-off date, and attach the list of items you need, with a date for each. A calm, specific request gets a better handover than a frustrated one.

  5. Transfer ownership, not just passwords

    Move the repository, cloud resources, domain and third-party accounts into accounts your business owns, then add people to them. A shared password to someone else's account is not a handover.

  6. Run a handover walkthrough and record it

    Ask the outgoing team for one or two recorded sessions: how to run the project locally, how it is deployed, where the data lives, and what is fragile. The incoming team should attend and ask questions.

  7. Check the live system matches the code you received

    The new team builds and deploys from the repository to a staging environment. If what is live cannot be rebuilt from the code you hold, find out why before the outgoing team's access ends.

  8. Remove old access and rotate every credential

    Once the new team can build and deploy, remove the outgoing team from every account and change every password, API key and token they could see. Do this on a planned date, not months later.

The access and assets inventory

Copy this list and fill in the current owner of each item before you give notice. The aim is simple: everything ends up in accounts your business owns and pays for, and suppliers are added as users who can be removed.

Access and assets inventory for an agency handover: what to collect, who should own it and what to do after handover
AssetWhat to collectWho should own itAfter handover
Domain registrarRegistrar name, login, registrant details, renewal date, transfer (Auth) code if moving registrarYour business, as registrant, with a company email addressRemove supplier logins; check registrant details are yours
DNSWhere DNS is hosted (often not the registrar) and a copy of every recordYour businessRemove supplier access; keep an exported copy of the records
Hosting and cloudProvider, account or project IDs, which environments exist (production, staging), billing ownerYour business, paying the bill directlyRemove supplier users and roles; rotate access keys
Code repositoryEvery repository, including small ones for scripts, infrastructure or mobile apps, with full historyYour business's GitHub, GitLab or Bitbucket organisationRemove supplier members; review deploy keys and integrations
CI/CD and deploymentPipeline configuration, where it runs, the secrets it uses, and how to deploy by hand if it failsYour business, inside your repository or cloud accountReplace pipeline secrets and tokens
Databases and backupsWhere each database runs, how backups are taken, where they are stored, and a tested restoreYour businessChange database passwords; confirm backups still run
Third-party accounts and API keysPayments, email sending, maps, AI APIs, authentication, error monitoring, app stores, with the plan each is onYour business, billed to youRevoke and reissue every key the supplier could see
Analytics and searchAnalytics properties, tag manager containers, search engine webmaster accountsYour business, as administratorRemove supplier users or reduce them to read-only
Email and domain mail settingsMailbox provider, and the DNS records that let your domain send emailYour businessRemove supplier admins; check sending still works
Design filesSource design files, component libraries, brand assets and fonts with their licencesYour business's workspace in the design toolTransfer files into your workspace; remove supplier editors
DocumentationSet-up instructions, architecture notes, environment variable list (names, not values, in documents), known issuesYour business, stored in the repository or your own wikiAsk the new team to review and correct it

Three transfers that have their own rules

Domains. ICANN’s FAQs for domain name holders explain that moving a domain to a different registrar needs an Auth-Code, which your registrar must provide within five calendar days of your request, and that you cannot transfer to a different registrar within 60 days of changing the registrant name, organisation or email address, unless your registrar lets you opt out of that lock (ICANN, accessed 18 October 2026). So if you need to correct the registrant details and change registrar, plan the order. Often you do not need to change registrar at all, only to make sure the account and registrant are yours.

Repositories. On GitHub, transferring a repository to your organisation keeps its issues, pull requests, wiki and commit history, and redirects links from the old location; the person transferring needs admin access to the repository and permission to create repositories in your organisation (GitHub Docs, accessed 18 October 2026). A transfer keeps the history, which a zip file of the latest code does not.

Removing access. Removing someone from your GitHub organisation ends their access to private forks of your private repositories, but GitHub notes they may still keep local copies (GitHub Docs, accessed 18 October 2026). That is why removing access is not enough on its own: the secrets in those copies must stop working.

Rotate credentials after handover

The OWASP Secrets Management Cheat Sheet says that when secrets are no longer required or potentially compromised, they must be securely revoked, and that secrets found in code or logs must be removed from the exposed system (OWASP, accessed 18 October 2026). After a handover, treat every password, API key, database credential and deploy token the outgoing team could see as no longer required by them. This is routine hygiene, not an accusation, and a professional outgoing team will expect it.

Who owns the source code and intellectual property after a project is completed?

Not automatically you. Paying for software and owning the copyright in it are different things, and when you switch agency is when the difference shows. What follows is a general summary of the UK and US position, not legal advice: your contract and the law that governs it decide your case.

United Kingdom

GOV.UK guidance says the author or creator of a work is usually the first owner of the copyright in it. For commissioned work, the first legal owner is the person or organisation that created it, unless you agree otherwise in writing, and without a clear agreement a commissioner may get only an implied, limited, non-exclusive licence. Work an employee creates in the course of employment belongs to the employer, subject to any agreement to the contrary (GOV.UK, ownership of copyright works). Under section 90(3) of the Copyright, Designs and Patents Act 1988, “an assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor” (legislation.gov.uk). Both accessed 18 October 2026.

United States

The US Copyright Office’s Circular 30 explains that a work is made for hire in two situations: when an employee creates it as part of their regular duties, or when a commissioned work falls into one of nine listed categories and both parties sign a written agreement saying it is a work made for hire (Circular 30, Works Made for Hire, accessed 18 October 2026). Software is not one of those categories in its own right, so code written by an outside agency or freelancer is generally not a work made for hire, whatever the contract calls it. A written assignment of copyright is what moves ownership to you.

What to do when you switch

  • Check whether your contract already assigns the IP, and on what condition, for example on payment of each invoice.
  • If it does not, ask for a short written assignment as part of the handover, covering the bespoke code, database design, designs and documentation, signed by the supplier.
  • Ask for a list of anything the supplier keeps: reusable components, templates or libraries it owns, and the licence under which you can keep using them.
  • Note the open-source licences the product depends on, so the new team inherits an accurate picture.

For the IP and exit clauses to put in your next contract, see the contract checklist in our guide to choosing a software development company. For a disputed or valuable codebase, have a lawyer qualified in the governing law review the wording.

What should happen if a software agency misses its deadlines?

A missed deadline is a reason to get clarity, not yet a reason to leave. Software estimates are uncertain, and a late project is often recoverable. What matters is whether the agency explains the delay honestly and whether a credible new plan follows. Escalate in steps:

  1. Ask for the reason in writing. Which milestone, how late, why, and what the new date depends on. Separate delay caused by extra scope you requested from delay on agreed work.
  2. Check the contract. Look for fixed dates or milestones, acceptance criteria, any remedy for delay, the change control process, and the termination and handover clauses.
  3. Ask for a revised plan you can verify. Smaller milestones, each ending in working software on a staging environment you can use, rather than a single new end date.
  4. Hold a senior-level review. Meet the agency’s director or account owner, agree what will change, and confirm it in writing with dates.
  5. If the revised plan slips too, prepare to exit. Start the inventory above, make sure the code is in your repository, and follow the contract’s termination route.

If your contract has no dates at all (England, Wales and Northern Ireland): section 14 of the Supply of Goods and Services Act 1982 says that where a business supplier’s contract does not fix the time for a service, there is an implied term that it will be carried out within a reasonable time, and that what is reasonable is a question of fact (legislation.gov.uk, accessed 18 October 2026). That is a fallback, not a plan: what counts as reasonable for software is arguable. Elsewhere, local law differs, so take advice before you treat a delay as a breach.

Payments are leverage only if they are tied to delivered work. If your current contract pays by calendar date, fixing that is worth more in your next contract than any penalty clause.

Signs it is time to switch, and problems that are usually fixable

Switching has a cost: the new team needs time to learn the code before it is as productive as the old one. It is worth paying when the problem is structural, and usually not when it is a specific problem you can name and fix together.

Signs it is time to switch

  • You cannot get access to your own code repository, hosting or accounts when you ask for it.
  • The same deadline has moved several times without a written reason or a revised plan.
  • You have not seen working software, rather than reports about it, for several weeks.
  • Fixes regularly break other things and nobody can explain why, which usually points to missing tests.
  • The people who built the product have left and the supplier cannot say who now understands it.
  • You raised a concern clearly and in writing, agreed what would change, and it has not changed.

Usually fixable without switching

  • Scope has grown since the estimate, and the delay matches the extra work you asked for.
  • Communication is patchy but the work is good; a fixed weekly demo and a shared board often solve it.
  • You are waiting on decisions, content or access from your own side.
  • One difficult integration is holding things up and the team has explained the problem honestly.
  • Costs have risen because of choices you agreed to, and the supplier told you before billing.

A useful test: write down the one change that would make you stay, share it with the current team, and give it a fixed period. If it happens, you have saved the cost of a switch. If it does not, you are leaving with a clear, documented reason.

What a new agency should do in the first two weeks of a takeover

Ask any agency you are considering to describe its first two weeks before you sign. A good answer is mostly investigation and documentation, with a small, safe release at the end. Feature work before the team can run, deploy and understand the code adds risk. The timings below are typical of how we would plan it, not a fixed rule; a large or undocumented codebase takes longer.

  1. Days 1–3: get it running

    Clone the repository from your organisation, follow the documentation to run it locally, and note every step that was missing or wrong. Build and deploy to a staging environment you control. If this is hard, that is the first finding.

  2. Days 3–6: code audit

    Review the structure, the dependencies and their versions, test coverage, error handling and the data model. The output is a written list of what is sound, what is risky and what blocks the roadmap, each with a severity, rather than a verdict on the previous team.

  3. Days 5–8: security review

    Search the code and its history for committed secrets, check authentication and authorisation on every sensitive route, review database access rules, and confirm that the old credentials have been rotated. Fix anything critical before new features.

  4. Days 8–10: document what you found

    Update the README so a new developer can run the project in under an hour, write down how deployment and backups work, and list the environment variables by name. This is what makes the next handover easy, whoever does it.

  5. Days 10–14: a plan you can check

    A prioritised plan: what to fix first, what can wait, and when you will see the first change deployed by the new team. A small, safe release in the first two weeks proves the deployment path works end to end.

If the app was built with an AI coding tool such as Lovable, Bolt, Replit or Cursor, the audit usually finds a different set of problems: authentication and database access rules, secrets in client-side code, and missing tests. Run it through our free production readiness checker first, and see our AI-built app rescue service for what fixing it involves.

If it is a business system such as a portal, internal tool or legacy application, a takeover often turns into stabilising and extending it; that is the work of our bespoke software development service.

Where AI Dev Planner fits, and when we are not the right choice

We take over web applications, SaaS products and AI-built apps from other teams. Our engineering team is in Islamabad, Pakistan, and works remotely with clients in the UK, the US, the Gulf and elsewhere, through a dedicated Slack channel and a video walkthrough of working software every two weeks. We recommend your repository lives in your own GitHub or GitLab organisation and your hosting in cloud accounts you control, and clients receive full IP ownership of the bespoke code we write, on the terms set out in the contract and our terms of service. A takeover starts with the audit described above, and we quote for the work after it, because nobody can price unfamiliar code honestly before reading it. Ask us how our 60–90 day warranty applies to inherited code before you sign.

We are not the right choice if:

  • your problem is on the fixable list above; a direct conversation with your current team is cheaper than a switch;
  • you are days from an important launch; switching then usually adds more risk than it removes;
  • you need people on site, or your contracts require your systems to be accessed only from your own country;
  • the product needs one small change; a freelancer is usually better value for a single, well-defined task.

Whoever you choose, vet them with the same checks: questions to ask a software development company.

FAQs about switching agency

Can I change software development company in the middle of a project?

Yes. Mid-project switches are common, and they go best when you finish or pause the current sprint cleanly rather than stopping mid-change. Agree a cut-off date with the outgoing team, ask them to merge or clearly label all unfinished work, and get a short written note of what is done, what is half-done and what is known to be broken. The new team then starts from an honest picture rather than a guess.

What can I do if my old agency will not hand over the code?

First, check the contract: what it says about ownership, handover and termination, and whether any invoices are genuinely outstanding. Ask in writing, calmly, for a specific list of items by a specific date. Many delays are about unpaid invoices or unclear scope rather than bad faith, so settling what is fairly owed often unlocks the handover. If the contract gives you ownership and the code still is not released, take legal advice under the law that governs the contract. In future, keep the repository in your own account from day one so this cannot happen.

Should I tell my current agency before I talk to a new one?

You do not need to announce it before you have options, but do not give a new team access to anything until you have checked your contract with the current one, in particular any confidentiality and notice terms. Once you have decided, tell the current agency directly and in writing, give the notice the contract requires, and keep the conversation about the handover rather than the reasons.

Will a new agency want to rewrite everything?

It should not assume so. A good takeover starts with an audit, then a written recommendation that separates what is fine, what needs fixing and what, if anything, needs replacing, with reasons. A full rewrite is sometimes right, for example when there are no tests, the framework is no longer supported and the data model blocks the next feature, but it should be a conclusion from evidence, not the opening offer.

How long does a handover between agencies take?

It depends on how much is already in your accounts. If the repository, hosting and third-party services are in your name and there is documentation, the handover can be a few days of access changes and walkthroughs. If everything sits in the outgoing supplier's accounts, expect longer: domains, cloud resources and app store listings each have their own transfer process, and some, such as domain transfers, have waiting periods set by the registry or registrar.

My freelancer has stopped replying. How do I take over the project?

Start with what you can reach without them: the domain registrar, the hosting or cloud account, the app stores, payment providers and email, using account recovery where the accounts are in your business's name. Make a list of everything you cannot reach. Send one clear written request for the code and credentials with a date. Then have a new developer check whether the live site matches any code you hold, and rotate every credential the freelancer had.

Should I pay the final invoice before I get the source code?

Look at what the contract says about payment and handover; that usually decides it. A fair arrangement ties payment to delivered work and handover to payment for that work. If you dispute part of an invoice, say which part and why in writing, pay what is not disputed if the contract expects it, and ask for the handover of work you have paid for. Take advice before withholding payment in a way the contract does not allow.

Sources

Each source is labelled with the jurisdiction it covers, where it has one, and the date we accessed it.

  1. GOV.UK: Ownership of copyright works (UK) — The creator is usually the first owner of copyright; for commissioned work the creator is the first owner unless agreed otherwise in writing; employers own employees' work made in the course of employment. Accessed 18 October 2026.
  2. Copyright, Designs and Patents Act 1988, section 90 (UK, legislation.gov.uk) — An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor. Accessed 18 October 2026.
  3. U.S. Copyright Office: Circular 30, Works Made for Hire (US) — Employees' works made within their regular duties are made for hire; a commissioned work qualifies only in nine listed categories with a written agreement signed by both parties. Accessed 18 October 2026.
  4. Supply of Goods and Services Act 1982, section 14 (England, Wales and Northern Ireland, legislation.gov.uk) — Where a business supplier's contract does not fix the time for a service, there is an implied term that it will be carried out within a reasonable time, which is a question of fact. Accessed 18 October 2026.
  5. ICANN: FAQs for domain name holders — An Auth-Code is needed to transfer a domain between registrars; registrars must provide it within five calendar days; the 60-day lock after a change of registrant details. Accessed 18 October 2026.
  6. GitHub Docs: Transferring a repository — What moves with a transferred repository (issues, pull requests, wiki, history, secrets and deploy keys) and the admin permissions needed. Accessed 18 October 2026.
  7. GitHub Docs: Removing a member from your organization — Removed members lose access to private forks of the organisation's private repositories but may keep local copies. Accessed 18 October 2026.
  8. OWASP Secrets Management Cheat Sheet — Revoking secrets that are no longer required or potentially compromised; rotating secrets; removing exposed secrets from code. Accessed 18 October 2026.

Planning a handover?

Tell us what you have and where it lives. We will say what a takeover would involve, and tell you if staying with your current team looks like the better option.

Talk through a takeover Check an AI-built app