Software Development Project Transition How-to

Software development project transition doesn’t have to hurt.

You find a software developer. They work on your project and everything is fine. At some point, they disappear or mess up so much you know you can’t rely on them in the future. Or you have been developing an app in-house, and your team can no longer work on it.

It’s time to google other programmers, choose the best and complete the project.

At that point, you already have an infrastructure set up, basic code written and processes in place. The very thought of transitioning the project makes your head spin with questions and doubts. How do you make sure the new developer gets all the nuances? Will they be able to read the code? How can you spend less time and money on the transition?

Contents

Read on and you will learn how to prepare for the transition early and streamline the process. At the end of the article, you will download the checklist of the transition plan in PDF.

Why Companies Transfer Software Projects

You may still think you are not going to need to change developers. Why would you do that? Here are four stories from our practice showing what made companies transfer software projects to us.

Abandoned Projects

One company had its project abandoned by the original developer. They came to us for help because that developer wouldn’t respond to their calls and messages.

Luckily, the client had the source code and access to the software infrastructure. We reviewed the code and completed the project. If they hadn’t had that data, they would have had to start from scratch.

Ended Partnerships

One company partnered with a developer on a Ruby on Rails project. At some point, the developer launched their own product and was no longer interested in the partnership.

The company decided to outsource the project to us. The programmers who built the software from the ground up gradually handed the project over to us.

Startup Acquisition

A large company acquired a startup. The startup’s original IT team stayed for a while but decided to quit later. The new owner asked us to replace them, so we ensured a painless transition.

Developer Replacement

This happened many times. A company was unhappy with its outsourcing vendor. It consulted with us to see how we could improve things, liked our suggestions and handed the project over to us.

Are you in a situation similar to those four? Let us know and we will get your Ruby on Rails or React Native project rolling towards success again.

Software Project Transition Plan

Everyone who needs to change developers wants a step-by-step software project transition plan or a project transition checklist. But it’s difficult to suggest a one-size-fits-all approach because every project is unique. Instead, we suggest sticking to three key principles.

1. Keep Knowledge Transfer in Mind from Day One

When you’re just starting out, you likely don’t know whether you will need to change developers in the future. But there is a big chance you will. To be on the safe side, check their projects and reviews before you start the work. Anyway, there is a big chance you will change contractors. And if you do, the process will be easier if you have laid the groundwork for knowledge transfer in advance. Here’s how you can do that.

• Standardize the development process.

Choose a development methodology (e.g. Agile) and stick to it throughout the project.

• Automate whatever you can.

You can automate testing, deployment, scaling and other operations to a varied extent. Once you have done so, write manuals. By referring to those manuals, another developer can run those operations in a few clicks, even if they are not yet familiar with the project’s specifics.

Some operations can’t be automated, though. For those, you can create protocols with step-by-step instructions.

• Document the process.

Ensure that you document the business logic, goals and features of the software you are building. The same applies to the changes you make and test results. This will help new programmers get on board faster.

• Keep technical debt to a minimum.

Accumulating tangible technical debt will make it difficult for a new developer to figure out the project priorities. Avoid the debt so it doesn’t slow things down.

2. Take It One Step at a Time

One does not simply rip a project from a developer’s hands and throw it at another developer. You need to proceed step-by-step.

Here are six useful tips around which you should plan your project transition. Some may not apply to your case, but if you manage to use at least four, you will save yourself a lot of trouble.

• Reduce technical debt.

That is something you should do before transitioning the project to another developer. Otherwise, they will get bogged down with a mess of tasks.

• Introduce the new team task by task.

Let your new programmers get familiar with the project before they take full responsibility from their predecessors. Then, prioritize the scope of work.

• Set up a test period for the new team.

Allow for some time to see you are not trading good for bad (or bad for worse).

• Establish communication between the two development teams.

Make sure that the new team can consult their predecessors for 3–5 months after the transition has begun.

• Unify collaboration.

During the transition period, assign roles across the two teams and ensure that everyone knows who does what. If the developers use different approaches to programming, make sure there is no conflict.

For instance, one team may be using daily standup meetings, while the other is used to weekly updates. In this case, find a solution that would work for both sides.

• Use a data transfer checklist.

You will need to transfer various data from one developer to another. The incremental approach will help you do that efficiently. We suggest using this checklist:

3. Leave No Loopholes

Finally, you need to provide the new outsourcing developer with access to the different parts of the project and restrict the old developer from accessing those. If you overlook something, this might compromise the integrity of your production system, databases, server infrastructure and accounts in third-party services.

The first thing to do is to make sure you only provide the new developer with access to services and resources they need to do their job.

You should also make sure you have access to every service and resource. Otherwise, you may realize one day that your new developer can’t fix a bug because they don’t have access to a conflicting service. And their predecessor is not answering your calls.

Over to You

Software development project transition may sound complicated. But if you plan ahead and split the process into smaller steps, it’s not that difficult.

Download the step-by-step guide to simplify transition process.  

Document all you can, especially what software and services you are using in your project. This will help you ensure that nothing leaks out and that your new developer won’t have to chase after the previous one for accesses and passwords.

If this still sounds like too much work, Rubyroid Labs can do most of it for you. We have taken over all kinds of Ruby on Rails and React Native projects since 2014. As a result, we worked out a foolproof IT service transition model. Just write to us.