6 Steps to Prepare for the Transfer of a Software Development Provider

Before changing your software development provider, it’s important to ask yourself the right questions about your reasons for switching in the first place. 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 high quality and successful software partner transition 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 agile methodology 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 software provider 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.

Make sure you know exactly what access you have to your current software, this is crucial for a smooth transition. 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, the key here is effective communication.

By thoroughly assessing your software now, you’ll save time and avoid costly surprises down the road.

In most cases, your future provider 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 provider, as these are potentially the first items your future provider will have to deal with. Announcing these items at the start of the relationship will enable your new software provider 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 provider, with a schedule detailing the number of hours of work planned for each period. Clearly define roles and responsibilities between providers 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 with your project timeline.

If you’re preparing for a software project transition, it’s crucial to also consider the broader context of working with a trusted partner. Check out our article on Working with a Software Modernization Partner: Best Practices & Key Questions to learn how to choose the right partner for your software modernization needs, ensuring your transition is part of a successful long-term strategy.

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

• Comprehensive Planning: A detailed transition plan is crucial for a smooth handover. Identify all necessary tasks, stakeholders, and resources early on.
• Clear Communication: Maintain transparent communication among all parties involved to ensure that everyone understands their roles and responsibilities.
• Risk Management: Proactively identify potential risks and develop mitigation strategies to avoid disruptions during the transition process.
• Documentation: Ensure thorough documentation of all project aspects, including procedures, technical details, and contact information, to facilitate a seamless transition.
• Testing and Validation: Before fully transitioning, conduct rigorous testing and validation to confirm that all systems and processes function as expected.
• Post-Transition Support: Plan for ongoing support and monitoring post-transition to address any issues that arise and ensure long-term success.