How to Switch 3rd Party Development Teams Without Going Insane

As a team that specializes in existing Rails applications, many of the projects we work on are inherited from other 3rd party development teams. The reasons for projects being moved from one development team vary – an agency closes up shop, shifts direction to a different focus, or the client is unhappy with progress from the dev team.

When we inherit applications from other agencies, there are a few best practices we follow to help make the transition as seamless as possible. Of course, the reason for changing dev teams can dictate how easy this transition can be – a team that parts amicably with a client will likely help with the transition much more than a team that was fired for not meeting the client’s standards.

Below are some of the steps we take to help clients and their projects successfully transition to a new development team without going insane.

Perform a code audit to assess risk and limit surprises

We begin more than half of our Ruby on Rails application projects with a code audit. This audit is a one-time, flat fee assessment of a code base’s health and stability done by one of our higher-level Ruby on Rails developers. We look at things like the gem file, automated tests, and database indexes to evaluate the state of the app.

At the end of this audit, the client receives a thorough 20-30 page document outlining our findings. The content of this audit varies widely based on the state of the application, but we always try to point out positives within the application as well as points of improvement.

When we’re inheriting an application, this code audit allows us to know what we’re getting into and set reasonable expectations early. We’ll see what’s brittle and what’s stable, and we’ll be able to recommend the best path forward with the client if everyone agrees to continue to work together on a project or retainer basis.

You can learn more about our code audit process in this blog post.

Communicate with the last agency thoroughly (when possible)

It’s beneficial to learn as much about an application from the people who built it (or the people who have been maintaining it in its recent history). While we’ll observe some things from our code audit, there’s much more to be learned by speaking with the people who have been working on the code.

If we’re communicating directly with the previous agency, we’ll send over some questions to be answered. Here’s a sampling of what we might ask:

• Where is the application hosted?
• What is the production site URL?
• What is the staging site URL(s)?
• How are SSL certificates managed?
• What has been your branching strategy?
• What areas of the application would you consider being ‘high-risk’ when it comes to code changes?
• What areas of the application would you consider to be areas that would benefit from refactoring?

These are some of the baseline questions to get answered when we inherit a new project. When a previous agency and a client are parting amicably, we’ll communicate more extensively during the handoff period to learn more about the application.

Set expectations about ramping up on a new project

When a company has been working with the same set of developers for many months (or years!) they may be used to a certain level of productivity or turnaround time on development requests. A team that has been working on an application for an extended amount of time will be more comfortable working on it and deploying features. They know how things are intertwined and will worry less about breaking things.

We’ve worked on enough applications to know that getting familiar with a new app takes time. We get a bit of the “lay of the land” during a code audit, but that’s more like dipping a toe in than really taking a swim within the weeds of an app.

During our initial conversations with a potential new client, we speak openly about how long it may take to see progress on new feature development. Since we work primarily on a retainer basis with projects, we may begin with a larger retainer amount to account for the initial time it will take us to find, test, and fix certain pieces of the app. If a client comes to us with short timelines to get certain features released, we'll temper expectations to make sure everyone is on the same page.

We lean toward “no surprises” for the clients whenever possible. It’s better to set the standard that the first 90 days will be a work in progress than to promise unrealistic accomplishments within the first few months. We always want to exceed expectations when possible instead of falling short.

---

Transitions between development teams are a common and often necessary part of an application’s lifecycle. It’s one reason why we try to follow conventions as often as possible when working on a client application – we know we won’t always be the only team working on an application for its entire lifetime.

While transitions between development teams can feel like a tumultuous time where things feel unsteady, these few steps can make a big difference in helping the handoff go as smoothly as possible.