Switching software vendors: what to know before an application handover
Your application may still serve customers well even when the relationship with its vendor no longer works. Changes take too long, capacity is limited, or your business needs capabilities the original team cannot provide. The question is not simply who will write the next feature. It is what the incoming team must understand and control to maintain the existing system.
When switching vendors makes sense
Poor software is not the only reason to change partners. A vendor may close, change its focus or lack capacity. In other cases, recurring outages and unresolved requests make the relationship difficult to sustain.
Before looking for a replacement, define the outcome: more reliable operations, faster development, clearer costs, or less dependence on one person. Without that distinction, the same problems can follow you into a new contract.
Also distinguish between staffing and service ownership. If you have technical leadership but need more people, additional development capacity may be enough. If you need a partner to organise maintenance, coordinate changes and handle incidents, agree a broader scope of responsibility.
What to include in the application handover
Source code is essential, but it is not the entire handover. Access to an administration panel does not provide control over development or infrastructure. Build an inventory with the outgoing vendor, assign an owner to each item, and agree how the incoming team will verify it.
| Area | What to provide | Evidence that the handover is usable |
|---|---|---|
| Source code | Repository, change history and identification of the deployed version | The team can identify the code behind the live application and build a runnable version. |
| Operations and deployment | Servers, cloud services, configuration, deployment instructions and scheduled jobs | The application runs in a separate environment using the supplied instructions. |
| Data and files | Database structure, backups, attachments, required keys and recovery instructions | A test restore produces a usable copy within the agreed scope. |
| Integrations | Accounting, payments, email and other connections, with technical contacts | The team knows what moves between systems, when it runs, which account it uses and how failures are detected. |
| Accounts and licences | Domain administration, service billing, licences, permissions and renewals | The business knows what it controls, what is transferable and what needs a new account or agreement. |
| Documentation and work in progress | Functional descriptions, known defects, open tasks and critical business workflows | The team understands routine operations, exceptions and who sets priorities. |
For custom software, also check the contractual permissions needed to modify the application and involve another vendor. Having a copy of the code does not resolve every licensing question. Unclear rights need legal review, not a technical assumption.
If the application shares the outgoing vendor's infrastructure with other customers, transferring the entire account may not be possible. Identify the resources belonging to your project and establish how to separate them without affecting unrelated systems.
What the technical audit should establish
A pre-handover audit should answer a practical question: can the new team operate and change this application, and under what conditions? A technology list or a general verdict that the code is old is not enough.
Can the application run from the supplied materials?
Verify that the team can build and run it outside production—the live environment used by real customers or employees. This can expose missing components, server-only configuration or dependence on an outgoing developer's computer.
Keep testing separate from real payments and customer emails. Use test data or appropriately anonymised data; a project handover should not automatically grant access to production information.
Review technology support status, third-party libraries and known vulnerabilities. Automated checks are useful, but findings still need assessment in context. The report should identify anything that could not be checked; an initial technical audit is not a full penetration test.
Do critical workflows work, not just the login screen?
Select representative scenarios with people who use the system: completing an order, issuing an invoice, approving a request or transferring data to accounting. Where automated tests are missing, begin with documented manual checks and add automation progressively.
A page loading successfully is not the same as the business being able to operate. An overnight stock synchronisation, for example, may never appear in a normal product demonstration.
What should the audit deliver?
Ask for findings with business impact, priority and a proposed next step. Separate handover blockers from essential stabilisation work and improvements that can wait. Estimates should state their assumptions and unresolved questions. This gives management a basis for allocating budget by risk, rather than by the volume of technical detail in the report.
How to plan the transition and protect operations
1. Define responsibility during the transition
Where possible, arrange a joint handover with the outgoing team. Record who responds to incidents, approves interventions and deploys changes. Both teams can contribute, but they should not make uncoordinated production changes.
Set an explicit point at which operational responsibility transfers. Signing a contract, receiving credentials and being ready to handle an incident do not necessarily happen on the same day.
2. Verify backups and the recovery process
Before a risky change, do not rely solely on a message that backups are running. Test recovery and verify the required data, files, configuration and decryption keys. Regular tests of partial and full restores are also recommended in CISA's guidance for small businesses.
Agree how much disruption the business can tolerate and how much recent data could acceptably be lost during recovery. These requirements should shape the recovery process and technical setup.
3. Transfer access in a controlled way
Give the incoming team only the permissions it needs and use a secure channel for sensitive credentials. When authorised involvement ends, remove outgoing access and replace shared credentials that must no longer remain usable. Least privilege and revocation of unneeded secrets are covered in OWASP's secrets management guidance.
Coordinate these changes with dependent services. Removing an account used by an automated import can stop a business process. The goal is to end unnecessary access while preserving legitimate application behaviour.
4. Start with a limited, verifiable change
The first release might be a small fix with a clear expected result. It tests the complete workflow: requirements, implementation, testing, deployment and observation. Smaller, self-contained changes are easier to roll back when problems occur, a principle described in the Google Site Reliability Engineering Workbook.
Rolling back code does not necessarily reverse changed data. Database changes need a separate recovery or remediation plan that protects newly created records. A vendor transition does not have to include a hosting migration, database replacement and major rewrite at the same time.
Maintain, modernise or rewrite?
An application's age does not determine the answer. If it supports important workflows and remains maintainable, continuing with application support and maintenance while addressing specific weaknesses can be a sensible option.
Refactoring improves the internal structure of code while preserving its behaviour. Incremental modernisation may replace a particular module or interface. Consider a full rewrite when the existing foundation cannot support necessary changes at acceptable cost and risk. Even then, account for data migration, integrations and less visible features that users still depend on.
Illustrative example: A business needs a new customer portal, but its order-management system works well. One option is to keep the existing core and connect the portal through an application programming interface, or API. Analysis should establish whether that separation is technically and commercially sound. Further custom software development does not automatically mean replacing the entire system.
What affects the cost and timeline?
Application size is only one factor. Others include documentation quality, integration complexity, cooperation from the outgoing team, the ability to recreate the environment and the required level of business continuity.
A proposal should separate discovery and handover, essential stabilisation, ongoing maintenance and new development. A single combined price makes it harder to distinguish prerequisites from optional improvements.
Treat a precise deadline offered before anyone has examined the application as an assumption to validate. A more useful proposal explains the scope and deliverable of initial discovery and identifies when the remaining schedule and budget will be refined. Contingency should reflect specific unresolved risks.
What if the outgoing vendor will not cooperate?
Start with an inventory of assets the business can legitimately access. Locate contracts, repositories, backups, service accounts and people who understand operations. Account recovery should use the provider's normal ownership-verification process; technical work should not bypass someone else's access controls.
Some documentation can be reconstructed from code and observed behaviour, but this adds effort and uncertainty. Without source code, it may be possible to keep an environment running without being able to continue full development. Establish those limits before accepting a promise that everything can be taken over.
Application handover checklist: when is it complete?
Do not assess completion only by the number of files received. Before closing the handover, confirm that:
- The incoming team has verified the necessary access and can run the appropriate application version.
- Critical workflows have been checked and a test restore has covered the agreed scope.
- Important integrations, scheduled jobs, licences and payments have named administrators.
- Known defects, unverified areas and accepted risks have been recorded with accountable owners.
- Deployment, monitoring and incident responsibilities are assigned from a specific date.
- The service-level agreement, or SLA, distinguishes response, service restoration and root-cause resolution, and specifies support hours and escalation.
- The business retains ongoing access to agreed project materials and a process for any future handover.
The first step need not be terminating your existing contract. It can be a verified inventory of what is available, what is missing and who will provide it. That is a practical foundation for deciding whether, when and how to switch vendors.
Planning to move a business application to a new partner? Tell us what the system does and what needs to change. We can discuss takeover options and the support or development work that follows.
