After an acquisition or a change of team

Inherited software, after an acquisition or a change of team.

When you buy a business, you buy its software too, often including systems nobody on your side has seen. This page covers the questions to ask before you buy, what to do in the first 90 days, and how to bring several systems under one sensible approach.

Most deal teams look hard at the finances and the contracts, and less hard at the software. Yet the business may run on a customer portal, a booking system or an integration with the finance system that one person built years ago. If that person is leaving as part of the deal, or has already left, you have inherited a risk along with the revenue.

None of this needs to slow the deal. A few well-chosen questions before you buy, and a calm first 90 days after, go a long way.

Before you buy: questions to ask about the software

This is technical due diligence in plain English. Put these to the seller, and note how readily they are answered. Slow or vague answers are information too.

  • What does the software do for the business? Which processes would stop if it failed, and how quickly would people notice?
  • Who built it, and who looks after it now? Is that person employed, a contractor or an agency, and are they staying?
  • Who owns the code? Is there a written agreement assigning the rights to the company being sold? Ownership depends on the contract, so ask to see it.
  • Where does the code live? Is it in a source control account the company owns, or on someone's laptop?
  • Where does it run? Whose hosting account is it, who can sign in, and what does it cost each month?
  • Is it still in support? Which framework, operating system and database versions does it use, and when do they go out of support? See our page on end of support.
  • What does it depend on? Third-party services, paid components and licences, and whether they transfer with the business.
  • Is it tested and documented? Are there automated tests, a documented release process and written notes on how it works?
  • What happens if it goes wrong? Backups, whether a restore has been tried, and what the last serious fault was.
  • What personal data does it hold? Where, and who can access it, so that you can meet your UK GDPR responsibilities from the day of completion.

Our article on questions to ask about your bespoke software goes through these in more depth. If an answer worries you, you can reflect it in the price, a warranty or a condition to be met before completion. Take advice from your legal team on how to do that.

After completion: the first 90 days

Treat the first three months as a plan with three stages.

  1. Days 1 to 30: secure. Make sure the company owns the code, hosting, domain names and accounts. Replace shared passwords. Take a copy of the code and confirm that backups exist. Get written knowledge from the people who know the system while they are still available. Our first week guide lists the essentials.
  2. Days 31 to 60: understand. Find out what each system does, who uses it, what it connects to and what state it is in. A software health audit gives you this in a week for one system.
  3. Days 61 to 90: decide. With the facts in hand, agree what to do with each system, and who is accountable for it going forward.

Avoid big changes in the first month. The system worked well enough to be part of what you bought, so the aim at first is to protect it, not to improve it.

Consolidating systems

Acquisitions often leave you with two of everything: two customer systems, two ways of taking orders, two sets of reports. Merging them is attractive, and it is also where projects go wrong.

For each system, decide whether to keep it, merge it into another, or retire it. Useful questions are how many people depend on it, how well it is understood, how long it will remain in support, and how much it would cost to replace compared with looking after it. Make sure each system is safe before you start moving data between them, and only retire one when its replacement has been proved with real use. Where an application sits on ageing servers, moving it to Azure can be part of the plan.

How the health audit helps

A software health audit is a fixed-price, one-week review of one system. You get a plain-English report with the risks ranked, what is out of support or exposed, and what it would take to look after the system, with a fixed quote. It works before completion, if you can arrange access, and after it. There is no obligation to continue, and the report is yours to act on with us, with another supplier or on your own.

If you go on, our software care service takes the system over: code into your own source control, automated tests, a repeatable build and release, monitoring and documentation, then monthly care. A named senior engineer is accountable for each system, with a named backup who also knows it.

Next step

Pick the system that matters most to the business you have bought, or are about to buy, and start there. Book a software health audit or talk to an engineer about your timetable.

Questions

Frequently asked

Can you assess the software before we complete a purchase?

A software health audit reviews one system and gives you a plain-English report with the risks ranked. If you can arrange read access to the code and hosting during due diligence, the audit can inform what you negotiate. Tell us your timetable when you get in touch.

What if we only have limited access to the target's systems?

Start with the questions below, which need no technical access. Ask for read access to the code and hosting as the deal progresses, and tell us what is missing. Finding that out is part of the audit.

Should we replace the inherited software straight away?

Usually not. A system that works is worth keeping while you learn what it does. Make it safe and understood first, then decide whether to keep, merge or replace it with the facts in hand.

Do you look after several inherited systems?

We start with an audit of one system. If you have several, we normally begin with the one that matters most, and the findings help you decide how to treat the others.

Get in touch

Find out where your software stands.

A software health audit gives you a plain-English view of the risks in one system, and what it would take to look after it properly. There's no obligation to continue.