When and why should you consider changing technology partners?
Changing software house is a strategic decision that can significantly affect the development of your product and the health of the company, but also the state of the product and user satisfaction. So it’s worthwhile for this decision to be thoughtful, informed and well-planned. Changing a technology partner is a challenge for all three parties to such an endeavor, so it certainly should not be hasty or taken for trivial reasons.
Changing a software house is worth considering when there are serious communication problems, delays in completing tasks, a decline in the quality of solutions delivered, or a loss of trust in the technology partner – especially if the project is constantly going over budget and the work performed is not delivering the promised business results. Lack of transparency, ignoring customer needs, inadequate technical support, or use of outdated technologies are also warning signals, which in the long run can expose the company to additional costs and loss of market advantage.
The decision to change is worth making when the new partner is able to guarantee better code quality, effective communication, a professional approach to running the project and real support in business development. A properly executed change allows to improve the efficiency, security and stability of the application, minimizing business risks in the future.
Recognition of red flags
Recognizing red flags in the existing cooperation with a software house requires vigilant observation of several key areas. These include regular delays in task completion, frequent changes in the team responsible for the project, or recurring errors in the delivered software. Such symptoms are often the result of inadequate project management, lack of clearly defined requirements or a mismatch between the competence of the team and the specifics of the product being implemented.
Lack of transparency in progress reporting, reluctance to make legitimate changes, constant budget overruns and protracted implementations of new features can also be symptoms. If this is compounded by the phenomenon of declining quality of technical support and an apparent lack of attention to security and application updates, it indicates serious organizational problems and may mean a change of supplier.
Lack of communication is a particular wake-up call, as virtually anything can be hidden under its “cloak.” A good software house – even when it has problems, which are a natural part of developing and testing new software – will communicate fairly up-to-date on their status, problems and preventive or corrective measures taken. If a technology partner has problems, but communicates, it may be that the project is problematic in its own right – for example, for reasons of innovation or under-supply by outside vendors. In that case, changing the software house may not improve the project’s situation.
Finding a new partner
A new partner should have, first of all, what you believe your current partner lacks. But it is also necessary that he or she is proficient in the same technologies you currently use. It is very valuable to search and analyze the software house’s portfolio with verifiable ratings – for example, Sailing Byte has reviews verified by the Clutch service.
If you want to know more, I recommend the entire article on how to find the right technology partner for your business.
Business risk planning in change
This aspect is not worth overlooking, as it ensures business continuity and minimizes potential business downtime, as well as customer and employee frustration. Creating such a plan allows you to react quickly in crisis situations, such as delays, technical problems or loss of key resources. The plan should identify possible risks, analyze them qualitatively and quantitatively, and prepare a strategy for avoiding, reducing, transferring or accepting them, thus increasing resilience to unforeseen situations during a change. Such a plan will be quite different for each case, but, for example, may include such elements as:
- Regular data backups and testing, with disaster recovery instructions.
- Assign roles and responsibilities to the team during a crisis and establish multi-channel emergency communications (phone, email, apps).
- Develop contingency scenarios covering different types of risks, such as system failures, cyber attacks, migration delays or supplier problems.
- Ensure redundancy of critical systems and infrastructure to avoid a single point of failure.
- Map the IT supply chain and securing alternative suppliers or locations for key services and resources.
- Establish Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets that define acceptable downtime and data loss.
- Conduct regular tests and updates to the plan, including simulated emergencies, to maintain effectiveness and adapt to the changing environment.
- Document and monitor risks with a plan to minimize, reduce or accept them depending on their impact on the business.
For your case, it can be both too much or too little – it all depends on the size and criticality of the system – so try to tailor such a plan to your specific case.
Audit: documentation, code and environment
If at this stage you are still leaning towards change, the next element will be an audit – getting a little deeper into the technicalities of the project. Preparing an IT project audit starts with gathering complete and up-to-date documentation – this includes requirements specification (both functional and non-functional), system architecture documentation, implementation manuals, test plans, user descriptions and a list of technologies used. Careful documentation allows you to understand the project assumptions, the business goal and facilitates the assessment of whether the realized functionalities comply with the initial requirements and security standards. It is good practice to store all materials in a repository, where they are accessible to auditors and the project team.
The next step after the audit is to analyze the source code and deployment environments. If the relationship with the software house is healthy, you should easily get access to the version control system, code documentation, information on database structure, access keys and environment configurations (dev, test, prod). This makes it possible to quickly identify technology debts, potential risks and assess the readiness of the project for further development or transfer to another entity.
The big problem at this stage is the selection of the auditor. For obvious reasons, it cannot come from the current software house. Nor can it be an inexperienced person or a freelancer. It should be a developer or a team that is not only experienced, but also knows the entire technology stack of the project, and is in no way related to the current technology partner. Alternatively, of course, you can do the audit yourself, but you need to understand all the technicalities to make it reliable and consistent.
Preparing to change partners
New partner, updated requirements
When defining the requirements for a new software house, we can use all the above-mentioned obtained information, but it should be supplemented with the quality factors that determined the failure of the project delivery. That is, for example, if quality was an issue, it is worth defining what quality should be expected – by setting appropriate KPIs – before changing partners. Requirements should also include expectations for collaboration, communication, and progress reporting, allowing you to clearly establish the scope of work and how it will be delivered. It is also important to clarify expectations for post-implementation support and change management, which will help the project run smoothly and efficiently.
Painless knowledge transfer
Knowledge transfer is one of the most important stages of a supplier change, so it is essential to comprehensively transfer project documentation, source code, data and configuration environments. Only the transfer of a complete set of information ensures the maximum easy process of assessing the status of the project and the possibility of its acquisition. The new software house should learn not only the technical aspects, but also the business expectations of the project. Such actions promote rapid adaptation and minimize the risk of losing information, ensuring the smooth continuation of project development without delays or disruptions. If you are concerned about the reaction of the current software house or it causes a business risk, try to provide this information without the knowledge of the current supplier. This should not be a problem at all if you own the copyright to the code.
Make sure about the status of the author’s property rights
Making sure of the author’s property rights is crucial when ending cooperation with a software house, to ensure that the company has full control over the software created and the possibility of its further development. Care should be taken to ensure that the contract unambiguously transfers to the ordering party the economic copyright to the source code, documentation and other results of the work, which guarantees the legal use, modification and distribution of the product. The absence of such provisions can lead to the risk of dependence on the supplier and limit the ability to develop the software without his consent. If cooperation with the current software house is not going well, this can be one of the more problematic points, so it is worth preparing for it.
Determine the details of the new cooperation
If the details of the cooperation have been tentatively agreed with the new software house, the next step will be to establish a schedule for the change. This should include a phased migration plan taking into account minimizing downtime and risk of business interruption. In practice, this means, among other things, implementing migrations during periods of lower load, performing test migrations on backup environments, and preparing contingency scenarios in case of problems. It is also crucial to accurately assign roles and resources, both on the client side and the new software house, and to constantly monitor progress and respond quickly to any difficulties.
Remember the pitfalls, proceed with caution
However, the above paragraphs describe the simplest case where the incumbent supplier is understanding and cooperative. On the other hand, unfortunately, from a business point of view, you need to take into account the risk of creating actual or imagined problems by the existing supplier. If you suspect that the current supplier may “cause problems,” you should make solid preparations and work closely with the new supplier. Since we have already processed such situations in our team, I recommend contacting Sailing Byte directly using the form at the bottom of the page – every case is different, and we are happy to help in such situations.
Test piloting of the new team on a small module (optional)
This is a step that is only possible if, from a business point of view, you are able to assess that temporary three-way cooperation is at all possible. In a pilot, the new team performs a specific, small task or product module, which allows them to learn about working methods, tools, communication and how to solve problems. Such a pilot allows you to identify potential challenges and adjust processes before a decision is made to fully take over the project.
During the test pilot, it is important to monitor the quality of the delivered code, the timeliness of implementation, and the team’s commitment to communication and quick response to feedback. This helps verify that the new partner meets expectations and is able to cooperate effectively. In addition, the pilot can be used for knowledge transfer and team integration, which facilitates full implementation and further development of the project. This allows a gradual transfer of responsibility, learning the specifics of the code, tools and architecture, as well as discussing expectations and quality standards.
Optimization of the project handover process (optional)
This step, too, is only possible if three-way cooperation is possible and the code and processes have any recognizable standards in place. Optimizing the transfer of knowledge and code between software houses requires establishing clear code standards and continuous integration (CI/CD). Knowledge and documentation management tools, such as code repositories (e.g., Git), project management systems and knowledge bases, enable centralization of information and quick access for the new team. Code standards, defined at the level of conventions, quality and testing, help maintain consistency and facilitate project maintenance, and automated CI/CD pipelines ensure a smooth deployment process, with rapid error detection and minimization of risks during integration. For example: a new software house can prepare new production and test infrastructure, and the current team can add new servers for deployment in the pipeline – this way the new team can test the infrastructure without disrupting the current work and deployment.
Signing an agreement for amicable termination of cooperation
This step may sometimes be required, for example, when the current supplier claims copyright to the code or documentation produced. Most often, by the time the idea of signing an amicable agreement comes up, all parties involved already know about each other and the process of code acquisition by the new company is not a secret. It may be necessary to consult not only with a lawyer, but also with the new software house – if only as to the extent of use of the old code. At Sailing Byte, for example, we have experienced such cases where there was no need to transfer copyright to the code, because the code was in an unusable state – which was used as an argument by lawyers when discussing compensation. So it is worth bearing in mind that this is a stage involving many parties.
Starting a new partnership
At this stage it should already be very simple, or even have already happened during the previous stages. Nevertheless, at the end it is still worth making sure of a few elements, for example:
- Are the communication channels established between the parties and working properly?
- Are the upcoming tasks clear to the team and does the team know how to prove them?
- Does the scrum master or project manager have no questions and know what next steps to take?
- Is the system in production working?
- Does everyone know when the next retrospective or sprint planning meeting is?
It will only take a moment to check such basics and it will certainly give all parties more confidence about the next steps.
Summary: How did the software house change go?
After some time, it is worth doing an evaluation of how the new cooperation looks like. If you have taken into account everything I described above, it should be better than it was. If not – a good scrum master should have already caught this to discuss at the retrospective.
The decision to change a technology partner is a strategic step that should be taken consciously and based on specific considerations. A properly executed change process allows you not only to minimize business risks, but also to gain a partner that is better suited to the needs of the project and will provide stability, efficiency and support for the next stage of product development. If you are interested in changing your current technology partner to Sailing Byte or want to discuss what such a change could look like – use the form below and get back to us. This could be the beginning of a beautiful new partnership!
