How to Successfully Change One Development Team to Another

What do you need to successfully change the development company with minimum stress? This article will help you transfer application development from one team to another. Here you will find a step-by-step project transition plan from one vendor to another, a list of required documents and checklists for a successful project transfer. Even for those who are just choosing the first development company, it will help to reinsure against this unpleasant outcome.

What are the reasons to change development company?

In any business, there are situations when, for some reason, it is necessary to change the contractor. From our practice, we have identified the TOP 3 reasons why people contact us with the task of completing a project:

1. Freelancers started the development, and you are unhappy with such cooperation;
2. Working with a previous company is too expensive / too long / too confusing;
3. The old team has collapsed or the developers lack competence.

For a business owner, the process of transferring a project causes a lot of difficulties due to a lack of understanding of how to do it correctly. For a person who does not understand programming, explaining to the new development team what has already been done and what remains to be done is an impossible task. This article will help to cope with it step by step. Let’s see how the project migration process takes place and what is needed for this.

Step 0 – Realize Mistakes & Formulate Expectations

Do not expect that the new company will become your magic pill and will solve all the problems in no time. It is better to pre-work on the mistakes and formulate understandable expectations.

To do this, answer the following questions:

• Why can’t the old team continue the project?
• What exactly was the old team at their best?
• What could be fixed/improved in the work of the old company?
• What do you expect from the new team?

By cleverly laying out all the pros and cons, you will increase the chance that bad experiences will not happen again, and the project handover process will be easy and understandable. The better you formulate your expectations, the more likely the new team will remind you of the old one only in a good light.

For example, if the communication process in the old team was too slow or inconvenient. Or you could not understand at what stage your project is and what work is being done now. Then describe what the speed of communication should be and what tools to use.

Do you expect answers to your questions within an hour or two? Do you want to track the development process in Redmine or Jira? So tell it to the new team. And of course, you should also adhere to all your requirements.

Step 1 – Find & Meet the New Team

This stage is the most important in order not to step on the same rake and ensure the successful future of your application. Since you have already started development, your choice is limited only to those companies that work with the technologies that were used in the project.

Search by technology on ranking sites like Clutch. Make a list of 5-10 candidates. Read the reviews about these companies, study their cases, which are implemented on the required technologies. Having done this, you will have 3-5 companies with which you can start communicating. Find out how the development process works in these companies and whether they are ready to take on a project that has already begun.

Of course, if your application is less than 30% complete, then we recommend starting from scratch rather than finishing what has already been started. In this case, the list of candidates will be wider, but then you will lose these investments. This is often a less expensive option than paying for the discovery phase and fixing the mistakes of the old team. As you read the article, it will become clearer to you which choice is best to make in your case.

The hallmark of a company that knows what to do with projects that have been started by another team is the questions you will be asked. Here are the main ones:

• Why did you break up with your previous team? You need to explain the reason for the decision to change the team. Tell us what was good and what was not.
• What do you expect from the new team? The more detailed you explain your vision of the work process, the more chances that you will not face the problem again.
• What are your plans for the short and long term? When do you plan to release? This question is needed to set the right time.
• Who from the previous command can be asked clarifying questions? Having someone on the old team in touch and ready to answer questions about the code will simplify and speed up the familiarizing process with the code for the new team.
• What do you have left from the previous team? The most important question that determines how the project acceptance process will take place. You need to list all documents and files that you have.

In a dialogue with a manager, you will already have an understanding of the company’s competencies. Discuss with examples from experience with the previous team how possible situations will be resolved. Clarify what the new team needs to get started on the project.

Here is all you need to provide to the new team:

1. Specifications for the project and road map.
2. Design project. Typically this is a Figma layout.
3. List of completed works. If the development was carried out according to the Kanban methodology, then there should be a kanban board. If according to SKRUM, then the product backlog.
4. Application source code.
5. Instructions on how to deploy the project.
6. List of used technologies, frameworks, libraries.
7. Reference information on API.

It’s good if you have all of the above, which rarely happens in practice. The minimum you need is specifications, source code, instructions for deploying the project and the API help. Without this, it will not work to continue developing the application and you need to start all over again.

Do not forget to sign a non-disclosure agreement before passing on the available information to candidates. If you do not have NDA, then you can read how to create it or use our templates. Then ask the candidates to look at the materials and make a conclusion about the results.

The result of the check will be a rough conclusion about the state of the code, a list of possible risks, terms for project completion and a wide price bracket. When you have collected the conclusions from all candidates, it is time to decide who you choose to go into the code-review phase. This stage will already be paid for you, so here are some tips on how to choose a new development company that will bring your project to the result:

1. Evaluate how detailed the preliminary estimation of your project is and how long it took. This will allow you to determine which company is most interested in working on your project.
2. Compare the scores with each other to understand the experience of each team. If the results are similar, and it is difficult to determine the leader, then…
3. Find out if the team has experience developing applications that have already been started by other developers. Ask managers to tell you more about these cases, let them provide links to them.

After that, you should already have an understanding of the competencies of the candidates and it will not be difficult to make a choice in favor of one of them.

Step 2 – Code Review

This stage can be called differently: code-review or discovery phase. This is the time it will take for a new team to figure out how the code works. Depending on the size of the project and the entropy of the code, this stage can last from a week to a month. This time is needed to delve into the architecture of the project, the structure of the code and understand the technologies. It is important to understand that without this stage, working with someone else’s bad code promises financial and moral losses.

You can’t skip the code review stage, it is needed to understand the relationships and “what influences what”. This will reduce the risk that something will “break” when the time comes to improve the project and introduce new features.

Do not expect that the new team will provide you with a detailed estimate of the timing and cost of work on the project until the code review has passed. Be prepared to answer a large number of clarifying questions or arrange with a specialist from the previous team to help you with this.

There is a chance that in the course of an acquaintance, the developers will say that the project is not subject to maintenance and scaling. In this case, the project manager will offer you one of two options.

The first option is to rewrite the project from scratch. Not the most pleasant situation, but effective and will solve many problems. Most likely you will be offered this option if your project falls into one of these categories:

• written more than 3 years ago – it is faster and cheaper to rewrite than trying to update the code to the current version;
• are so complex and incomprehensible that it is easier to rewrite the code than to try to understand it;
• do not meet the standards for scalability and performance – these are important parameters to consider in the architecture of the project;
• less than 30% ready – these applications are easier to start over.

The second option is likely if the project is almost completely ready, but the technologies used are outdated. In this case, you will be prompted for refactoring. That is, to update the project code in parts: replacing the old sections of the code with newer modern solutions. This is the most common trade-off offered instead of rewriting the application from scratch.

Step 3 – Acceptance Testing

If you are “lucky” and don’t need to rewrite the project from scratch, then the next step is to carefully document the existing bugs. This is necessary to avoid disputes about the causes of a particular problem.

The more code will be added (or updated), the more chances that bugs may occur. To find out whether this error is new or inherited, a document that will describe the results of acceptance testing is needed.

This is usually documented in Google Docs in the form of a description of the sequence of actions and the result to which it leads. Photos and videos are also attached.

At the end of the stages of code review and acceptance testing, a report is generated on the result of the analysis. The analysis results document usually contains:

• Number of libraries and components used
• Number of unknown (self-written) solutions
• List of detected errors, recommendations for their elimination
• Compliance of coding style with generally accepted standards
• Conclusion about the general “health” of the code and possible ways of project development.
• Preliminary estimate of the cost and terms of work on the project.

When all the work described above has been completed, new developers can start working.

The described sequence of actions is an ideal situation, in practice, everything may be different. For example, if the relationship with the previous company did not end well, then it is not possible to get feedback or the necessary documentation on important issues. This will significantly complicate the work for the new development team.

It’s always best to continue working with whoever you started with. But if the change of development team is a necessary measure, then remember that the source code of the application is the most important thing, without it, you will not be able to continue working on the project.

If you are faced with difficulties with your project, if you need a new team or your application needs to be “diagnosed” – contact us and we will help you find the right way. If you are just at the stage of searching for a development company – feel free to write/call us and you can be sure that your application will meet all the standards described in this article.