Steve & I have prepared a short list of things to help prepare your organization when you loose your techie. Many organizations rely heavily on their techies, but don't have a plan in place to replace them when they leave. The following is a list of things that may help ensure that there is as little disruption as possible when a key technical staff person leaves.

Basic server/network access (for local machines, but also also dedicated or virtual servers)

• how is user authentication managed?
• what are the root and other administrator usernames / passwords.
• are there routers, firewalls, or other network tools that require usernames/passwords?
• if the server is hosted elsewhere, does the hosting provider have console access?

Domain Names

• where are your domain names hosted? (a domain's zone file is usually hosted with the company that hosts your web site, but not always; you can usually find out by verifying if the NS1-Hostname has a common domain name with the person who hosts your website).
• usernames/passwords for managing Doman names.

Web Hosting

• where and how are your sites hosted?
• how are they administered? (do you upload files with FTP? do you have shell/ssh access? is there a control panel interface? is this a CMS?)
• usernames/passwords (and note that there may be different usernames/passwords for ftp, shell, database, CMS, and control panel accounts).

Email Hosting

• how is your and your clients' email handled?
• (you can usually find this out through the client, but can also look up the MX record using the 'DNS Lookup' on DNSStuff).
• if it is managed by a 3rd party service like Google Apps, you will need to get the username/password for the admin user.

Mailing Lists

• do you use mailing lists (such as Sympa or Mailman) on any of your servers, or provided by a 3rd party (such as Electric Embers)?
• each list will have it's own username/password, but each mailing list manager will also have an over-riding admin or 'listmaster' username/password where you can configure this. information.
• you will at least need the listmaster username/password.

Apache setup

• how is apache authentication managed? (password files, DB backend, etc.?)
• have your clients set up .htaccess files which restrict access to certain files/directories to people without them providing a generic username/password?
• what virtual hosts are running?
• what applications are running on each virtual host? Each application will have its own admin username/password.

Databases

• where are your databases hosted?
• usernames/passwords.
• often you will have different usernames/passwords associated with each database. There also may be others that have access to create new databases, user accounts, or simply to run backups. Some of these are accessible remotely and so can be managed through desktop. applications or via interfaces like phpMyAdmin.
• these databases may also be hosted with a 3rd party or on a separate server, but usually this relationship is something that is managed by the web host.

Client/Site/Server Specific Notes

• ideally there would be site specific notes recorded that would describe any idiosyncrasies of the install (there's almost always something).
• for customized work a recipe would also be beneficial to help guide other developers as to what was set up and why.
• for Drupal ensure that there are notes documenting any customized modules for all sites
• simple things like how cron is run can save time and confusion for the new developer.
• documentation of any known browser issues for client sites.
• list of the key URLs for major applications, sub-domains & control panel interfaces.

Backup routines

• are there both server side and off-site backups being done on all client's sites? Do these include both the file system and the database? Is there a reasonable rotation so that there is time to catch & repair problems?
• if there are remote off-site backups being done there may be an additional username/password required to access them and they may be hosted on a server that may have its own username/passwords.
• when was the last time that the backups were checked to see that they could indeed restore the sites that they were backing up? File corruption is pretty common and not all backup scripts report such problems.
• are backups being burned to optical or magnetic media and stored in a safe? Is there a process for destroying old backups at a reasonable time?
• usernames/passwords for any backup-specific accounts.

Secured Files

• are there any usernames / passwords required to access secured files (many document formats can have passwords associated with them).

3rd Party Services

• are there any 3rd party applications like those required for eCommerce, site monitoring or log analysis reports? Each of these may have a unique username/password.
• companies are increasingly using Web 2.0 services like del.icio.us, Flickr, and YouTube for organizing content and these may have been set up by the departing techie. All will need usernames and passwords.

Reports

• what email address(es) receives logs and error reports?
• is remote logging or monitoring enabled (via syslog, Munin, Nagios, etc,)?

Ongoing work

• detailed status reports of work that is completed and what is left to do.
• snapshots from the last week of all files and databases of all live sites.
• snapshots of active development environments.
• ask that techie send all client data with member information and permanently delete his/her versions of it.

Software Licenses

• are there software or other registration keys that might need to be transferred to another employee?
• where is software stored? where are keys recorded?

Knowledge Transfer

• collecting a list of useful links is always good.
• budgeting the time that it takes to document the work being done is also useful, but rarely happens.
• documenting general approaches to setting up server/development environments would be useful - company style guides or best practices would help to ensure greater consistency.
• lists of tested modules can also assist in bringing a new person on board.
• are there any cheat sheets that the departing employee has developed?
• try to provide as much overlap as you can afford. It can take some time to bring a new person up to speed.