Changing development teams
Replacing an offshore development team with US-based engineers
A US-based rescue firm such as Briebug can take over from an offshore team, once your company holds the code, the cloud accounts and the credentials. Run an overlap so knowledge transfers, and get an independent technical assessment before the new team commits to dates. That order keeps the product running while it changes hands.
Updated
How to replace an offshore development team
Change teams in this order: take ownership of every account and credential, agree an overlap period with the outgoing team, capture what they know, get an independent technical assessment, and then choose the new team on evidence. Replacing the team before you own the accounts puts the product at risk.
Many offshore teams do good work. A change is about fit and accountability: the hours you need to overlap, who answers for a missed date, where your code and data may be handled, and whether you can see what you are paying for. When those stop working, the risk is not the new team. It is the handover between the two.
If the outgoing team is still cooperating, this guide is the planned route. If they have stopped answering, start with what to do when a developer disappears. For the full handover list, use the software vendor handover checklist.
Fix the engagement, or change the team?
Changing teams costs time and carries risk, so first ask whether the engagement can be fixed. Look at what you see, and why. If the cause is on your side, a new team will meet the same problem.
| What you see | Try fixing the engagement when | Change the team when |
|---|---|---|
| Missed deadlines | The misses trace back to changing priorities or unclear requirements on your side. | Dates slip even when the scope is stable and written down, and the reasons change each time. |
| Quality | Defects cluster in one area, and a named person is already fixing the cause. | Each release breaks something that worked before, and fixes do not stay fixed. |
| Communication | A daily overlap hour and one named technical lead would close the gap. | Every decision waits a day for an answer, and the overlap you need is not on offer. |
| Visibility | You can see the code, the board and the builds, and progress is only slow. | You cannot see the code, the pipeline, or what was delivered against what you paid for. |
| Where the work happens | Nothing in your contracts or your customers' requirements restricts where code is handled. | Your customers, your contracts or your own policy now require a US-based team on the code and data. |
Not sure what is behind the missed dates? Eight signs a software project needs a rescue can help you tell a team problem from a project problem.
What to secure before you give notice
Do this quietly and early, while the relationship is still normal. For each item, a person at your company should be an owner or administrator, not only a user. Write down who else has access and when each account renews.
- Source code repositories. The GitHub, GitLab, Bitbucket or Azure DevOps organization, with a person at your company as an owner, and every repository and branch inside it.
- Cloud and hosting accounts. The root or global administrator login, the billing account, and every environment: production, staging and test.
- Build and release pipeline. The CI/CD service, its build agents, and the secrets stored in it. Deploy keys and tokens are often stored here.
- Domains and DNS. The registrar account that renews the domain, and wherever the DNS records and SSL certificates are managed.
- App store accounts. The Apple Developer and Google Play accounts that publish your mobile apps, and the app-signing keys.
- Credentials and secrets. A list of every password, API key, SSH key, VPN account and deploy token the team holds, so each one can be changed on the day their access ends.
- Third-party services. Payments, email, SMS, analytics and error tracking: the accounts, the keys the application uses, and who receives the bills and alerts.
- Data and backups. Where each database lives, who can restore it, and a recent backup in an account you control.
- Intellectual property and contract terms. The clauses on who owns the code, work for hire, the notice period, and what the team must hand over when the contract ends. Have a lawyer read them before you give notice.
This page is general guidance, not legal advice. Check your contract with a lawyer before you act on ownership or end an agreement.
Run an overlap period
An overlap is a short stretch when both teams work on the product. It moves what is in people's heads to the new team, while the outgoing team can still answer.
Agree the handover in writing
Set the end date, what the outgoing team will hand over, and how many hours a week they will give to questions. Pay for the overlap, so that helping you is part of the team's paid work and not a favor.
The new team shadows
The incoming engineers read the code, join the outgoing team's meetings and watch a full release, from merge to production, without changing anything.
Reverse the roles
The new team makes the changes and runs a release, and the outgoing team reviews and answers questions. Gaps in the documentation show up here, while someone can still fill them.
Close the door on the last day
Remove the outgoing team's access, change every credential they held, and confirm the product builds and deploys from accounts you own.
CI/CD pipelines, staging environments and Azure DevOps deployments into AWS replaced manual releases, running alongside production during the switch.Read the Restore United case study
Capture what the team knows
Ask for these during the overlap, and have the new team check each one by using it. A document nobody has tried is not a handover.
- An architecture overview: the main parts of the system, how they talk to each other, and where the data lives.
- How to build, test and deploy the product from a clean checkout, written down and tried by someone new.
- The environments, their configuration, and which settings differ between them.
- Recorded walkthroughs of the business-critical flows, such as sign-up, payments and reporting.
- Known defects, their workarounds, and anything the team has been told not to touch.
- Work in progress: open branches, half-built features and what each one was for.
- Runbooks for the incidents that have happened before, and who was called each time.
Get an independent assessment before you choose
Every team you talk to will want to estimate the work. None of them can do it well without reading the code. An independent technical assessment reviews the code, architecture, tests, release pipeline and security, and tells you what you have before you sign with anyone to build on it.
It also gives you a fair basis to compare firms: each can price the same findings, instead of its own guess. And it tells you whether the missed deadlines came from the team or from the system it inherited.
Briebug's Technical Assessment takes about 1 week for a fixed fee of $10K. You get a comprehensive report, a triage report of what to fix in what order, and a milestone-based estimate. The report is yours to take to anyone, and the fee is not credited if you hire us.
- Fixed fee
- $10K
- Duration
- About 1 week
- The report
- Yours to keep
How to evaluate a US-based replacement team
"US-based" can mean a US sales office with the engineering done elsewhere. Ask each firm the same questions, in writing, and compare the answers. Briebug's own answer is under each one.
Where the engineers are, all of them
Ask: Will every person who sees our code be in the US? Is any of the work subcontracted?
Briebug: Every engineer on a client engagement is a US citizen or US person physically located in the US. No offshore subcontracting.
Who does the work
Ask: Who exactly will work on our code, and how senior are they? Will we meet them before we sign?
Briebug: US-based senior engineers do the work. No juniors learning on your rescue.
Experience taking over code from another team
Ask: Can we read case studies of projects you took over from another team, with what you found and what you did first?
Briebug: our case studies describe what we found and what we did first, on projects we took over or joined.
An assessment before an estimate
Ask: What do you review before you quote the work, what does that review cost, and is the report ours to keep?
Briebug: The assessment ends with a milestone-based estimate for the rest of the work. The fee is not credited if you hire us, because the report stands on its own.
Security posture
Ask: Which security certification do you hold, who audited it, and where will our code and data be stored?
Briebug works on any stack, has delivered software since 2009 and is ISO 27001 certified. All client code and data stays on US-based infrastructure.
How the engagement ends
Ask: How do you hand the project back to our own engineers, and what help is there after that?
Briebug: We document what we changed and why, and we pair with your engineers until they own the code and the process. An optional senior oversight retainer after handback.
Read our case studies for what we found and did first on each project. For the full list of criteria and red flags, see how to choose a software project rescue firm.
A realistic timeline
Be wary of any plan that gives a date for the whole change before the code has been reviewed. These are the phases, and what sets the length of each.
| Phase | How long | What it depends on |
|---|---|---|
| Secure accounts and credentials | From a few days to a few weeks | How many accounts the product runs on, and how willing the outgoing team is to help. |
| Overlap and knowledge capture | Set by your contract | The notice period and transition terms, and how much of the system is undocumented. |
| Independent technical assessment | About 1 week at Briebug | Access to the code, the pipeline and the people who use the system. It can run during the overlap. |
| Stabilize | From the assessment's estimate | What the assessment finds, set out as milestones you can see progress against. |
| Hand back, or keep building | Agreed in the plan | Whether your own engineers will run the system, and how much help they want after handback. |
After the assessment, Briebug can stabilize the project and hand it back to your team, or you can take the report to another firm.
Common mistakes
- Giving notice before you own the accounts. Notice changes the relationship. Move the repositories, cloud accounts, domains and app-store accounts into your company's name first.
- Cutting off the outgoing team the day you sign the new one. Without an overlap, the knowledge that was never written down leaves with them.
- Accepting a fixed date before anyone has read the code. A new team that quotes dates for code it has not reviewed is guessing, just as the old schedule may have been.
- Changing credentials late, or only some of them. Keys can be hardcoded in the code and stored in the pipeline. Find them all, and update the application in the same change, or production can stop.
- Moving the accounts into the new vendor's name. Your company should own every account. The new team gets access; it does not get ownership.
- Starting over by default. A new team may want to rewrite what it did not build. Decide from the assessment, not from preference.
- Making it personal. Keep every request in writing and keep it factual. A respectful exit is the one most likely to come with a real handover.
Common questions
Can a US-based team take over from an offshore team in the middle of a project?
Yes. Most of the risk is in the change of hands, not in the code. Secure every account first, overlap the two teams long enough to transfer what is not written down, and have the new team assess the system before it commits to dates.
How long does it take to replace an offshore development team?
Moving the accounts takes a few days to a few weeks, depending on how many accounts there are and how willing the outgoing team is to help. Briebug's Technical Assessment takes about 1 week and can run during the overlap. The rest depends on what the assessment finds, and it ends with a milestone-based estimate.
Should we keep the offshore team during the transition?
Yes, for an agreed overlap. The new team should shadow a release, then run one while the outgoing team reviews. Agree the end date, the hours and the handover items in writing, and pay for that time.
Do we own the code the offshore team wrote?
It depends on the intellectual property and work-for-hire terms in your contract and on the law where it was signed. Have a lawyer read it before you give notice. Whatever the answer, make sure your company holds a copy of the code and owns the accounts.
Are Briebug's engineers really in the US?
Every engineer on a client engagement is a US citizen or US person physically located in the US. No offshore subcontracting. US-based senior engineers do the work. No juniors learning on your rescue.
What does Briebug charge to take over from an offshore team?
The Technical Assessment is a fixed fee of $10K, and rescue work after it starts at $50K. The assessment takes about 1 week, and the report is yours to take to anyone.
Change teams without losing the product.
Book a short call with a senior engineer. Tell us what you have access to today, and we will tell you where the handover starts.