Insight ยท October 2026

Your developer has left: what to do with a bespoke system nobody understands

Your business depends on software built by one person or a small firm, and they've retired, moved on or stopped answering. The system still works, for now. Here's how to take back control before something breaks.

First: don't panic, and don't change anything

A system that has run for years will usually keep running for a while yet. The real risks are a failure nobody can fix, a security problem nobody patches, or losing access to something you didn't know you depended on. So the first job isn't development. It's making sure you own and can reach everything.

Secure these before anything else

Make a list, and find out who holds the login for each of these:

  • Domain names: who the registrar is, whose account they're in, and when they renew. A lapsed domain takes your website and email down with it.
  • Hosting and cloud accounts: the server, cloud subscription or hosting control panel the system runs on, and whose card pays for it.
  • The source code: where it lives (GitHub, Azure DevOps, a USB stick, the developer's laptop) and whether you can get a copy.
  • The database and backups: where the data is, whether backups exist, and whether anyone has ever restored one.
  • Third-party services: payment providers, email sending, SSL certificates, map or address-lookup APIs. Each is an account, usually in someone's name.
Ownership matters: accounts registered in a developer's personal name are common, and they're the hardest thing to recover once relationships go cold. If the developer is still reachable, ask politely for everything to be transferred into your company's name now.

Warning signs that it's urgent

  • The system runs on software that is out of support, such as .NET 8 after 10 November 2026, Windows Server 2016 after 12 January 2027, or SQL Server 2016, which lost support in July 2026.
  • Nobody can tell you whether backups work.
  • Small things are already going wrong: failed emails, slow pages, reports that don't add up.
  • Card payments or personal data pass through the system, and nobody knows how it's secured.

Find out what you actually have

Before anyone quotes for changes, someone needs to understand the system. A good takeover review answers:

  1. What is it built with, and is that still supported?
  2. How is it deployed? Can it be rebuilt from the source code, or does the live server contain changes nobody saved?
  3. Where are the risks? Security, single points of failure, missing backups, expiring certificates.
  4. What does it need next? Steady care, an upgrade, or a staged modernisation. A full rewrite is rarely the right first answer.

The output should be a written report you own, so the knowledge never lives in one person's head again.

Choosing who looks after it next

Plenty of developers will offer to rebuild your system from scratch. Sometimes that's right, but it's expensive and risky, and it throws away years of business rules that already work. Look for someone who:

  • has experience with the technology your system already uses
  • starts by understanding and stabilising, not rewriting
  • puts every account and the code in your company's name
  • documents as they go, so you're never in this position again
  • offers a clear support arrangement, so you know what's covered

Need a hand?

I've built and supported bespoke business systems for 30 years. One job, stock and invoicing system I built has been in daily use for more than 11 years, and I've rescued a failing e-commerce site left behind by someone else. My fixed-price takeover audit tells you what you have, the risks and what to do next, and recovers your accounts into your own name.

Book a takeover audit