Why takeovers go wrong
Takeovers usually go wrong in a few predictable ways: an account still in a former supplier’s name, a password nobody has, a backup that has never been restored, or code that is not what is actually running. None of these is hard to fix, but any one of them can stop you releasing an update or recovering when something breaks. The checklist below closes them off in order, starting with the ones that cost the most if they are missed.
Before day one: what to collect
Most of this list is about ownership. Ask your current developer for these while they are still available, and check that each account is in your company’s name rather than theirs:
- Access to the code repository (for example GitHub, GitLab or Bitbucket), with your company as the owner.
- Logins for where the product runs (the hosting or cloud account), your web address and its settings (domain and DNS), and the service that sends your emails.
- The Apple App Store and Google Play accounts, if you have mobile apps.
- The payment provider account, and any other paid services the product relies on.
- Whatever documentation exists, even if it is out of date, and the list of known bugs and open requests.
Then agree with the new team what the first two weeks will cover and what “done” means, before any work starts.
If your current developer will not help
You can still take over. For EZBuild, LNOKS planned for no handover from the previous supplier and started from what was in the main code repository. What matters most is that the accounts are in your company’s name. Almost everything else can be worked out from the code.
The first two weeks: make it safe to change
The aim of the first two weeks is not new features. It is to reach the point where the product can be changed without fear. In order:
- Change the passwords and keys the previous team had, and remove access nobody needs any more.
- Make a full copy of the data and files, and test it by restoring it (a tested backup), before changing anything.
- Check that the code you were handed is really what your customers are using.
- Put one update through a safe test copy of the product (staging), writing down every step, so updates no longer depend on one person.
- Set up warnings that tell a named person as soon as something stops working (monitoring and alerts).
- Write a plain-language list of the biggest risks, each with what it would take to fix.
The third step catches more than people expect. On one CRM LNOKS took over, the live servers, the test copy and the code repository held three different versions of the product. They had to be matched up before anything could safely change.
At LNOKS the first two weeks also end with two or three agreed fixes live in your product and a fixed-price plan for the next step, so you see real changes and not only a report. The software takeover and support page sets out how that works.
After the handover: keep it running
Once the basics hold, the work becomes routine. Updates go out on a regular schedule, each one checked by a second engineer and tested before customers see it. Every month brings software updates, security fixes and a short written report. New features come once updates are safe, not before.
Questions to ask a team before they take over
- Will the code, servers and accounts be in our company’s name?
- What will we have at the end of the first two weeks?
- How will you check that the code matches what is live?
- Will you want to rebuild everything, and if so, what evidence will you show us first?
- Who do we contact when something breaks, and when are you available?
A team that answers these plainly, in writing, before starting is usually a team that will run the handover carefully.
