How to Make the Transition of Your Software Project From One Vendor to Another

Liubomyr Miller

Delivery Director

Victoria Sukharevskaya

Delivery Manager

There can be multiple reasons for a project vendor switch: the app has matured to significant improvements, or the MVP didn’t live up to the client’s expectations. Many cases result in a software transition plan, creating conditions in which technical support and development of the project have become the most popular service of mobile and web development studios. 

Relay races with the transfer of the project from one team to another have not yet become firmly established in everyday life. Many companies would rather choose to stick to the same development supplier because of the risks that creating a stable knowledge transition plan for software projects imposes. However, we are here to prove that even the most complicated solutions can be implemented seamlessly if you pay attention to detail. 

Why Do You Need an Established Application Transition Plan?

Sometimes, the old manager leaves the project, and you start noticing that the dev team went off the beaten track. Alternatively, working with the old team may become too expensive for the client and force them to look for a cheaper option. 

The question “Why did you part ways with the previous vendor?” is always the first one we ask when we start developing an IT project transition plan. Nevertheless, there can be multiple reasons for this, and the human factor is far from being the most important.

Buggy application and negative feedback from users

This situation arises when your application relies on technology that is not keeping up with the times, either unintentionally or on purpose. The publisher may, in fact, decide not to release new updates to its technology for various reasons. Of course, this is a solid reason to start searching for another vendor.

Unmotivated delays on releases

The previous contractor may not be meeting important deadlines. Is their lack of necessary competencies clear? Remember: missing deadlines is an important reason for coming up with a software transition plan checklist. Of course, switching to a new vendor doesn’t mean rebuilding the app from scratch. Despite requiring immediate, unforeseen solutions, switching saves you much more in the long term.

No dynamics and lack of efficiency

You will likely be faced with a frozen application if your dev team shows no consistency in their progress. The efficient separation of roles and responsibilities is crucial for dynamic development. If you notice tremendous irrationalities in how the software team’s work is arranged, you should consider moving to another architecture. An IT project transition plan template will allow your app to evolve. 

No sufficient communication

What do you want as a client? In addition to advancing your competitors, be sure to meet your users’ expectations. If your application no longer resembles the initial plan, you feel frustrated because of the lack of communication, and correcting each minor error takes ages — you should switch the vendor. 

Distorted focus

Indeed, an IT transition plan is also an opportunity to clean up or enrich an application or to reformulate its evolving needs. In a computer development project, it is estimated that almost half of the desired functionalities are never used. Using the Agile methodology in your projects allows you to focus first on the most important features and limit this percentage.

Slowing down the scaling process

This can quickly become problematic because your application, developed at a given time on a certain version of the technology used, risks falling behind if the updates are no longer installed. This risk is all the greater if your application uses peripherals that would continue to benefit from new updates. It could end up not supporting them anymore, and the scaling will become even harder over time.

Exceeding budget and deadlines

Several factors directly impact the development costs. Evolutions that make any maintenance operation laborious, the economic situation, new technology used, or bug accumulation cause going over budget. The vendor should feel free to reconsider the initial budget, but the procedure should be clear and within the legal terms of the contract. 

Lack of automatization

Tools like Jira and Confluence allow you to follow the development process and see each feature’s progress in real-time. If your company keeps everything behind closed doors and you often feel a lack of transparency — do not settle for less. It’s time to move on. 

Lack of tech documentation and requirements

A code or application audit will help us see more clearly and let you determine the aspects where your software can evolve or if it will be necessary to restart everything. However, the old vendor should be ready to cooperate as sometimes the knowledge transition plan for software projects is bound to people. Responsible documentation handling should always result in a clear SDLC process.

Challenges in Switching the Vendor: Overcome Them With a Reliable Application Transition Plan

Even a minor refinement, in the form of the remaining 15%, results in huge expenses not provided for by the original budget. If the previous contractor completed only half of the work, it would most likely be more profitable to start from scratch. Sometimes, dealing with the legacy of a previous developer can be much more time-consuming and difficult than starting over with an IT project transition plan template. What other challenges might you face?

The Current Vendor Denies to Cooperate During the Software Transition Plan

If a manager introduces people to someone else’s team, it’s worth finding out if it’s a product team or freelancers. We noticed that freelancers do not have the habit of working according to corporate principles. They very rarely hold on to the product with their heart and soul. They just make money and have no interest in the release’s success. 

Previous vendors may also sabotage the project transfer because a software transition plan is a painful procedure for their ego. In the worst case, they won’t share all the necessary documents, and we will have to carry out most audits by ourselves. However, this is not the end of the world.

How to check the vendor for quality (professionalism, seniority, and maturity)

The search for a contractor must be approached thoroughly, and especially if you do not have much experience in dealing with IT companies, the main thing to focus on is interviews with performers and management. It is important to understand how transparent the project management processes are in the company and how well-established their methodology is. Talk to them to get a better idea of what it will be like to work with this IT company. You can also study any IT project transition plan template to have a better understanding.

Here are four aspects that define software development quality:

• Vendor’s professionalism — A responsible approach with attention to detail should be seen in everything, starting from the offered solutions to documentation.
• Team seniority — Choose development companies that are able to retain talent and take care of their employees. The team consisting of senior developers, business analytics, and designers is a good sign.
• Software company’s maturity — The product is constantly evolving, taking into account user feedback. The vendor keeps track of all processes and carries out detailed measures to ensure them.
• Vendor’s experience — Has the company dealt with the same/similar projects before? How successful were these cooperation cases?

Very often, an IT project transition plan opens up a new look at your product and can ultimately solve the accumulated problems by bringing your project to a fundamentally higher level. 

Agreed SLA

SLA (Service Level Agreement) is a document that regulates the working relationship between the client and support. It describes the situation in which this document was required, the amount of support (number of hours per month), roles on the project, response time depending on the status of the task (critical, urgent, normal), what the result of the response will be, as well as how it is planned and the terms for paid time for the project manager, developer, tester, analyst and designer.

SLA work is the result of negotiations. So, taking over a project means new discussions based on the current conditions. Every development team is free to define its comfortable format of cooperation. Thus, the SLA will differ from one vendor to another, but such things cannot be left in the form of an oral agreement.

Users shouldn’t notice the switch to another vendor

If your goal is to serve the end user and make them more productive, integration is a no-brainer. Today, it is often said that employees are “timeless.” And, because the software market is so saturated, users are bound to have high expectations. 

An IT transition plan should take this into account and create the base for a smooth transition. Finally, after you exchange the development process for a tangibly more qualitative provider, a new company will take care of the previous bugs, thus making the user experience even better.

Challenges in Switching the Vendor: Overcome Them With a Reliable Application Transition Plan

Building a new web of audits and human connections is difficult. Thus, an application transition plan requires maximum cooperation between the client, the previous software team and the new software team. Of course, we won’t do everything from scratch, but to know where to start, Devlight carries out a few important audits as well as analyzes the current workflow.

Documentation, access, and communication channels brief

The longer a team works on a project, the more it covers functionality with good code. At first, these are partial edits, but over time, this code covers the entire project. Of course, can be painful to hand over your masterpiece to another vendor. The team may not agree with this, but evidence is needed.

The acceptance test document, which includes all the functionality and bugs, will be used to analyze the current situation and determine the success of the project. Both the client and the performer are responsible for it, so they should take care of each other’s time and effort. A brief can be used as insurance against counterproductive showdowns on the topic “Is this specific bug new or inherited?”

Even Google Docs can be used for bug documentation: attach photos or videos and describe the actions step by step and what they lead to. Problems should be described as specifically as possible. Some of the bugs may be less critical than others. Whether we should fix them now or wait — it’s up to the client. 

Finally, let’s not forget the IT transition plan is also an analysis of the reasons for the transfer of the project (inability to fulfil the strategy, poor understanding of the requirements, etc). We usually ask the client for their point of view to avoid possible miscommunications in future cooperation.

Knowledge transfer 

Sooner or later, everyone has to accept the knowledge transition plan for software projects. In order to do this effectively with minimum risk for the client/project, we recommend following the scheme above, created and perfected by dozens of successful Devlight cases.

Of course, modern development frameworks are extremely helpful in project management, and in general, all the ceremonials and roles in the team are known, but there is always room for improvement, so it’s better to understand the team’s activities from beginning to end when designing an application transition plan.

It is worth noting that it is best to conduct KT when it is possible to keep 2 teams in parallel so that new employees gradually join the development process, deal with system configuration, and process systems together with knowledge holders. For example, using JIRA, which helps us deal with the life cycle of a defect, requires knowing many details of the previous workflow. Nevertheless, this step is often skipped.

Code Audit as a Part of Software Transition Plan

Knowledge transfer, mentioned earlier, does not reveal all the problems of the project. To fully comprehend the code, the team needs to start coding. The code review should result in developers saying: “OK, we know what to do and how to handle the project further.” But implementing new features and dealing with dependencies is another story.

If the performance of your current contractor raises questions, it is best to seek an audit from a third party. A professional view from the outside will allow you to assess the situation and find the least costly way to solve the problem. The Devlight code review means the customer receives a specific list of what needs to be fixed. Even if they later decide to choose another vendor, they can use this document, which summarises what is wrong with security, scaling and other aspects.

Design audit

We conduct interface audits according to the same principles as we develop the design: feasibility, reliability, convenience, and acceptance. You can call them the four qualities of the interface. During development, we create these qualities, and during the audit, we check them.

The interface should allow the user to perform their basic tasks. This doesn’t just apply to buttons — scripts may not work either. At the same time, we check if the interface allows scenarios to be passed in alternative ways. The principle of convenience helps to evaluate how effective the patterns the designer has chosen are — in other words, how quickly the user solves problems. We then attach the screenshots to your IT project transition plan template.

Finally, can we discuss the UI? Yes, but we that’s not all we focus on. Everything influences the perception: understandable texts, brand voice, animations, illustrations and the number of menu items — each element works to ensure that the interface establishes a positive relationship with the user.

QA audit

QA helps us assess how much the IT transition plan client is potentially losing based on Firebase analysis. Firebase is Google’s mobile app development platform that provides state-of-the-art features for developing, repackaging, and enhancing apps. Firebase is, at its core, a set of tools that developers can use to create and modify applications based on their needs. The goal of Firebase is to solve three main problems for developers:

• Quickly create an application
• Issue and provide robust health monitoring
• Engage users

Some of the most popular features of the Google Firebase platform include databases, authentication, push notifications, analytics and file storage. We analyse these features and more as part of an IT project transition plan.

Analytic analysis of the product

As a code review is based on the technical side, the marketing department deals with measuring app performance in terms of user efficiency. Analysing the business model and product processes must get us answers to key questions:

• Who is this product for?
• What is its central service?
• What is its priority functionality, and how is this priority supported?

Perhaps the client has been moving in the wrong direction with their old team. The task of another vendor is to find the right path, believe in this path and convey this confidence to the client.

Software Transition Plan Demo + Conclusion 

The more entropy in the project, the longer drawing a software transition plan checklist will take. Our practice shows that it can last from a week to a month. This is enough time to understand the nuances of the code and study the architecture and technologies. In the result, we summarize our analysis and make up a short budget conclusion: 

• Everything is ok, so the client has to pay just for a few new features;
• We cover the technical gap (in case there are too many product bugs to start immediate work)
• The final option is to rewrite the code from scratch

Although the client wants to know the exact terms and plans, any IT transition plan should start from the stage: “let’s figure it out first, let’s see how things work there.” Meetings should be very frequent at each stage.

How Our Team Creates Software Transition Plans That Work

Regardless of the reason why the project is going to other hands, the new team is expected to be rescued. The job of the manager is to set the frame for the whole team’s cooperation: talk, ask, answer, and explain.

Once the client understands your goals, we make sure to measure their success in achieving them by setting appropriate key metrics. The stated goal reflects the intended result. At the same time, we need some kind of benchmark to assess the success of achieving this result. This is why we set SMART goals. SMART goal setting provides clear and measurable indicators of success that can be easily identified at the end of the project, describing to what extent these goals have been achieved.

The Devlight software transition plan checklist also contains the next questions for the client:

• “What did you not like about the old team, and what did you like?”
• “What are your plans for the project?”
• “What audits/briefs/documents can you provide?”

After that, the manager and the client agree on the time that the team will devote to getting to know the code. A week, two weeks, or a month — the term depends on the size of the project. Sometimes we can refuse to review the code if we plan to rewrite it fully. Partial refactoring acts as a lifeline, which will simplify and reduce the cost of development in the future.

We will start working on the acceptance document after the software transition plan contract is concluded. It describes the project, its functionality, and its bugs. The acceptance document will insure the new team from liability for problems left after the previous team and save time and nerves for all project participants.

We make sure to arrange the knowledge transition plan for software projects according to SLA, determining the arising tasks according to the degree of criticality, response time and required result. Devlight understands that it is necessary to predict the timing, taking into account possible risks that the client should be aware of.

Project Transfer Blockers

Changing a contractor when developing an IT product (whether it’s a mobile application, website development, desktop application, or customization of a ready-made solution for yourself) is always painful. Clients want to avoid it with all their might. Why? Because specific pitfalls accompany the whole application transition plan process. 

Occuring budget override

Implementation of a knowledge transition plan for software projects costs money. Whether you’re hiring freelancers to write content or a catering service provider to host an event, you’ll likely need to spend a certain amount of money.

Since you have already identified the goals and stakeholders in the project plan, this information can be used for budgeting. For example, if this project involves multiple departments, will the costs of the project be shared among them? If you have a certain measure of success, such as the number of participants in an event or the number of new users, is your estimated budget capable of meeting that measure?

Creating a budget during the IT project transition plan (before you start any spending) will ensure that the financial side of the contract is fully agreed upon. Devlight will take over the entire setup of the process and show you all the materials — audits, artefacts and documentation. 

The slowdown of the release process 

Clients don’t want to wait a long time for the next releases, but following the software transition plan checklist is essential for preparing the project release. Without a stable new base and correction implementation now, the project won’t be able to scale. As a solution, we may set a lower price of ownership — fix less and spend less time on refinement or support. This will result in a new revenue stream.

The boundary against client dissatisfaction is again drawn in the SLA: we determine the response time to client requests in advance. This way, we guarantee to bear legal responsibility for not fulfilling our side of the contract. Naturally, even a perfect software transition plan can cause some release slowdowns because the period needed to teach a completely new team was not included in the initial development timing.

Overestimating the state of the project

Often, a software transition plan manager makes confident promises that a new team will pull it all off. We at Devlight do not guarantee anything we are unsure of. Responsible managers must ensure their promises with a buffer of time in case of unforeseen obstacles. A negative result of the audit may scare the client away as they were unprepared to see the real state of things. And it is our responsibility to have your back.

So, if you plan to start drawing a software transition plan, mentally prepare yourself for the fact that your app may be doing worse than you thought. The sooner you understand the real situation and decide to fix it, the easier it will be to start. 

Intellectual property

Intellectual property in the IT field is no different from intellectual property in other areas. It allows its owner to get the full benefit of a product that has gone from idea to market launch. Only the owner agrees to copy, modify, distribute, sell or modify the intellectual property during the application transition plan included. Thus, we will need a lot of permissions from the previous vendor before we can start full-scale work.

On the other hand, you shouldn’t worry that we will use the result of your programmers’ creative activity. If our team needs access to any object code protected as a literary work, we will contact the author and ask for permission to do so.

The previous vendor sabotages cooperation

For a software transition plan manager, relationships with another team can be a nightmare. We try to deal with things professionally and aspire to make the transition process as painless as possible for all parties. However, the vendor may sabotage an application transition plan in a different way: incompetence accusations, slowing down the cooperation process or holding back documentation. As a client, you should be ready for such pitfalls.

Using ready libraries or your own archives

Taking a ready-made lib seems like a great solution to speed up the application transition plan. Everything has already been written or invented before the new team arrived. However, projects are growing, getting covered with more and more logic, and sometimes it becomes more difficult to understand them. After several years of project development, any new developer can easily get used to the project, so a clear project architecture is needed. However, some libraries may reduce project maintainability to zero.

If the app was coded using ready solutions, it may be hard for a new vendor to handle it. One of the necessary IT project transition plan steps that is often overlooked is deciding on using own resources only or sticking to the previously made libraries. Choosing either option will lead to a completely new perspective.

The app’s general incapability

Even the best IT project transition plan template will not help if the app is impossible to assess or transfer properly. Outdated apps that have not been taken proper care of will require serious time and money investment. If we notice a great technical gap between the current state of things and what we strive for, we will need a lot of effort to cover this lack. However, we don’t usually refuse projects, so even the worst scenario is not the end of the world!

If you feel that your project needs a software transition plan, we can carry out a surface analysis before you decide to transfer your project to us!