Taking over maintenance

Taking over maintenance means looking after a system our team did not build, so before a standing contract we carry out a review: we need to know what we are taking on. Looking after a system our team built is the "Maintenance and development" scope within the "Systems and integrations" service.

What we check before the takeover

Code: whether the company has the full source code in a repository, a place that keeps the history of changes, and whether what runs on the server can be built from it. Access: who holds administrator accounts for the servers, the database and the domain, and which of them belong to people who are no longer there. Documentation: whether it exists and whether it matches what the system does. Licences: on what terms the company uses the database and the libraries, meaning ready-made pieces of code, and whether the fees are up to date. Backups: whether they are made, where they are kept and when someone last restored the system from them. Unsupported components: which parts, such as the database, no longer receive fixes from the vendor.

A joint period, or a takeover without the predecessor

If the previous contractor is available, we agree a joint period: they handle requests while we observe and ask questions, then the roles are reversed. The period ends with a handover record: what we received and what is missing. Without the predecessor, we take the system over from what remains: the code on the server, the logs and conversations with the department. The first weeks go on reading the system; we make changes once we know what they trigger.

The list of gaps and the first clean-up

Every gap found in the review goes onto a list with a note of what it puts at risk for the company and three options: restore, replace, or knowingly leave as it is. You choose, with our estimate for each option. The decisions produce a plan for the first clean-up, in this order:

• the company's own administrator accounts, and access withdrawn from people outside the company,
• a backup, with a test restore of the system,
• the code in a repository on the company's account,
• a test environment, meaning a copy of the system for checking changes,
• updates for unsupported components.

Finally, we write down what the system does today, and that replaces the old documentation.

Then ongoing care

Requests from the department go into a single register: a bug is a departure from how the system worked on the day of takeover, a change is a new feature, and you decide the order of changes. Changes go in through releases, meaning packages checked on the test environment, with a description and a way to roll them back. Monitoring, an ongoing view of how the system is running, alerts the designated people when the system stops responding. Handing the system to your staff, when you want to run it yourself, is a separate scope: knowledge transfer.

When the code does not belong to the company

Sometimes the contract with the previous contractor did not transfer the rights to the code to the company, or the system is the contractor's product under a licence that does not allow changes. In that case the contract is read by team members with legal training; a legal opinion is issued by a law firm. The options: buy the rights or a licence to make changes, limit our care to the data, configuration and servers, or plan to replace the system. We do not change the code until the rights are settled.

1. We review the system under a non-disclosure agreement, with an agreed scope and deadline. Result: a report and a list of gaps on which you base the decision on the takeover.
2. We take over: in a joint period with the previous contractor, or from what remains. Result: a handover record, the company's own administrator accounts, the code in the company's repository.
3. We carry out the first clean-up according to the plan. Result: a tested backup, a test environment, supported components, documentation of the current state.
4. We provide ongoing care. Result: a single request queue, releases on an agreed rhythm, monitoring and a periodic summary of how the system is running.

1. Can what runs on the server today be built from the code we have, and who will confirm it?
2. Which administrator accounts will you take over, which will you withdraw from previous people, and who on our side approves that?
3. When did someone last restore the system from a backup, and when will you do it?
4. What about the parts of the system for which there is no code: a list of gaps, or a takeover in the dark?
5. Does the contract with the previous contractor allow us to change the code, and what will you do if it does not?

We start every takeover with an analysis of the system: you receive the review report and the list of gaps before deciding on a standing contract.