Bealers.com

evergreen · planted · tended

Inherited a web app? A due-diligence checklist

All notes, by stage

I gave this as a talk in 2016, for anyone taking over a web application: the new agency, the new freelancer, or the manager who has just been told it's theirs now. Most applications I've taken over had gaps that were real risks for the owner. The aim is to answer one question: walk away if you can, and if you can't, what needs putting right?

Your expectations of what your suppliers do for you may not match reality. In my experience they usually don't provide the thing you think they do, rather than doing it badly.

First pass

Get familiar with it and learn the vocabulary.

  • Platform, language, database, framework or base software (CMS, e-commerce).
  • Versions of each, against the current stable version. How far behind is it?
  • What does it do, and who uses it: the public, existing customers, suppliers, staff?
  • Known urgent problems. Are people complaining? Are bugs logged anywhere? Any promised features still owed?
  • Is there a backlog, who controls it, who adds to it?
  • Any usage numbers or logs?
  • Are the servers patched? Can you point to a backup, when it last ran, and when it was last restored?

Commercial

  • Why is it changing hands? Bad blood, unpaid bills, unreasonable expectations? Will the old team help with the handover?
  • List every supplier: hosting, DNS, SSL, domain registrar, email, designer, freelancers.
  • Expiry dates, and whose card is charged. Is the domain owned by the business, or by the old developer?
  • Contracts: who is responsible for what, and where are the gaps? If something goes wrong, who do you call?
  • Who else has the code, and who controls releases?

Owners often assume their developer or host covers DNS, SSL renewals, upgrades, backups and monitoring. Ask. Often nobody does.

Code and database

  • How big is it? Do seven years of logs need to live in the repo?
  • Third-party libraries and their versions. Browser lock-in on older internal systems.
  • Search the code for TODO, FIXME, "broken" and the odd swear word. It's illuminating.
  • SQL injection, passwords in the code, hardcoded paths.
  • How are user passwords stored? Who holds copies of a database full of personal data?

Infrastructure and access

  • How many servers, what each one does. Get someone to draw you a diagram.
  • How people get in (passwords, SSH keys, VPN), and where the passwords live.
  • Load balancers, firewalls, caches: why they're there, or why not.
  • Monitoring: will anything tell you it's down before a customer does?
  • Who has access, and which old staff or suppliers still do?
  • Scheduled jobs: what runs, when, as whom, and can it be re-run if it fails?

Workflow

Separate dev and test servers that match production, version control, scripted deployment, some automated tests. None of these are luxuries once the app earns money.

The report

Give every finding a red, amber or green. Don't get scientific; ask "if this went wrong, how bad would it be?" Work down from the reds, starting with security.

Don't make it a witch hunt.

You don't know what the deadlines and budgets were when it was built. And if you can't fix something, write the risk down and send it up the chain.

Related: upgrade or rewrite, maintenance is a market you have to make, and the questions I asked when interviewing a sysadmin.

Linked from (7)