Switching Agencies Mid-Project
By CodexierPublished 5 min read
Changing agency halfway through a website or app project feels like admitting defeat, and it does cost time. But staying with a supplier who misses every deadline or has stopped answering costs more. The difference between a messy switch and a controlled one is order: secure your access and assets before anything else, document where the project stands, brief the new supplier properly and close the old contract cleanly. This guide walks through that order.
When switching is the right call
Some problems can be fixed in a frank conversation: unclear priorities, a changed contact person, scope that grew without anyone noticing. Try that first, in writing, with specific issues and a deadline. If nothing changes, the sunk cost is not a reason to stay.
| Signal | Fixable? |
|---|---|
| Missed deadlines with explanations and new plans | Often; renegotiate the plan |
| Missed deadlines without explanation, repeated | Rarely |
| No replies for weeks | Rarely |
| Quality problems that return after fixes | Rarely |
| Disagreement on scope | Often; clarify with a written change process |
Securing access and assets
The most important step happens quietly, before any announcement. Check that you, not the agency, own or have admin access to everything the project runs on. Our guide on who owns your website explains why this matters.
- Domain: registered in your company's name, with your own login at the registrar
- Hosting and servers: the account in your name, or at least your admin access
- Code repository: owner or admin access to the GitHub, GitLab or Bitbucket project
- CMS and admin panels: your own administrator account
- Third-party services: analytics, Search Console, payment providers, email sending, Google Business Profile
- Design files: access to the Figma or similar project, not just exported images
- Credentials stored somewhere you control, such as a password manager
Documenting the current state
The new supplier needs an honest picture. Ask the outgoing agency for a written status, and make your own list in parallel. Where the two disagree, you have found the risks.
- What is finished, tested and approved
- What is started but not finished
- What has not been started
- Known bugs and workarounds
- Environments: where the live, staging and development versions are
- Integrations and their credentials
- What has been invoiced and paid, per milestone
A short technical review by the new supplier, before they quote, is worth paying for. Code that looks nearly finished can be structurally unsound, and it is better to know before you sign.
Briefing the new supplier
Give the new team everything: the original brief and quote, the change requests, the status document, access to the code and the design, and an honest account of what went wrong. Hiding the conflict helps nobody; the new supplier needs to know which expectations were not met.
| Step | Purpose |
|---|---|
| Technical assessment of existing code | Decide whether to continue, refactor or rebuild parts |
| Revised scope and plan | Separate what is left from what needs redoing |
| Fixed price or estimate for the remainder | Only after the assessment |
| Clear ownership and access terms in the new contract | So this does not happen again |
Expect some rework. Few teams can take over another team's half-finished code without changing parts of it, and a supplier who promises none at all has probably not looked closely.
Settling the old contract
Read the termination terms before you give notice: notice period, payment for work done, ownership of code and designs on termination. Pay for accepted deliverables, dispute the rest in writing, and ask for a final handover of everything in the access list. Keep the tone factual; you may need their help with a question later.
- Give notice in writing, referring to the contract clause
- List what you consider delivered and what you consider owed
- Request transfer of all remaining accounts and files by a set date
- Confirm that the agency's access is removed afterwards
- If there is a real dispute over money or rights, involve a lawyer rather than escalating by email
When not to switch, and how we help
If the project is days from launch and the problems are cosmetic, finishing with the current supplier and switching for maintenance afterwards may be less risky. Switching is also rarely worth it over price alone. When a switch is right, we take over half-finished website projects: a technical review first, then a fixed scope for completing the business website. See pricing, or book a short call to talk through your situation.
Frequently asked questions
Can the old agency refuse to hand over the code?
It depends on your contract. If it says you own the code on payment, you are entitled to it for the parts you have paid for. If ownership is unclear, get legal advice before withholding payment or escalating.
Will switching double my costs?
It usually adds cost, mainly for the new supplier's assessment and some rework. It is still often cheaper than continuing with a supplier who is not delivering.
Should the new supplier continue on the old code or start over?
Decide after a technical review, not before. Many projects can continue with some refactoring; some foundations are too weak to build on.
How do we avoid this with the next supplier?
Keep all accounts in your company's name from day one, pay against accepted milestones, and write ownership of code and designs into the contract.
Stuck with a project that is not moving?
Describe where the project stands on a short call. We will tell you what to secure first and whether taking over makes sense.
Book a free 15-minute call