Time to switch development agency? Here's how

By Weapp · Updated 2025-01-15

Switching development agency is done in three steps. First secure code, documentation, accounts, and access while the collaboration is still active. Then plan an overlap period of a few weeks where the old and new agency work in parallel for knowledge transfer. Finally, analyze why the collaboration failed, so the next vendor relationship starts on better footing.

Switching development agency often feels like a bigger step than it is. With the right preparation, it’s a manageable project spanning a few weeks – without preparation, it can get expensive, slow, and risky for the product. Here’s the process that makes the switch clean.

When is a switch warranted?

Separate a one-off miss from a pattern. A late delivery happens even to good agencies; repeated delays without warning is a pattern. Common signs it’s time:

Deliveries are systematically missed and communication goes quiet when things get tough.
Quality slips: the same bugs keep coming back, small changes take unreasonably long.
You’re dependent on a single person at the agency – and that person is on their way out.
Prices drift without scope growing, or every invoice is a surprise.
The agency has lost the expertise you need, for example in AI or your platform.

Always have an honest conversation first. If the answer is excuses rather than a plan, you have your answer. Also weigh the cost of switching against repairing the relationship – a conversation is cheaper than a handover, but only if it leads to actual change.

Secure your assets before terminating the contract

Do this while the collaboration is still working – it’s harder afterward:

Source code: your own copy and ownership in the repository, not just read access.
Cloud accounts and environments: accounts with the cloud provider should be in your name.
Domains and DNS: check who formally owns them.
App store accounts: Apple and Google accounts should be yours, with you as the owner.
API keys and third-party services: payment services, email, maps, analytics.
Documentation: architecture, operational routines, known issues, work in progress.
Data and backups: where they’re stored, how they’re exported, and who has access.

At the same time, read the contract: notice period, what’s included in an exit, and what the handover is allowed to cost.

Plan the overlap between agencies

The most common mistake is ending the old relationship before the new one is up and running. Aim for a four-to-six-week overlap where the new agency does a code review, takes over operational responsibility in stages, and can ask the old agency questions. Book structured handover meetings: architecture, operational routines, known bugs, and the backlog that never got built.

At the same time, freeze development. During the handover itself, no new functionality should be built – every change mid-switch increases risk and blurs accountability if something breaks. Also inform internally: support, sales, and others who’d notice if the product behaves differently should know a switch is underway and where to turn.

Expect to pay for the transition. A rough worked example: the old agency’s wind-down work can land at 40-60 hours and the new agency’s ramp-up at 60-100 hours. At agency hourly rates of SEK 950-1,600, the switch becomes a one-time cost of roughly SEK 100,000-250,000. That stings – but it’s almost always cheaper than letting the new agency do archaeology in an undocumented codebase without help.

Analyze what went wrong

An agency switch that isn’t followed by honest reflection tends to repeat itself. Go through the old relationship honestly:

Was the requirements picture clear, or did the agency have to guess what you wanted?
Was there a working rhythm for check-ins and decisions, or did everything get handled by email after the fact?
Was the problem competence, staffing, or prioritization at the agency – or a budget that never matched the ambition?
Who on your side actually owned the product and the relationship?

The answers determine what to do differently: more thorough reference checks, a clearer contract with milestones, more frequent demos, or a designated product owner internally.

Next step

A well-planned switch takes a few weeks and pays off in a product that’s workable again. At Weapp we’ve taken over codebases in varying condition, and we always start the same way: a code review that gives you an honest picture of where things stand before you decide. Facing a switch? Get in touch and we’ll take a look at your situation.

Frequently asked questions

Does the old agency have to hand over the source code?

It depends on what the contract says and whether you've paid what you owe. If rights have transferred to you under the contract, the agency is obligated to hand over the code. Without such wording, it becomes a negotiation – another reason to secure ongoing access to the repository from the start of the project.

How long does an agency switch take?

With an orderly handover, a switch often takes four to eight weeks from termination to the new agency working independently. Without documentation, or if the old agency is passive, it can take considerably longer, since the new agency then has to read its way into everything through the code.

Should I tell the agency I'm considering switching?

Usually, yes. An honest conversation gives the agency a chance to fix the problems, and if you move on anyway, the handover benefits from a professional tone. The exception is if trust is completely gone – then secure your assets and copies before you have that conversation.

Can a new agency take over any codebase?

Technically, usually yes, but the cost varies with the code's condition, the documentation, and the technology choices. A serious agency starts with a code review and then tells you what the takeover requires. Be skeptical of anyone who promises a seamless transition without having seen the code.

What do I do if the agency refuses to cooperate at handover?

Lean on the contract and put the requirements in writing: code, documentation, accounts, and data. If the contract allows it, withholding final payment can be leverage, but don't escalate needlessly. If you're getting nowhere, a lawyer specializing in IT contracts is the next step.