Most companies rely on technology partners and software development companies to keep the custom software they’ve created to drive their business running smoothly.
When a business needs to scale or update these custom software applications, or wants to evolve and add new features, gaps can develop between companies and their vendors. When it’s time to change software development vendors it can be difficult for companies to know what to do next – or where to turn.
Common Reasons for Changing Software Vendors
It’s not easy coming to the conclusion that it’s time to move on from your current software development partner. From our experience, there are usually a few common reasons that move the needle in favour of a vendor change.
Technical:
- New features or enhancements are wanted.
- Legacy solutions or software require updates.
- Lack of confidence the vendor can deliver needed changes or upgrades.
- Outgrown current vendor’s technical skills.
- Looking for second opinion on proposed strategy and budget.
Social:
- Lack of responsiveness or communication.
- A falling out with current vendor.
- Retirement or business closure.
- Extended timelines for getting work completed.
In these situations, it often becomes clear that taking your application to a different software developer is the best way to get your business back on track.
Out of the SMEs surveyed in Canada, 96% currently plan to upgrade or modify their software. Over half of SMEs surveyed (56%) will upgrade their software to gain more functionality. Capterra
How Changing Software Vendors Works
The first step in any move requires information gathering. Any new vendor will need to understand the current environment, the state of the codebase and the IT ecosystem. Next is getting a clear picture of what the business needs from the software today and into the future, so a development plan can be made accordingly.
It’s important to note that moving vendors doesn’t always mean you have to start from scratch and build a new solution. The codebase and software elements can sometimes be reused if:
- It’s built using modern languages and technologies.
- Codebase is clean and well documented.
- The solution is architected well and can scale.
The topic of rebuild or replace can be complex and is covered extensively in our application modernization guide. Generally speaking, we’ll always do our best to reuse what a client already has. But it may not always be possible, and we don’t know what we don’t know until we dive in, so it’s wise to be prepared for surprises.
Potential Pitfalls
You never really know exactly what’s going on under the hood until you get deeper and deeper into the system – and when we are evaluating a solution for a client looking to switch vendors, it’s impossible to review every line of code. On the surface things look good and are able to support the changes required, but as we get deeper into the system, problems can start to come to light.
We’ve learned one cardinal truth – the deeper you have to dig into the code to make changes, the greater the risks of uncovering problems. Simple requests to extract specific data or visualizing an element might seem like a simple ask but can sometimes become very complex depending on how the solution is built and where that information is being extracted from.
We’ve also encountered situations where we were working hard to reuse as much of the legacy codebase as we could, but as we dug deeper into the solution, we realized replacing the entire solution would be the better option (financially and/or technically) over the long term.
In this environment – expect the unexpected.
Is a move worth the time, effort and budget? The answer isn’t cut and dried.
We’ve met with potential clients and suggested the best developer to do what they needed is their existing vendor. In other situations, a move makes sense – to get the support, technical expertise and a solution that’s architected for future growth.
Preparing for the Move: Steps to Protect Your IP
Regardless of why a customer needs to change vendors, there are some important steps to take to help ease the transition – and protect your technology ecosystem including codebase, libraries, frameworks, databases and documentation.
Some of this can and should be done on a regular basis – even if you have no intention of moving to a new vendor. Having control over your assets is one of the best ways to make sure you can keep the lights on in almost any situation.
- Put it in the Contract: Make sure your contracts spell out who owns the IP for your custom software. In most cases, that owner should be you.
- Get Regular Back Ups: At each major update, key milestones or upgrades, ensure you have access to a copy of the codebase, documentation and database. Having access to the source code repository is a must before any move.
- Secure Your Licenses: Know what licenses you have, where they reside and in whose name. Vendors can often secure preferential pricing, but if you’re planning a move, you will need to ensure you have access to the licenses (or can buy new ones).
- Understand Hosting Arrangements: Consider where your app is hosted and move it if need be.
Keys to Transition Success
Handoff
When you have taken the above steps to protect your IT ecosystem, transitions can become more seamless.
Ideally, the previous vendor is available for transition and handoff meetings. When we are dealing with very complex solutions, those handoff meetings and having access to the original developer can save time and headaches – and can sometimes make the difference between the decision as to whether or how much of the existing solution we can reuse.
When previous vendors aren’t available, or the move is less friendly, it is even more important to safeguard your code, licenses and ecosystem before making any move.
Budget
Be prepared to make an investment to get exactly what you want. Band aid solutions might be less expensive in the short term but can add up to bigger costs and issues down the road.
That doesn’t mean you have to break the budget up front. You can start out by prioritizing your investments on foundational work first, like updating the architecture.
And, be prepared to expect the unexpected. You can take every possible step to make the transition seamless, but things come up and get uncovered – which is why the next point is so important.
Communicate
In a situation where a customer feels they have been burned, it can be difficult to move forward in a new relationship with a new vendor. It can be hard to put your trust in the hands of someone new. What does it take to succeed? Communication.
This might seem overly simplistic, but the foundation of every relationship is communication. Clear and honest communication. Asking questions. And, of course, listening to each other and trying to understand each other’s point of view. You can’t bring a legacy of distrust into a new relationship, or you won’t get the outcome you are hoping for.
If you think you need to move solutions to a new vendor, make sure you protect your assets. Need someone you can trust to help you? We’ve got a lot of experience helping businesses protect and move their IP. Let’s chat.
