Breaking up with your software vendor isn’t a joyous moment. But sometimes it’s the best decision, especially if the reason behind it is low performance, huge project delays, poor project management, or any other unsatisfactory cause.
The transition to a new vendor can seem so complicated you wouldn’t know where to start. Here are the things you should expect and the essential elements you need to consider for a smooth and downtime-free project transition.
1 – Treat The Exit Process as A Project In Itself
Carefully planning your exit strategy from A to Z is crucial if you want to achieve a smooth as possible transition to a new IT vendor. Contrary to common belief, you need to prepare the exit plan before you contact your new service provider; this way, you pack up all the information and details you’d have to hand over to your new provider.
Although you may not need a traditional roadmap, the exit process is a project in itself. That means including timelines, budgets, resources and communicating with stakeholders like employees, customers, and other vendors you partner with so they’re informed about the change.
Pro tip: appoint an exit manager (any qualified senior manager) to liaise with the supplier, ensure that exit terms are followed, and will also negotiate the termination terms.
2 – Create A Knowledge Transfer Plan
One of the key parts of your exit process is creating the knowledge transfer plan. It’s a complex and multi-layered process that covers the organization as a whole but also teams or departments and individuals (handing over information from one expert to another).
The straight-forward approach would be:
- make a clear and comprehensive list of all the assets that need to be transferred;the list can include technical to internal documents, source code, design files, user documentation, project repository, deployment procedures, etc.
- determine and assign people who need to transfer and receive knowledge
For instance, at the company level, this designated person can be a representative from the legal or finance department. On the team level, you can appoint the CTO, a product manager, or a business analyst. On the individual level, product designers, software engineers, and DevOps professionals can have meetings where they share important details from one expert to another.
Pro tip: Make sure to store all the knowledge transfer assets and items into a dedicated and secure space. Choose a knowledge management platform that allows people to easily share their knowledge (e.g., look for options like automatic updates, duplicated content identifiers, etc.)
You shouldn’t expect knowledge transfer to happen without incentivizing and creating context for it. People are usually reluctant to showcase weakness by asking questions and are unwilling to read exhaustive documentation. Thus, you need to make it happen! Workshops and working sessions where an individual acts as a catalyst for the process, asking the right questions is key to a successful knowledge transfer.
Ștefan Murariu, Product Manager @ Softbinator Technologies
3 – Assess Your New Provider Against Your Compliance or Regulatory Needs
The specific business standards your company needs to diligently follow, like compliance or regulatory requirements are crucial for protecting your business and your relationship with stakeholders and customers.
For example, if your company stores credit card information, you need to ensure that you stay within Payment Card Industry (PCI) compliance with your new vendor. So, look for IT providers with experience or know-how in your industry’s regulatory and compliance standards; this increases the chances for them to align with your needs.
Pro tip: if the new provider doesn’t have the required knowledge or experience, they might partner with an outside vendor or contractor that offers the support that you need; but this is a crucial detail you should check and ensure it’s included in their service agreement.
4 – Perform an Effective Code Audit
Running a code audit with a thorough code review is a key measure when transitioning to another vendor. Make sure you perform high-quality, well-structured code and even divide it into logical parts. This step makes it easier for the new team to take over, helps with implementing new features faster, and effectively measures the technical debt.
Pro tip: consider hiring a 3rd party to perform the audit because your developers might be too subjective and neglect potential security risks. Moreso, you can create a document that mentions the scope of the audit and include a checklist to ensure no important areas are missed.
5 – Ensure That You Own The Code (after the transfer)
Once you find a new provider, get the confirmation that you’ll be the code owner once you finish building your app or project. If the company refuses to give you ownership for any reason, make sure that a clause about source code ownership is included in the contract.
Pro tip: sign a non-disclosure agreement (NDA) as an additional layer of protection; this way, your vendor is responsible for keeping all shared resources, including source code and intellectual property assets confidential.
Additional key things to keep in mind:
- Make sure you have the correct IP clauses in the employer-employee agreements so that the code is really in the hands of the company selling the code. You can fill in gaps after the work has been performed; a fast and effective due dilligence can be highly relevant here.
- File the source code, or the relevant part of it, with a copyright office, in the buyer’s name once the code is in his hands. The US Copyright Office or the French INPI are two examples.
- Make sure there is a proper SPA for source-code agreement, where duration, territory, and pricing are fully addressed. Often, SPAs (Service Provider Agreements) lack essential details, and this creates confusion later on.
A proper review of an SPA draft should be done by specialized IP practitioners, not tax or M&A advisors.
Paul Cosmovici, Managing Partner at Cosmovici Intellectual Property
6 – Remember to Keep Access to Your Current Environments & 3rd Party Services
Whether for IT infrastructure or end-user systems, if you’ve partnered up with a managed service provider, you’ll want to continue to have access and see the software history of these systems. Examples of such services include:
- cloud infrastructures, like AWS
- DNS services
- development services
- analytics tools
You should also ensure that you provide access to these services to your new technical partner.
Pro tip: choose a vendor with experience in maintaining applications on the hosting platform that you want to use; this will help you in deploying and maintaining your project successfully.
The new vendor will get up to speed faster if the previous vendor can do the transition to these services and if it helps with the handover. It’s best that you get access to all these services before letting your current vendor know that you decided to drop its services. Otherwise, they might refuse to cooperate.
Daniel Ilinca, Chief Executive Officer @ Softbinator Technologies
7 – Deactivate Old Accounts
Don’t forget to deactivate the accounts of the current vendor you’ve decided to quit so it no longer has access to your product. Ask your vendor to provide the entire list of accounts and access credentials to all the tools and services linked to your project’s assets; this allows you to double-check the number of accounts.
Most importantly, this step protects your intellectual property rights and keeps away unauthorized access to confidential data.
Pro tip: Although based on a typical NDA, the provider is legally responsible for destroying all assets and information related to your project after the termination of the contract, make sure that this detail is very clear with the vendor you’re leaving.
8 – Plan An Overlap Period
You can estimate a cutoff date – the day your company will finally make the transition from your current software vendor to a new one. However, plan an overlap period where you can monitor the new software’s performance and make adjustments if necessary until the complete data migration and integration takes place.
Staff from the previous and new vendor will work on knowledge transfer, while the full transition can usually last a month or two.
Pro tip: In case of unexpected downtime, choose a cutoff date in a less busy period so it doesn’t affect business operations, like the end of the fiscal year or December.
9 – Accept the Fact That the New Team Will Need Time to Adjust
Even with an effective knowledge transfer and successful onboarding, keep in mind that you’re dealing with a new software team who’ll need to go to a learning period before they reach the same pace as your previous team. That said, you shouldn’t expect a high output and performance in the beginning. In fact, you might even face some initial disruptions to your workflow as the new team progresses and fully understands the project nuances.
Pro tip: set clear expectations and project milestones, so the team can understand the big picture and the most essential project goals; this way, the team can focus and align with the product vision. Additionally, provide support, have recurrent check-ins with the team, see if everyone has everything they need, and ensure things are moving in the right direction.
Conclusion – Key Things to Remember
Hopefully, you now have a clearer idea of what you need to take into account before making the switch to a new software vendor.
Once you decide to switch, carefully explore your options, plan your timeline, and prepare your employees. Based on the reason you decided to call it quits with your previous vendor, make a thorough check to make sure you set the right expectations with your new provider. Before you reach a final decision on your new vendor, set a discovery period where you can get to know and better understand their technical skills and knowledge.
Apart from that, go deep into specifics, like licensing and renewal terms, if they provide support on your local time, or if they have the ability to scale with you as your company grows. These are just some of the key details you should acknowledge from the very start.
Introduction to Atomic Transactions - How A Simple Database Operation Can Highly Impact Your Business 
Questions Non-Tech Founders Have About Software Development