Safe Transition of an IT Project from One Vendor to Another

• Key aspects of the project transition plan to consider
• Business aspect (Transition speed and information completeness)
• Security (Access and confidentiality)
• Technical aspect (Must-have documentation)
• Finances (Be aware of unpredictable expenses)
• Human factor (Meetings and estimates)
• What comes after completing the project transition plan?
• Technical audit
• The final note on the IT project transition

Working on a big software development project can take years, and during this process, many things can change. Often, you might even need to switch your vendor in the middle of the development process. But moving your project from one software development vendor to another is not a walk in the park, and there are many important factors to consider. Join us as we go over them in this article.

As a custom software development company, at SECL Group we have successfully completed IT project transitions so many times that it has become our new area of expertise. In our experience, any decision to switch vendors tends to take place when a project has already been in development for a few years, typically when the outgoing team lacks the quality or resources to support or further develop the project. But there are risks, and if you carry out the project transition the wrong way, then it can take your new team a costly amount of time to actually begin working on it.

In this article, we’re going to touch on the critical aspects of IT project transition. While some may think that project transition deals with technical aspects only, in our opinion, business, and security factors are sometimes even more important. So, let’s talk about these first.

Key aspects of the project transition plan to consider

Business aspect (Transition speed and information completeness)

If a project transition goes well, your new team can start working on a project ASAP and spend minimal time studying its specifics and extraneous details. The previous provider is free to choose whether or not to share information about the project with the new one. Where a provider chooses not to share, work on the project can be significantly slowed down and bottlenecks are created for your new vendor to deal with.

At SECL Group, we’ve often found ourselves in a situation where we’ve received zero information about a project and have had to study it from scratch. In an extreme case, on one occasion our team even received a project that had been deliberately tampered with, so we couldn’t start working on it right away. We’re proud to say that even in such an instance, we were able to figure things out and start work within a reasonable timeframe. As we say “Nothing is impossible, the question is how much it takes”.

In any case, any project simply cannot be ready for transition the moment you decide to switch your IT vendor. A process of preparation should be carried out, which is why you first need to ask your previous team to prepare code documentation, specifications, etc. To mitigate the loss of project knowledge, you can engage your new team as early as possible to take part in knowledge transfer.

These indicators would suggest that your project transfer has worked effectively:

• Fast knowledge transfer from one team to another.
• The new vendor has very few bottlenecks and questions before they actually start working on the project.
• The new development team jumpstarts a project quickly and makes further development effective.
• Continuous work on a project is possible.

With the joint efforts of your current and future project vendors, you will be able to make your software transition plan more efficient and spend less time and effort on this process.

Security (Access and confidentiality)

After your software transition is complete, your former contractor should have no remaining access to your project and store no materials on their devices. You can even add charges for violating this into your NDA. But bear in mind that there is no surefire way to check if all of their employees have deleted your project’s files and accesses, which is where different security issues can arise.

At SECL Group, we once had an experience with such an issue. A local mass-media company turned to us to redesign its website while keeping its technical basis. Our team had to transfer the project from the old server to a more powerful one because the website was running slowly. At first, the tasks seemed relatively straightforward and we began by moving the website to new servers. Yet right after we’d done it, the website went down.

We discovered that the problem was RAM leakage because of faulty project implementation. The previous team had developed a script that reloaded the server in critical moments, yet nobody from the previous team had told us about this script while we migrated the website, so we didn’t add it and therefore couldn’t launch the website. Such a little thing became a major obstacle to normal website operation. Thankfully, we were able to resolve this problem and the website ran smoothly later on.

But we couldn’t call this situation a safe software transition. Of course, this wouldn’t constitute a typical situation, but it goes to show that you should always be thinking about your project’s security. In any case, you should ensure that you have kept your backups updated before you start executing your IT project transition plan.

Furthermore, you need to pay attention to creating new credentials. Your new vendor will need access to your repository, task-tracking tools, and a whole host of other things. For this, you should deactivate your old team’s accounts and create new ones. Ask your new team in advance about the accesses required to start working on your project.

Technical aspect (Must-have documentation)

Transferring project documentation is the most important part of any transition. With well-prepared documentation, your team will know the answers to all of the questions about your project specifics. They will also be able to dive into the project’s details with ease. 

We’ve made a helpful project transition checklist with all of the technical considerations necessary for a successful project transition. Make sure to update, collect and tick them off before you start the transfer process:

• Tech stack description (all the programming languages, frameworks, and libraries)
• Source code
• Software architecture
• Project deployment documentation
• Development environment documentation (additional software on the server)
• API/integrations documentation (if used)
• Design style guides and mockups
• Testing plans and specifications
• Information about APIs

For a large project, it’s essential to have all this documentation for a successful transfer and it’s great if you already have them. For smaller ones, you may overlook some of the points or unite several documents into one.

Finances (Be aware of unpredictable expenses)

Now, let’s talk money. Moving your project from one vendor to another does not come cheap, so, therefore, you need to prepare your budget for it in advance. While some direct expenses are easy to predict, such as termination fees, there are some things you might not take into account at first. They include a decrease in team productivity, disruption of work and parallel working carried out by both your old and new vendors during the transition period. Make sure to factor these costs in while calculating your vendor transfer budget.

Human factor (Meetings and estimates)

No matter how much attention you pay to the technical aspects of a project transfer, they aren’t the only thing that will define your success. We are all human, and communication in IT is crucial. For starters, you can organize a meeting between both teams so they can have a conversation about the project’s features, especially about the so-called “technical debt”. We understand that discussing it with the new vendor can be unpleasant, but it can help them a lot.

Apart from that, you can discuss the possibility of having separate, hourly consultations with the front-end and back-end developers of your former team. This way, the new team will know about any potential stumbling blocks and have a better understanding of project logic. It will all be beneficial for smooth project transfer.

It may seem like a small thing, but such meetings can save clients tons of time, especially if engineers have built your software from scratch. Here are some other types of meetings you could organize between your teams if needed:

• Q&A sessions
• Demos
• One-to-one meetings

Remember, your new team won’t be able to give accurate estimates if they work with legacy code, even after they perform a technical audit and have documentation. But if a vendor transition is done right, the new team will be able to give at least some rough estimates and make them more accurate as they study your project.

In such cases, our team provides rough estimates the following way. First, we take one hour to study the task and the old code and issue our first estimate. Then, we make a rough estimate of how much time we will need to complete the task/s. If we require more time than expected, we immediately inform our client about this and also explain why we need this extra time. Furthermore, at first, we spend some time on refactoring but rest assured that it will pay off later as it enables faster work, more accurate estimates, and a more predictable pattern of work for the client.

What comes after completing the project transition plan?

Once you are done with the IT project transition, we recommend starting a technical audit to identify problem areas in your project. Any project always has things that need improvement, but there are some critical aspects you may not know about until you run a technical audit of your project.

Technical audit

For the project owner, a technical audit provides an independent snapshot of the current situation; and for the new software development team, it is a great opportunity to get acquainted with the project’s specifics. For most projects, a technical audit takes 40-100 hours to complete, but large projects and ones featuring non-standard specifics can require more time, and although it’s impossible to cover the entirety of a project’s code during an audit, it allows your new vendor to better understand the big picture.

With a technical audit, the new team gains more insight into your project’s health and, according to it, can give more careful estimates on the time and cost of their work. Very often, projects need some code refactoring that will speed up the work of your new team.

When you switch vendors, you also need to pay attention to any bugs in your code. It can be very hard to find out whether they have come from the old or the new team’s work. An audit will reveal the vulnerabilities in your project that can help you identify the root cause of bugs. For instance, you may learn that there are no unit tests or that they don’t have enough coverage. To avoid bugs in the future, you will have to cover the project with tests or inform the client about potential problems. A thorough audit can help prevent a great deal of trouble for your project in the future.

The final note on the IT project transition

Having worked in the software development industry for nearly 20 years, at SECL Group we’ve seen a whole host of different situations during project transitions from one vendor to another. In each case, we’ve spotted inefficiencies and potential areas of improvement, and have noticed that product owners often lose a lot of time and money on the process.

If you are just considering knowledge transfer from one IT vendor to another for your project and don’t know where to begin, feel free to contact us. Especially if you are non-tech-savvy. Rest assured that we are well-placed to help you figure out the specifics of your project. Simply book your first free consultation with us, and together we’ll create the perfect plan for your project transition.