Taking over software from another vendor: what to check first

Most businesses don’t change software vendors in a quiet week. Something has already gone wrong. Releases have stopped, questions go unanswered, or nobody can say what is safe to change. The instinct is to find a new team and start fixing things straight away.

The safer first step is to find out what you actually control.

Who owns the code, accounts and data?

Start with the pieces that decide whether anyone can work on the system at all:

• The code repository, and whether it sits in an account your company controls.
• The hosting or cloud account, the domain and its DNS settings, and important third-party services such as payments, email and SMS.
• The database, and where the backups are kept.
• The credentials, and who currently holds them.

If any of these sit only with the outgoing vendor, resolving that comes before any other work. Our default setup keeps repositories, cloud accounts, domains and data under the client company’s control, and our trust page explains how we handle ownership and handover. The article on who should own the code, hosting and accounts goes through each item in more detail.

What access exists today?

Partial access is common. You may have the admin panel but not the server, or the code but not the deployment. That is workable, as long as everyone is honest about it.

We start by recording what is available and, just as importantly, what it prevents anyone from confirming. A missing deployment pipeline or database access changes what a new team can safely promise. It is far better to know that before work is priced than to discover it halfway through.

How does the system actually get released?

Ask how changes reach your staff or customers today. Is there a test copy of the system (a staging environment) where changes are checked first? Can a release be undone? Who approves it?

If nobody knows, treat every change as risky until the release path is understood. The first useful piece of work may be making releases safe and repeatable, before any feature is touched.

What does the business depend on?

The technical picture is only half of it. Talk to the people who use the system every day about the workflows, business rules and reports they rely on. These are the things that must keep working through a handover, and they are rarely written down anywhere.

Do you need to rebuild?

When a system has been painful for a while, a rebuild can feel like the clean answer. Sometimes it is. More often, the problems sit in a few specific places: an unreliable integration, a slow report, a release process nobody trusts.

A rebuild is a large decision, and it deserves evidence. We would rather investigate the actual problem first, recommend what to fix first, and let the case for a rebuild prove itself. If it does, it becomes a properly scoped Custom Project with its own plan, not a reaction to frustration.

If the current vendor won’t cooperate

It happens. We identify what can be verified without them and prepare a specific list of the access and handover items still missing. The commercial or legal follow-up with the vendor stays with your company, but a precise list makes that conversation much shorter.

Where to start

If the system itself is unclear, start with a review rather than a delivery commitment. A System Review investigates one system or workflow problem, records what can and cannot be verified, and recommends what to fix first. If you have a single decision to make, such as whether to keep the current system at all, a Decision Review gives you an independent view on that one question.