Who Will Run the Business System After the Company Changes Hands?

When a company changes hands, the new owner needs to know who will look after its software. Start with the people who know it now. Agree who will keep doing the work, who can approve changes, and what needs to be handed over if someone else is taking over.

Say you've bought a business that uses a custom system for orders and invoices. Staff can still log in. Orders are coming through. So far, so good.

Then an invoice fails to reach the accounting software. Who knows where to look? Can that person still make changes? And have they agreed to help the new owner?

Those are worth answering while everyone is still available.

Who can say yes, who knows how, and who will help?

These can be three different people.

The operations manager may approve changes to the order system. A developer may know how the accounting connection works. A support company may answer requests during agreed hours.

Giving the manager an administrator account doesn't settle the other two questions. You still need someone who understands the software and an agreement about the help they'll provide.

Start by talking to the current team or supplier. Ask who is staying involved and what needs to change. The Australian Cyber Security Centre's guidance on company and organisational changes makes a useful point here: when relationships change, check people's identity and authority. Knowing a familiar name isn't enough to know what that person may approve now.

Write down enough for the next person

You don't need to begin with a giant manual. Start with the work the business needs to get done: taking orders, sending invoices, paying people or producing a monthly report.

For each important job, write down:

• Who makes the business decisions? Name the person who can approve work, including any spending or changes that need someone else's permission.
• Who looks after the software? Include a contact and who to call if they can't help.
• What does it depend on? List the accounts, services and connections it needs, who controls them and how the right people will get access.
• What does the next person need to know? Point to instructions and the people who can explain them. Include the awkward bits, such as what to do when an invoice gets stuck.
• What help has actually been agreed? Record what support covers, when it's available and how to ask for it.
• What's still missing? Give each unanswered question to someone, with a date to sort it out and a note about the work it could affect.

A short document with names and links may be enough for a small system. Keep passwords in a suitable protected password manager or access system. This document should tell people how access is arranged.

Let the next person try a real task

A folder of instructions is useful. Seeing whether someone can follow them tells you more.

For our order-system example, ask the person taking over to follow a sample invoice through a test setup. Can they find where it went wrong? Do they know who to call if the problem is outside their part of the system?

Arrange this with the right permission, somewhere safe. If a demonstration isn't practical, ask them to explain the steps. Keep live customer data and daily operations out of the exercise where they aren't needed. One successful task helps check understanding; it won't tell you whether every possible failure is covered.

Google's account of how its teams take responsibility for running software describes documentation, training and a gradual handover with backup from the developers. A small company can use the same basic idea: give the next person time to learn, and make sure someone can help while they do.

You may already have the right people

A new owner doesn't automatically need a new developer. Keeping the current supplier can make sense if everyone agrees what they'll do and who they take instructions from.

If a new team is taking over, it may need training or some time working alongside the people who know the system. Agree how long that help lasts, when those people are available and what happens when a question falls outside the agreed work.

There may also be plans to connect the software to another company system or replace it later. Treat that as a separate decision from keeping today's orders and invoices moving. NACD and Internet Security Alliance guidance on acquisitions considers access and integration across the stages of a deal. The everyday handover is one part of that wider work.

Check the deal and the relevant agreements with your advisers, too. Don't assume the sale automatically transfers software rights, contracts, source code, licences, accounts or customer data. Having access to something and being allowed to use it are different questions.

Before the handover is finished, you should be able to name who approves changes, who knows how to make them and who has agreed to help. If an answer is missing, make someone responsible for finding it.

We build custom business software and can agree ongoing care or help with a handover. If you need someone to look after an existing system, talk to us about what it does and what help you need.