You may be thinking of changing the supplier that looks after your bespoke software. Perhaps the service has become slow or unreliable, perhaps the agency is winding down, or perhaps you simply want someone accountable for it. Whatever the reason, you are right to want a calm, planned change, not a sudden one.
A takeover can be done without disrupting the business. The order of work matters, and it starts with keeping the system running as it is.
What a takeover involves
Taking over a system means taking on responsibility for it: knowing what it does, where it runs, how it is built and released, and what to do when something goes wrong. For most systems there are four jobs.
- Get access. The code, the hosting and the accounts the system depends on.
- Make it safe. Put the code in your own source control, take backups you can restore, and replace shared passwords.
- Make it repeatable. A build and release anyone can run, with monitoring to show when something goes wrong.
- Write it down. Documentation, so the system no longer depends on what one person remembers.
Nothing here changes how the system behaves for your users. The aim at first is to protect what works, and improvements come later.
What we need from you
Gather what you can, and tell us what is missing. Finding out what is missing is a normal part of the work.
- The source code, with its history if possible, or the name of whoever holds it.
- Hosting, meaning the cloud subscription, servers or hosting account where the system runs, and who can sign in.
- Domain names and certificates, including where they are registered and when they renew.
- Accounts and access for any outside services the system uses, such as email sending, payments or licences for components.
- Documentation, however thin: notes, diagrams, handover emails, the original specification.
- A contact at the outgoing supplier, if you can arrange one, for questions.
Our article on handover checklists goes through these in more detail, and the same list works when the supplier is an agency as well as an individual.
Working with, or without, the previous supplier
The best handover has a cooperative overlap: a few weeks in which the outgoing supplier answers questions, shows us how a release is done and points out the awkward parts. We would ask for a short walk-through of the system, a list of what it connects to, and a trial release while they watch.
Sometimes there is no overlap. The supplier may have closed, stopped replying or left on poor terms. A cold start is slower and has more unknowns, but it is workable, because a running system can be inspected and the code and hosting hold most of the answers.
Either way, we stay courteous and factual with the outgoing supplier. We ask for what you are entitled to under your agreement, keep a written record of requests, and avoid comment on how the system was built. If a dispute develops, that is for you and your legal adviser. Our job is to keep the system safe and running.
The first month
We follow the same order on every takeover, as part of our software care service. It starts with a health audit, then onboarding, then monthly care.
- A software health audit. A review of one system, giving you a plain-English report with the risks ranked. We sign a non-disclosure agreement before we look at anything. Read about the software health audit.
- Onboarding, in the first month or so. We secure access, take the code into your own source control, get a repeatable build and release working, add monitoring and start the documentation. Automated tests are added as the work goes on.
- Monthly care. We monitor the system, apply security updates, keep it in support and report in plain English.
A named senior engineer is accountable for your system, with a named backup engineer who also knows it. Throughout, the live system keeps running, and a named engineer approves anything that reaches it.
Who owns the code
Ownership depends on your agreement with the person or company who built the software. In general, software written by an employee belongs to the employer, while software written by a freelancer or an agency may stay with its author unless the contract assigns it to you in writing. This page is not legal advice. If your paperwork is missing or unclear, take legal advice rather than assume. Our page on what to do when your developer has left covers ownership in more detail.
Ownership of the code is separate from the right to keep running the system. Many organisations can carry on using their software while the position is clarified.
If the system came to you through an acquisition, see inherited software. If you are not sure what you have, our article on questions to ask about your bespoke software is a good place to begin.
Next step
Start by listing what you have and what you do not, and keep it somewhere safe. Then book a software health audit or talk to an engineer. You do not need to have everything in hand first.