Has your software been left without support? A roadmap for taking over an existing project

It's a situation many businesses run into at some point: the team or person who built the website, the app or the in-house software no longer provides support. When a bug appears, no one can step in; even for a small change, nobody knows whom to ask. The system may seem to be working, but it becomes a little riskier every day. In this post we describe the steps for taking over software that has been left without an owner.

The risks of unsupported software

• Security: Software and servers that aren't updated become vulnerable to known exploits over time.
• Downtime: When the server, domain or certificate expires, the site may one day simply stop loading.
• Data loss: Nobody knows whether backups are being taken, or where they are kept if they are.
• No room to grow: Adding a new feature or connecting to another system becomes impossible.

1. Gathering access

The first job is to bring together all the keys to the system. This is often the step that takes longest:

• The account where the domain is registered,
• The server or hosting account,
• Where the source code lives (a code repository or the files on the server),
• Database access,
• Accounts for the third-party services in use (email, SMS, payments, maps, etc.).

It's important to establish which of these accounts belong to the business and which were opened in the previous team's name. Transferring the accounts that aren't in your name is the first priority.

2. Infrastructure review

The infrastructure is reviewed to understand where and how the code runs:

• Are the server's operating system and software up to date?
• When do the SSL certificate and the domain expire?
• Are there backups, and can the system actually be restored from them?
• Are the site and services monitored, and will you find out when there's an outage?

3. Code review

Next comes the code itself. The aim isn't to hunt for faults but to give an honest picture of where the system stands:

• Is the code readable and well organised, or does every change introduce a new bug?
• Are the libraries and frameworks used still supported?
• Are there known security vulnerabilities?
• Is there documentation, or did the knowledge live only in the previous developer's head?

4. Report and decision: continue or rewrite?

The review ends with a report that recommends one of two paths:

• Building on what exists: If the code and infrastructure are in reasonable shape, urgent risks (updates, backups, security vulnerabilities) are addressed first, then development continues. In most cases this is the fastest and most economical path.
• Rewriting: If the code relies on technologies that are no longer supported, if every change creates new problems or if the security issues are structural, it can be healthier to build the new system step by step while the old one keeps running.

Whichever path is chosen should be presented with its reasoning, alongside a comparison of cost and risk. A suggestion to "just rewrite everything from scratch" shouldn't be accepted without a clear explanation of why.

5. Documentation and maintenance

The most important gain from a takeover is that the system no longer depends on a single person. That's why:

• How everything works is written down,
• Access is brought under the business's control,
• Updates, backups and monitoring are tied to a regular maintenance plan.

Avoiding the same situation again

When starting a new software project, settling these points from the outset is the best way to avoid the same problem later:

• In whose name will the domain, hosting and service accounts be opened?
• Will the source code and technical documentation be handed over on request?
• How will support and maintenance be provided after launch?

As part of our custom software and integration service, we take over projects left behind by other teams; we review the code and infrastructure first and report clearly on where things stand. Tell us about your system and let's decide together where to start.

We cover the other side, leaving the company that built the project and getting your domain, server and source code back, in our post leaving the company that built your website.

We explain what custom software is and when it is needed in what is custom software development?