Thank you for your submission! We’ve sent a copy to your inbox Follow us on social media to stay up-to-date with Jaydevs!

4 Steps IT Project Transition Plan from One Vendor to Another

article_img

Sometimes a company might feel the need to change contractors at some point. Nobody likes being deceived or misled by empty promises especially when it is about doing business. As a software development company, Jaydevs realizes the scale of engineering solutions vendors’ responsibility and the cost of error when choosing a vendor.

While choosing an IT service provider, you as a customer would expect to get the best bang for your buck for developing your product. However, the implementation doesn’t always go smoothly and you might consider changing your IT vendor.

Many of our actual customers asked us for assistance in addressing the consequences of destructive cooperation with other software development vendors. Here, we’ll help you solve potential issues from switching vendors. In this article you will find a step-by-step guide for implementing an efficient software transition plan from one vendor to another, a list of required documents and at the end of the article, you can download the checklist of the IT project transition plan in PDF.

Step One: Current state analysis

Evaluate three factors before making a decision to switch vendors: vendor value, risks, and contract termination cost.

Assessment of the current vendor

List everything you don’t like about your current vendor. For instance, missed deadlines, poor feature implementation, overpricing during development, inexperienced developers, inconvenient and slow communication process, etc. Make sure you know the exact reason why you want to change your software development provider. This will help you better understand your demands from another supplier and the nuances you want to avoid. 

Risks associated with switching vendors

  • Challenges of drawing up an RFP and SOW. It might also include issues with knowledge transfer — the process when all documentation, data access, and project knowledge are transferred from the current to the new software development vendor. If your existing contract does not include a section about assistance in a smooth transition to a new vendor (termination assistance services) — you might face issues with knowledge transfer. 
  • Problems with contract termination. Depending on the contractual stage, the complexity of its termination will vary. Termination closer to the end of the contract period will prevent services quality drop, loss of data, etc. 
  • Intellectual property rights transfer and work with confidential information. Make sure that the intellectual property rights belong to you, and this is stipulated in the contract. As for confidential information, there is no way to check if all vendor employees deleted files related to your project. However, if you had a strong non-disclosure agreement, you could file a charge should the leak occur.

Cost of terminating the existing contract

Analyze the termination fees in the current contract. Typically, no termination fee is charged at the end of the contract or in case of a breach of contract terms by the vendor (so-called termination for cause). Conversely, the closer the termination date is to the start date of the contract, the higher the termination fee. You can try to negotiate a lower cost if the termination decision is mutual or if the facts speak in favor of the contract breach by the current vendor.

If you are still positive about changing the software development vendor following an evaluation of all three factors you can proceed to the next step — planning.


Step Two: Planning

Planning includes business strategy, development process handover timeline, contract termination strategy, and development schedule with a new vendor. 

Creation of a business strategy

The business strategy is the goals and outcomes you hope to achieve with the new vendor. For instance:

  • Find a large pool of developers with different skills in a specific region: Lithuania, for example.
  • Reduce the high costs associated with the current vendor.
  • Increase efficiency: double the number of implemented features per development iteration (sprint), reduce the number of code errors, etc.

Set the timeline for development stages handover

Determine the timeframe to transfer every software development stage from the current to the new vendor. If the current provider is not involved in the process, ask them to prepare a detailed knowledge transfer plan for the new vendor.

Define a contract termination strategy

Plan your strategy to mitigate possible issues with your current vendor considering the terms of the existing contract. For instance, if needed, prolong the contract with the current vendor for a transitional period; consider leveraging retention bonuses i.e. a bonus for continuing to work to avoid suppliers defection, etc.


Step Three: Plan implementation and choosing a new IT service provider

Use the RFP and SOW as a starting point to find your new IT service provider

The request for proposals should clearly state the scope of work required from the vendor — the more concise it is, the better the proposal you can expect from the vendor. Be sure to include these provisions in your RFP when changing vendors:

  • Summary — specify the goal of your request for proposal.
  • Stakeholder Relationship — specify the roles and responsibilities of the dedicated development team and the client.
  • Legal Terms and Conditions — include the main contract terms (the so-called term sheet) in advance: project description, the start date and the end dates of the contract, the country regulating the disputes within the contract scope, etc.
  • Approach for Transition — describe the timeframe for gradual transition of development functions from a current to a new vendor.
  • Scope of Work — describe the work scope.
  • Vendor Background Information — request general information about the outsourcing company, their experience in a specific tech stack, their client base, etc.
  • Expected Vendor Performance — clearly define the SLA that the vendor will have to meet (SLA – a service-level agreement stating what, when and how services will be provided).
  • Vendor Capabilities Form (to be filled out by the vendor) — lists everything you expect from the vendor and determines the level of proficiency per each task.
  • Termination — specify the conditions that may lead to the termination of cooperation: refusal to provide services, failure to meet performance standards, failure to meet deadlines, etc.
  • Price Bid — specify the type of contract you need based on the pricing model: fixed price, time and materials, dedicated. 

Conduct a comparative analysis of proposals from potential vendors

Determine the most important criteria to make the final decision on whom to work with. These criteria can include the supplier’s location, software developers hourly rates, the level of developers, any extra additional costs, etc. Having chosen a service provider and finished negotiations with them, take care of the SOW for the contract. The SOW should contain the following sections:

  • Executive Summary — the goal of the agreement.
  • Term and Termination — the duration of the contract and termination rights.
  • Vendor Scope of work — a description of the services that will be provided.
  • Vendor Statement of Work — a more granular work description (processes and requirements) than provided in the RFP.
  • Documentation — documents and reports the vendor is responsible for, including schedules for delivery and development stages accomplishment.
  • SLA / Vendor Performance — prioritize SLAs based on their importance to project development and define the penalties to be charged for non-delivery.
  • Transition Plan — states the roles and responsibilities of both parties during the project transition period. Specify how everything related to the development stages will be transferred to the new vendor.
  • Operational calendar — working hours, public holidays, etc.
  • Pricing — specify your pricing model, developer rates, and how funds will be sent.
  • Fee adjustments — specify how payments are corrected in case of:
    exchange rate fluctuations;
    payment adjustments considering changes in the scope of development.
  • Exit Management Plan — develop a plan that outlines the steps to be taken if you or the IT vendor terminate the contract. These steps should include how to transfer the service to a new IT provider, knowledge transfer, roles and responsibilities during the transition phase, and the time when services facilitating such transfer are provided.

Step Four: Completing the transition to a new IT vendor

After signing the SOW, discuss the knowledge transfer plan with the new dedicated development team.

Knowledge transfer plan checklist:

  • Project specifications, code documentation, and a road map — gather project specifications, code documentation (including source code, description of application architecture, description of key algorithms, description of application layers, database structure description, frameworks and libraries used), deployment flow recommendations, and environment setup.
  • Development credentials — in order to get the project your new development team needs access to the project’s repository, issue tracking system, etc. Request access to all accounts used for your project from the previous vendor. Then update access to all accounts and tools connected to your project and remove the accounts of previous providers. If you’re not sure what tools and credentials a new software development vendor needs, ask them to provide a list of the required information.
  • Assets transfer — ask your current development team to transfer all the project-related documents and files to you: design files (Figma files as a rule) etc, depending on your project.
Checklist
Use our Software Development Project Transition Checklist to make the transition process of your project seamless and successful.
Download
<strong>Checklist</strong>
Download

In practice, you are unlikely to have all of the above artifacts, but specifications, source code, API, and project deployment instructions should be the bare minimum you need to provide to a new dedicated development team.

Having this data, the new team will be able to continue working on the project without having to develop everything from scratch.


Summing up

Changing vendors within your product development is always unique and has specific challenges arising from the existing contract. However, by following the recommendations in our article, you will be able to get the expected product, minimize the risks and minimize the negative impact when switching software development vendors.

Tags:

Frequently Asked questions
What are an RFP and SOW?
RFP (Request for proposal) is a document that is created by the client to receive proposals from potential IT services providers. SOW (Statement of work) is a part of the contract between the client and the vendor, containing all the details and expectations of cooperation.
Where can I find IT service providers I can trust?
It is worth checking platforms that have already proven themselves to be trustworthy. Clutch, Goodfirms, and Designrush are good examples. You will not only find the right company there but also read customer reviews before making your choice. Consider contacting us directly instead of spending time searching and analyzing.
Is the project handover process to a new vendor team time-consuming?
There are many factors affecting it. Starting from the accuracy of source code documentation and ending with the quality of that code. A matter of ownership is also something to consider — Whether you have full ownership of the software, system, or application that the vendor creates? Will the new development team be able to access everything the previous supplier had access to? If not, the transition process might become really challenging. The worst-case scenario is that a new development team might have to start from scratch.
How can I get my current supplier to collaborate with a new supplier?
Sometimes a supplier, frustrated about being dismissed, may not be willing to assist with knowledge transfer to a new supplier. Therefore, you might need to consider negotiating with your current IT vendor. For instance, you can suggest an amicable separation, offering them to provide a recommendation, or at least agree not to post bad reviews afterward. You can also discuss compensation to the existing provider in case of a successful transition.