Taking over a system someone else built
When the developer or supplier behind your software is no longer the right one, we take the system on: securing access, proving it can be built and released, and then looking after it.
What changes hands
A takeover moves everything needed to run the system into your organisation. We then work with access that you grant and can withdraw.
Before the handover
Held by the previous developer
- Source code
- Server logins
- Domain names
- Backups
- Release steps
- Documentation
Held by your business
Little or nothing
After the handover
Held by the previous developer
Access removed
Held by your business
- Source code
- Server logins
- Domain names
- Backups
- Release steps
- Documentation
A change of supplier is a risky moment
Software changes hands for ordinary reasons. A developer retires. A small supplier is bought by a larger one that has no interest in a ten-year-old system. A relationship sours over price or responsiveness. Whatever the cause, the handover is the point at which things get lost: a password nobody wrote down, a server only one person knew about, a monthly job that ran from somebody’s desktop.
Our takeover process exists to make sure nothing is lost, and that by the end of it you hold everything needed to run the system with us or with anyone else.
We do not change anything first
The temptation with an inherited system is to start fixing the things that are obviously wrong. We resist it. Until we can build the application from its source, release a change in a controlled way and restore it from a backup, any fix is a gamble.
So the first work is unexciting. We find out what exists, bring it under your ownership and prove the basics. In our experience this is also where the surprises appear: backups that have not run for months, code on the server that differs from the code in the repository, a licence in a former employee’s name. It is far better to find those in week one than during an outage.
What you have at the end
You have a system that is known. There is an owner for every account, a tested way to recover it, a documented way to release it and a list of what it depends on with the support dates for each. From there, ongoing maintenance is a predictable monthly arrangement, and any modernisation can be planned from facts.
If you want an independent view of a system before committing to a change of supplier, a code audit gives you one at a fixed price.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss a software handover 0800 433 7990What the handover establishes
- Ownership and access
- A register of every repository, server, domain, cloud account and third-party subscription, who controls each, and a plan to move them to your ownership.
- A build from source
- Proof that the application can be built from the code you hold. A source archive only one former developer's laptop can compile is not much use.
- A tested restore
- A backup restored into an isolated environment, with a note of how long it took and how much data would have been lost.
- A repeatable release
- A documented path from an approved change to production, including database changes, configuration and how to roll back.
- A dependency inventory
- Every framework, database and external service the system relies on, with its vendor support status.
- A handover pack
- The documentation another team would need to pick the system up, kept current from then on.
The order we work in
Know what the business depends on
We list the workflows that must keep working, who uses them and what an interruption would cost, and identify someone who can confirm each still behaves correctly.
Secure ownership and access
Credentials are transferred through a secure channel, accounts are moved under your control and the outgoing party's access is removed once the handover is complete.
Prove build, restore and release
We build from source, restore a backup and ship one small, low-risk change. These three checks tell us more about the system than any document.
Record important behaviour
We add automated checks around the calculations, permissions and integrations that matter most, before changing any of them.
Choose the first useful change
With the system under control, we agree a first improvement with a clear business purpose and a result you can see.
Each step is priced before you commit to it
You can stop after any step and keep what it produced. Nothing depends on agreeing to the next one.
-
A first call
Free20 minutes
You describe the system and what prompted the call. We say whether we can help, and if we are not the right people we say that too.
Arrange a call -
A code audit
£1,950 fixed1 to 2 weeks
A written report on the condition of the system, its risks and what to do first. It is yours whatever you decide, and the fee is credited against any work that follows.
What the audit covers -
A first piece of work
Fixed priceAgreed in writing
Usually the priority items from the audit, or one defined package. Scope, price and acceptance checks are agreed before we start.
How fixed price works -
Ongoing support, if you want it
From £450 a monthCancel with 30 days' notice
A monthly plan covering faults, updates and small changes. The code, accounts and documentation stay yours throughout.
Support plans
A good fit when
- Your developer has left or is leaving and there is no successor.
- Your supplier has closed, been acquired or stopped responding.
- You are unhappy with the current supplier and want to move without disruption.
- You have inherited a system through an acquisition or reorganisation.
Probably not for you if
- The outgoing supplier owns the code and will not license or release it. We can advise, but that is a contractual matter to resolve first.
- You want a rewrite quoted without anyone examining the existing system.
Questions we are asked
Can you take over without the previous developer's cooperation?
Usually, provided you hold the source code and administrative access to the servers and accounts. Cooperation makes the handover quicker, but we plan on the assumption that we may not get it.
What if we do not have the source code?
First we check whether it can be recovered: from the hosting server, an old repository, a backup or the supplier's contractual obligations. If it cannot, the realistic options are to keep the system running unchanged or to replace it.
How long does a takeover take?
It depends on the size of the system and how much access you already hold. A small application with code and credentials to hand can be under our care within a couple of weeks; a larger one with missing pieces takes longer. The assessment gives you a specific answer.
Will there be downtime?
A takeover should not need any. The system keeps running where it is while we establish that we can build, restore and release it. Moving hosting, if that is needed, is planned separately.
Who owns the system afterwards?
You do. Every account, repository and document is held in your organisation's name, so you are never locked in to us.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.