Taking over software built by another company

Yes, another team can take over software that another company built, provided you have, or can get, five things: the code, the accounts and credentials, the infrastructure, the list of dependencies and some documentation.

This is not legal advice. Who owns the code depends on what was signed; if you have doubts, take legal advice.

• Do you have access to the whole repository, with its history, or only a zipped copy?
• Can you run it on another machine by following the instructions, or does it only work in the supplier’s environment?
• Is it clear who owns it and what licence it carries?

• Who holds each account: domain, hosting, transactional email, payment gateway, maps, analytics?
• Are they in your company’s name or the supplier’s? This is what takes longest to sort out if you have to ask for it later.

• Where does it run, and who pays for it?
• Are there backups, and has anyone ever checked that they can be restored?

• Which libraries and third-party services does it use, and in which versions?
• Are any of them on a paid licence or no longer maintained?

• Are there automated tests that tell you whether a change breaks something?
• Is there documentation of how it is built and how it is deployed?
• Are there parts nobody dares to touch?

A specific request in writing avoids misunderstandings. What is usually worth asking for:

• The full repository, with its history.
• The accounts, with access and ownership transferred to your name.
• The technical and deployment documentation.
• The keys and secrets, handed over through a secure channel and not by email.
• The list of dependencies and third-party services.
• The backups and the data.

An orderly handover does not start by adding features. Follow this order:

• Inventory: what there is, where it is and in whose name.
• Access and running: check that the system can be brought up outside the original environment.
• Technical review: tests, dependencies, security and accumulated debt.
• Stabilisation: fix whatever puts the system at risk before building anything new.

• Only the supplier knows how a release is published.
• The important accounts are in the name of someone who has left the supplier.
• There is no way to run it outside the original environment.
• Nobody can say what data it stores or where.

• Ask first for a review of what exists, before a proposal for changes.
• Make sure the new contract says who owns the code and what documentation is delivered.
• Transfer the important accounts to your name before you start.

At BAZROX we review what you have before proposing anything.

Technology evolution

Support, maintenance and modernisation of live systems

Can I use code that another company wrote?

It depends on what was signed and on the code’s licence. Before you start, establish in writing who owns it and what rights of use and modification you have. If in doubt, take legal advice: this guide is not legal advice.

What if the previous supplier won’t cooperate?

What you can do depends on what you already have. If you have the repository and the accounts, work can go ahead without their help. If not, the first step is to settle ownership and access, and that is where legal advice is worth having.

Does it have to be rebuilt from scratch?

Not always. A technical review tells you whether the system can be maintained as it is, whether it is worth rebuilding only some parts, or whether it is better to start again. The decision should be made with that review in front of you, not by instinct.

What is the first thing I should secure?

The accounts and access to the code. With those you can carry on with any team; without them, every other improvement depends on someone who is no longer there.

Software and website maintenance: what to include

What maintenance of software or a website should include, which conditions are worth putting in writing and what the cost of maintenance depends on.

Web agency or digital product studio

What sets a web agency apart from a digital product studio, when each one fits, and how to read a proposal before you sign it.