How to switch development agencies without losing your product

To switch development agencies safely, secure admin access to everything before you give notice: the code repository, cloud hosting, domain, app store accounts and third-party services. Then review your contract, run a structured handover with documentation and recorded walkthroughs, get the code independently reviewed, and keep the live product running until the new team has deployed it.

The order matters more than anything else. Most agencies handle an exit professionally, but a handover is extra work at the end of a relationship, when the agency's attention is already moving to other clients. Picking up products from previous agencies is part of my work as a fractional CTO, and in my experience the smooth handovers share one trait: the founder already controlled the accounts.

Before you give notice: secure access to everything

Once you announce you are leaving, your position changes overnight. The agency no longer has future work with you to protect, and access requests can become part of an exit negotiation. So do this first, while everything is still business as usual.

You do not need a cover story. Asking for admin access to your own systems is good practice whether or not you are leaving, and a short, matter-of-fact message is enough: you are tidying up account ownership and want the company listed as owner everywhere.

1. Code repository: your company as owner of the organization or project, with full history. If the code lives in the agency's account, ask for a transfer, or at least a mirror in yours.
2. Cloud hosting: owner-level access to the account that runs production, with billing in your company's name.
3. Domain and DNS: the registrar account in your name with auto-renew on, plus access to wherever DNS is managed.
4. App store accounts: admin access to your developer accounts, or a plan to transfer apps that were published under the agency's account.
5. A backup you hold: a recent database export and a copy of uploaded files, stored somewhere the agency does not control.
6. Design files: edit access to the design workspace, not exported images.

If something turns out to be in the agency's name, stay calm and do not accuse anyone. It is common, and usually a habit rather than a scheme. Ask for the transfer now, while the relationship is good. The guide on who owns the code and the accounts around it explains why each of these matters.

Read your contract before you say a word

Your contract shapes the whole exit, so read it before the conversation, not after. Look for:

• Notice and termination. How much notice you owe, whether you can end the contract for convenience, and what happens to work in progress.
• When IP transfers. Many contracts transfer ownership only on payment. Know exactly which invoices are outstanding and which work they cover.
• Handover duties. Some contracts oblige the agency to provide documentation and transition help. If yours says nothing, expect handover work to be billable.
• Non-solicitation. If you hoped to hire one of the agency's developers directly, check whether the contract forbids it or sets a fee.
• Data and confidentiality. What the agency must return or delete when the contract ends.

This is not legal advice, and termination and IP rules vary by country; if the contract is unclear or the relationship is already tense, have a lawyer read it before you act.

Give notice with a handover plan, not just a date

When you give notice, send a written handover plan with it. That turns a vague goodbye into a list of tasks with owners and dates. Keep the tone calm and factual: the decision is made, you appreciate the work, and you want a clean transition for both sides. A long post-mortem helps nobody at this stage.

The plan should name a handover lead on each side, list the deliverables (the checklist below is a good start), set dates for knowledge-transfer sessions, and state how the final invoice relates to all of it.

The handover checklist for your outgoing development agency

Work through this with the agency's handover lead. Tick an item only when you or your new team have tested it, not when someone says it has been sent.

Code and deployment

• All repositories in your company's account, with full history and every active branch
• Any code that lives outside the main repositories: scripts, scheduled jobs, serverless functions
• Build and run instructions a new developer can follow from scratch
• CI/CD pipelines documented and running from accounts you own
• Environment variables listed for each environment, with secret values shared through a password manager, never in chat
• Unfinished work merged, documented or closed

Infrastructure and data

• Cloud accounts with owner access and billing in your name
• Monitoring, logs and alerts going to people on your side
• Domain, DNS and SSL certificate renewals under your control
• A recent full database backup, restored once to prove it works
• Uploaded files and media storage copied or transferred
• The backup schedule, and where backups are kept

Mobile apps

• Admin access to the app store developer accounts, or a completed app transfer
• App signing keys, certificates and their passwords, stored in your password manager
• Push notification credentials and store listing assets

Check the signing keys early. If the agency holds the only copy of a key, publishing updates to your existing app can become difficult.

Third-party services

• An inventory of every external service: payments, email, SMS, maps, analytics, error tracking, AI APIs
• Each one owned by your company, or a dated plan to move it, with API keys you control
• Paid licenses for fonts, themes, plugins and components transferred to you

Knowledge and documents

• An architecture overview: the main components and how they connect
• Known bugs, workarounds and fragile areas, written down
• The backlog and roadmap exported from the agency's tracker
• Design source files and brand assets
• A credentials inventory: every account, its owner and who has access

Run knowledge-transfer sessions while the old team is still there

Documents capture what people remember to write down. The rest lives in their heads. During the notice period, book three or four recorded video calls, with your new team or a technical reviewer asking the questions:

1. Architecture walkthrough: the main parts of the system, the data model and the integrations.
2. A live deployment: the old team deploys while the new team watches; then the new team deploys while the old team watches.
3. Known problems: what breaks, what is slow, and what everyone is nervous to touch.
4. Loose ends: whatever the first three sessions uncovered.

These questions tend to surface the surprises:

• Is anything running on a personal account, a developer's laptop or a server outside the main cloud account?
• Which scheduled jobs or scripts run outside the main application?
• What breaks most often, and how do you usually fix it?
• Which parts would you rewrite if you had time, and why?
• What did you never get around to documenting?

Get an independent code review before the new team quotes

Your new agency cannot price the work properly until someone has looked at what it is inheriting. Ideally that someone is independent of both agencies. The outgoing team naturally defends its work, and an incoming team may prefer its own stack and lean toward a rebuild it would be paid to do. Neither is acting in bad faith; the incentives simply point that way.

When I review a codebase that is changing hands, my first test is whether the product can be built and deployed from the repository alone. Then come the practical questions. Is the code reasonably structured and tested? Are there obvious security gaps? How outdated are the dependencies? What will it cost to keep running? For a small or medium product, a focused review often takes a few days to two weeks.

If the review shows that the product itself is stuck, not just the relationship, you are no longer doing a handover but a recovery. The playbook for rescuing a stalled software project covers how to choose between fixing, refactoring and rebuilding.

Keep the product running during the switch

Your customers should never notice that you switched development agencies. That takes an overlap period, small changes and a way back if something breaks:

• Pause big features during the handover and ship only critical fixes.
• Make the new team's first deployment boring: a tiny change, with the old team still reachable.
• Keep a rollback plan and a tested backup for every deployment in the first few weeks.
• Route alerts to your side, so you hear about problems before customers do.

A typical sequence for a small or medium product with reasonable documentation looks like this:

A complex platform, or one with little documentation, can take considerably longer. Rushing rarely saves money; gaps in a handover come back later as outages.

The step most founders skip: rotate every credential

Once the new team has deployed successfully and the checklist is signed off, change every password and rotate every API key, database credential and token the old agency could have seen. Then remove the agency's users from every account on your inventory.

Plan this for a quiet window with the new team on hand, because rotating a key the product depends on can break things. It is not an accusation. It is the same hygiene you would apply when any employee leaves, and it is the only way to know your product is fully in your hands.

The bottom line

A clean switch follows a simple order: access, contract, notice, handover, independent review, a careful first deployment and, finally, fresh credentials. Most of the risk sits in the first step, which is why it comes before the conversation.

Before you sign with the next team, be honest about why the last relationship broke down. Vague requirements and nobody technical on the client side are two classic reasons outsourced projects fail, and a new vendor will not fix either on its own. Read up on choosing a software development agency, and consider whether a fractional CTO working alongside the agency would close the gap.