The end is coming. It may be next week or it may be next year but soon it's going to happen: someone in your organization is going to leave. There's a lot to be done when someone leaves, but being prepared in advance can make the process a lot easier. There's a lot of HR and training needed when someone leaves the company, but this is the software development blog, so let's talk about the software. Handling the transition of a member of the IT staff can go smoothly or poorly, and it's all in how you prepare.

Preparation

Preparation starts far before anyone tenders their resignation. Any organization uses many systems and has accounts: an MSDN login; a Github account; user accounts on various servers; an admin user in the ticketing system. Make sure that none of these are tied to a person. Instead, use an organization address or login (e.g., "Administrator" or "IT@myorg.com").

• Always use a corporate email address for accounts. It's easy to forward email from that corporate account to the appropriate individuals, and when one person leaves then it's far easier to change the forwarding than to change the email address on the account. This also means that other people who need to access the account can use the password reset functionality or other emailed services, even when the original account holder is on vacation or gone.
• Use individual SSH keys. This sounds like the inverse of the advice above, but it makes managing servers a lot easier! If each person has an SSH key they use to access systems, then adding that individual to the system and removing them from the system is a simple matter of putting their key in the hosts allow or deny list. Again, make sure that systems (i.e., machines) have their own keys, and not a person's key.
• Keep passwords in a central location. All account passwords should be accessible to more than one person. Password vaults are good for this, but a private document on a shared drive (or Google docs) will do in a pinch.
• Ensure that passwords and other account information are in configurations, not hardcoded in software. This is a good development practice anyway; it makes deployments and running across multiple environments substantially easier. It also means that changing a password does not require a redeployment or a new build of the software.

Once you've set yourself up for success, you can practice accessing systems while someone is on vacation. After all, vacation is a form of leaving — just a temporary one! When the day arrives and someone leaves permanently, you'll lean on your infrastructure to handle that event. It doesn't matter whether the person is leaving under good circumstances or bad; you should still take these steps to protect the company and the (now ex-) employee. In most cases, the departing employee isn't intending to do anything nefarious, but it's much safer to protect everyone involved. You don't want that rare angry employee to do something! It's also fair to the departing employee; they don't want to be (erroneously) blamed for anything that happens! The day someone leaves, do the following:

• Roll passwords. Change all the passwords for accounts. This includes updating SSH allow lists and keys, and changing all the passwords for the accounts that person could access.
• Check mailing lists. The person was probably on mailing lists and should be removed from those lists. This also applies to auto-forwards from those company accounts.
• Close or forward the person's accounts. Just to be on the safe side, make the person's account read-only and disable access to everything, but don't delete it yet. Give it a few weeks, and then go back and delete it once you're sure you don't need it. The same is true for the person's email account. Don't delete it; just disable login and auto-forward it to the appropriate person (usually the departing employee's boss).

Leaving happens. Make sure it goes as smoothly as possible. Image: Courtesy of Larry West/Flickr (Creative Commons)