How long does it take to take over a software system?

The part with a known length

The assessment is the one stage we can put a duration on. A code audit takes 1 to 2 weeks. It reports whether the code can be built, how a change reaches production, what is backed up and who controls each account. From that we can say what the rest of the takeover involves for your system, which is the specific answer this page cannot give.

Anyone who quotes a duration for a takeover before seeing the system is guessing.

What the handover has to prove

After the assessment, a takeover is finished when the new team has shown three things:

1. It can build the application from the source code and get the same result as the running system.
2. It can release a change to production in a controlled way.
3. It can restore the system from a backup.

Each depends on things outside the new supplier’s control: whether the code is complete, whether the accounts can be reached, whether a backup exists. That is why the length varies so much from one system to the next. Our takeover process is built around these checks.

What speeds it up

• Complete, current source code in a repository your organisation controls.
• Administrator access to hosting, the database, domain names and third-party services, held in the organisation’s name.
• A release process that is written down or automated, so that a release does not depend on one person’s memory.
• A backup that has been restored before, so the restore check is a repeat and not a first attempt.
• An outgoing supplier or developer who is still available and is paid for handover time.
• One person on your side with the authority to make decisions and chase access.

Our software takeover checklist lists what to gather before the work starts.

What slows it down

• Source code that is missing or out of date. If the copy you hold does not match what is running, the difference has to be found before anything is released.
• Accounts in an individual’s name. Recovering a hosting account or domain registered to a former employee means dealing with the provider, at the provider’s pace.
• A manual release process that only one person knew. The steps have to be worked out by examining the live system.
• Old development tools. Some older systems need tools that are hard to obtain or will not run on a current machine.
• Routine tasks nobody recorded. Scheduled jobs, renewals, manual fixes and connections to other systems tend to surface one at a time.
• Contract terms. A long notice period, an unresolved question over who owns the code or an unpaid invoice can each hold up a handover.
• An unstable system. If urgent faults keep arriving, they compete with the handover for attention.

Where the supplier has already closed or gone silent, the order changes. Securing copies of the code and data and regaining access come first, and the full takeover follows. Our page on a supplier that has stopped supporting a system covers those first steps, and the supplier transition plan sets out the sequence for a planned change.