6 Steps to Prepare a Software Project Transition Plan

Before making a software supplier transfer, it’s important to ask yourself the right questions about the reasons for changing your current software supplier. These may include high costs, quality problems, lack of scalability or specialist skills, frequent delays, unsatisfactory customer support, the need for new technologies, contractual disputes or a change in strategic direction. The key to a successful software vendor transfer is a thorough assessment of your motivations.

Once you’ve defined what you don’t like about your current situation, it’s time to draw up a list of your objectives, so that you can clearly define what you’re looking for in your ideal new partner. What are you looking to gain? Are you looking for a partner with better technical skills? Or perhaps you’re looking for a better quality of service from your future partner?

To ensure a successful collaboration with your new partner, it’s crucial to create a comprehensive list of objectives, enabling you to define your requirements precisely from the outset.

Before launching your project, draw up a data sheet summarizing the essential elements of your software. Find out about its environment and the people involved in the project. Don’t forget to check the intellectual property rights of the application and code.

Next, find out about any suppliers of software such as ERP (Enterprise Resource Planning) or accounting systems, and indicate the computer language, version, framework and database information used by your software.

Finally, carry out a code audit to assess the need for rewriting. Some parts of the software may be difficult to maintain or evolve. Security holes and obsolete updates may also require adjustments.

Record all this information in your software’s data sheet for an efficient project recovery.

It is imperative to know the level of access granted to the current software. For example, if you use SendGrid to send e-mails, you’ll need to have the appropriate access rights to these accounts in order to transfer them to your new partner. You also need to know what level of access you need for the software: is it only accessible internally, or does it only work on tablets or cell phones? Does the software reside on internal servers, or with an external host?

Gather all this information in available documentation, so that your future partner fully understands what has already been done, and what the expectations of the project are.

In most cases, your future supplier will introduce you to a business analyst who will help you gather all the information you need for the transfer. This analyst will be responsible for gathering all the necessary information upstream: how the software works, what its functionalities are and how they are used. The analyst will also list the information you need to add or remove from the existing software.

It’s at this stage that you should highlight the most frequent bugs and support requests you have with your current supplier, as these are potentially the first items your future supplier will have to deal with. Announcing these items at the start of the relationship will enable your new software supplier to understand where you’re going to need the most support, and to be able to help you with these aspects.

Following the above steps, draw up an action plan with one key aspect in mind: cost. Establish a budget based on planned maintenance costs, planned additions, and the time allocated to support and software updates. You’ll also need to estimate your budget, either at the start of the project or smoothed out over time. Then set up a migration plan between the old and new suppliers, with a schedule detailing the number of hours of work planned for each period. Clearly define roles and responsibilities between suppliers using the RACI project management tool. Each internal stakeholder will know precisely what is expected of them, and will be kept informed of project progress.

Last but not least, designate the person(s) responsible for validating when your project handover is fully completed, to avoid any possible confusion.

Don’t forget to document who will be impacted by this internal project takeover. You can create a register in which you will indicate who is impacted by the project, how and when. You also need to plan a time frame for when service will be suspended during your project handover, to ensure that internal people are aware of this, and to give them an alternative solution. In conclusion, to make your software transfer a success, clearly identify your motivations and future objectives. Provide a project data sheet and draw up an action plan involving all players with their roles and responsibilities, and schedule interviews with a business analyst, who will help you move forward

Don’t miss our episode on the key essential points to prepare for a supplier transfer for your software development with Johannie Robitaille, Director of Software Development Teams at Openmind Technologies (Audio is rolling in French only).