This question already has an answer here:

We currently have over 300 web projects that are legacy code, that is kind of spaghetti like based on a modified version of an old framework.

Our one developer that knows these systems best is leaving and I'm the replacement, what are the best questions to ask before they leave? I want to make sure I can support all these bespoke apps

marked as duplicate by gnat, Doc Brown, Eric King, Greg Burghardt, Robbie Dee Aug 31 '16 at 8:05

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • How long until this other developer leaves? Is there any current documentation on these projects? Do you know how to maintain these applications? – Matthew Aug 30 '16 at 20:22
  • 7
    "What company are you going? Do you know if there are more open positions?" – RMalke Aug 30 '16 at 20:22
  • "How often do you fantasize about burning the repository to the ground?" – CHendrix Aug 30 '16 at 20:23
  • They have about 1 month left, we have little documentation and nothing is commented – Adrian Aug 30 '16 at 20:31
  • 1
    Question 1: personal phone number; question 2: his favorite beer. – YSharp Aug 31 '16 at 5:34

It depends on your timeframe, existing documentation (if any), the time span in between projects (300 over 1 year or over 30 years), etc.

Start with the most important apps, the ones that require the most frequent changes and go backwards. Understand those as best you can, have the dev. show you the code and frequent change points.

If its overwhelming see if there is a possibility to agree for the dev. to have a fixed hourly rate that they could charge to assist after they leave in case you need them.


You ask for his (her?) contact information. Having them available as a resource (possibly at contractor rates, or possibly over an occasional lunch) is invaluable to keeping legacy systems running.

Regardless of the above, however, get them to map out the system from a high level (including databases accessed and accounts used). You also want to ask for hidden "gotchas" that they are aware of; and take careful notes (these can save a lot of time down the road, if you know what to look out for).

  • Cheatsheets
  • Common errors and their troubleshooting procedures, workarounds
  • Prioritized list of pending refactorings
  • List of error that he has not been able to reproduce
  • Explanation of permissions an roles
  • Databases, connections info, admin accounts and their passwords
  • Version repositories passwords
  • Explanation of crontab jobs and batch processes
  • Contact info of business custodians (the non-IT "owners" of the apps business-side)
  • OS user accounts and password of the crontab/schedule tasks's owner
  • Contact info of himself/herself
  • List of problematic modules
  • Scripts to correct or erase bad inserted data due to app errors
  • Discussion of the part of the database models that are not obvious or clear (a plotted ER model would be nice) for each database.
  • Data life-time considerations that may not be well documented, like: trunc this temporal table every N months, or this transactional table's data must me move to an historical database every N years, etc.
  • Contingengy procedures, including procedures for recovering cluster nodes, promoting an slave node to master and viceversa, etc.
  • Prioritized list of pending requirements, like modifications, new reports, etc.
  • Interfaces with other systems or apps.
  • Dependencies on external APIs

Not the answer you're looking for? Browse other questions tagged or ask your own question.