How to Switch Developers Mid-Project (Without Losing Everything)

To switch developers mid-project without losing work, do it in a fixed order: secure access and code first, get the existing code reviewed second, and only then let anyone build on it. Done in that order, a switch usually costs you a few weeks of momentum. Skip the first two steps and you risk paying for the same work twice.

I'm a freelance developer who takes over projects other people built, so I have a stake in this topic. The steps work no matter who you hire next.

The short answer

Where you start depends on how things stand with your current developer:

One rule covers all three: no new code until you have access to the old code, and no decision to build on it until someone has read it. If you're still looking for your next developer, my guide to hiring a developer covers that part. Come back here when the handover starts.

Is it the developer or the project?

Before you switch, spend ten minutes on an honest question: would a new developer actually do better? Every switch costs time, because the new person has to learn someone else's code. It only pays off if the problem sits with the developer, not with how the project is run.

Signs the developer is the problem:

• Deadlines slip again and again with no explanation you can follow.
• You get status updates but never see anything working.
• Fixes break things somewhere else.
• You can't get access to the code or the server when you ask.
• Replies get slower every week.

Signs the project is the problem:

• Requirements change weekly, and nobody on your side has the final say.
• The budget was set before anyone knew what was being built.
• Tasks arrive one email at a time with no priorities.

If the second list sounds more familiar, the problem moves with you to the next developer. Spend a couple of weeks writing down what you need and ranking it before you switch. Often it's a bit of both.

How to switch developers mid-project in 6 steps

These steps assume your current developer still answers emails. If they've disappeared, read the section further down as well.

1. Map everything the project depends on

A software project is more than code. It's also every account and service that code relies on. List them before you do anything else, and note who owns each account and who pays for it.

Expect the repository (the code archive, usually on GitHub, GitLab or Bitbucket), hosting and servers, the domain and DNS, the database and backups, transactional email, payments such as Stripe, app store accounts and any integrations like HubSpot or Xero. Go through your invoices and card statements. Anything your company pays for monthly belongs on the list.

2. Move every account into your company's name

The principle is simple: your company owns the account, and the developer is invited as a user. If an account sits in the developer's personal name, ask them to transfer it or add you as an admin while you're still on good terms.

Check the domain first. Look up who's listed as the registrant (the legal holder), and if it's the developer, have them change it to your company with the registrar. For .com and other generic domains, moving to a new registrar also requires a transfer authorization code (auth code) from the current one, as described in ICANN's FAQ for domain name holders. Country domains such as .de, .dk or .co.uk follow their own registry's rules. The codebase itself can move to your own GitHub organization, and a GitHub repository transfer keeps the full history, issues and pull requests.

Remove the old developer's access only once the handover is complete. Then change passwords and have the new developer generate fresh API keys for payments, email and other integrations.

3. Agree on a managed handover

The cheapest handover is one where the outgoing developer helps. Even if you're frustrated, keep it businesslike. Set a fixed end date and a short list of what you expect:

• All code pushed to the repository, including unfinished work on separate branches.
• Written notes on how to run the project locally and how to deploy it.
• A list of known bugs, workarounds and missing pieces.
• A walkthrough of a couple of hours with the new developer, if possible.

Pay for that time. The alternative is a new developer guessing their way around, which costs more.

Then read your contract. Many contracts transfer the rights to the code once the final invoice is paid. Under the EU Software Directive, an employer holds the economic rights to software an employee writes on the job unless agreed otherwise (Article 2(3)), but that rule covers employees, not contractors. A freelancer without a signed assignment often keeps the copyright, and the details vary by country. I've written more about who owns the code when you hire a freelancer. If you disagree on rights or payment, talk to a lawyer before you build further.

If the developer handled personal data, your data processing agreement should require them to delete or return it when the work ends (Article 28(3)(g) GDPR). Ask for written confirmation that local copies of the database are gone.

4. Have the new developer review the code

Before the new developer writes a single line, they should review what's there. This is where you find out what you've actually paid for. A useful review answers questions like:

• Can the project be set up from what's in the repository, or is something missing?
• How old are the framework and packages, and do they still get security updates?
• Are passwords or keys stored directly in the code?
• Are there automated tests, and do they pass?
• Are there backups, and has anyone ever tested a restore?
• How much of what you ordered is genuinely finished?

The output should be a short written report with risks in order of priority, written so you can follow it without reading code. For a mid-sized project it typically takes a few days to a week. A switch is one of the clearest cases for an external code review.

5. Decide: build on it, clean it up or start over

With the report in hand, you have three options:

• Keep building when the code is sound but unfinished. This is the most common outcome and the cheapest.
• Clean up first when the foundation holds but parts are messy, outdated or insecure. The new developer spends the first weeks stabilizing before adding features.
• Start over when the technology is obsolete, nobody can get the project running, or security problems run through the whole codebase. It can also be right for a small project where most of it needs redoing anyway.

Be wary of a new developer who recommends a rewrite before reading the code. Building your own thing is easier than learning someone else's, but you're the one paying for the easy route. Rewrites almost always take longer than planned, because old code hides business rules nobody wrote down.

6. Plan the first 30 days

The first month is about regaining control, not catching up. The order I recommend:

1. Stabilize: backups, monitoring and the bugs your users actually hit.
2. Ship something small and visible within the first couple of weeks, so you can see the new setup works.
3. Rank everything else, and agree on a fixed weekly slot where you see what's been done.

Expect the new developer to move slower at first. That doesn't mean you picked the wrong person. It's the price of taking over a codebase you didn't write.

What to do if your developer has disappeared

Maybe the developer took a full-time job, got ill or simply stopped replying. It's stressful, but rarely fatal, because most of it can be recovered through the providers.

Start with a written email that sets a clear deadline for handing over access and code. If you get no reply, you at least have a record that you tried. Then work through your list from step 1:

• Hosting and services: if your company pays the bills, the provider can usually restore your access once you prove you're the customer, for example with invoices and company registration details.
• The code: without repository access, the latest version often lives on the server. Once you're into the hosting, the new developer can pull it from there. You lose the history, not the code.
• The domain: if your company is the registrant, you can move it yourself. If the developer registered it in their own name and can't be reached, contact the registrar first. Most registries have a dispute process, and you may need legal help.
• The rights: without a contract that assigns them, you're in a gray area. Get legal advice before you build your business further on that code.

What a switch costs, and when I'm not the right fit

A switch costs you three things: handover hours from the old developer, a code review from the new one, and a ramp-up period with slower progress. How much that adds up to depends mostly on the state of the code, how well it's documented, and whether the old developer cooperates.

The most expensive scenario is all three going wrong at once: no documentation, no help and a codebase that needs cleaning up. The cheapest is a cooperative developer and a project where the code has lived in your own repository from the start.

Pick a new developer who works in the technology the project is built with. I work mainly in Laravel/PHP and JavaScript (React and Next.js). If your product is built in .NET, Java or Ruby, a developer with deep experience in that stack is a better choice than me. And if it's a standard WordPress site with an off-the-shelf theme, a WordPress agency can often handle it for less.

How to avoid ending up here again

Once the handover is done, use what you learned to set up the next working relationship properly:

• The code lives in your own repository from day one, not the developer's.
• Every account is in your company's name, with the developer invited as a user.
• The contract covers rights, termination and a duty to help with a handover. My freelance developer contract checklist walks through the clauses.
• Setup and deployment get documented as you go, not only when the work ends.

With me, clients own their code from day one, precisely because it makes a switch easy, including away from me. You'll find more practical safeguards in my guide on how to avoid vendor lock-in with your developer. And when you pick your next developer, use these questions to ask a developer before hiring to dig into handovers and access.

Next steps

If you're ready to switch, do it in this order:

1. Write the list of accounts and services today.
2. Get admin access to all of it.
3. Agree on an end date and a handover with your current developer.
4. Have the code reviewed before anyone builds on it.

If you need a developer to take over the project, here's how I handle maintenance and takeovers of existing web apps. I reply within one business day.

Frequently asked questions

Should I tell my current developer I've hired someone new?+

Yes, but only once you have admin access to the important accounts. It's both decent and practical, because handovers work best when the two developers can talk. Keep the message short and factual: when the work ends, what you need from them, and that you'll pay for the handover hours. The conversation about what went wrong can wait.

How long does it take to switch developers?+

Plan for a few weeks from the decision until the new developer is properly up to speed. The handover itself can take a week or two if the old developer cooperates. The code review takes a few days to a week, followed by a ramp-up period. If the developer has vanished, the timeline depends mostly on how quickly providers restore your access.

Can the old and new developer overlap for a while?+

Yes, and a short overlap is often the best money you'll spend on the whole switch. A few paid hours where the old developer walks through setup, deployment and the tricky parts of the code save the new one many hours of guesswork. Longer periods of both working in the same code rarely help, because responsibility gets blurry.

Does the new developer need to use the same tech stack?+

Yes, if you want to build on what you have. A developer who suggests moving to their own preferred language or framework is effectively proposing a rewrite. That can be the right call, but it should be a deliberate decision based on a code review, not a side effect of hiring someone with a different background.

Do I need a data processing agreement with the new developer?+

In most cases, yes, if they'll have access to personal data such as a customer or user database. They're then processing data on your behalf, and if your business falls under the GDPR, you need a written agreement covering that, wherever the developer is based. Put it in place before you grant access, and ask a privacy advisor if you're unsure what it should include.