Our system admin will roll off from the team and will be replaced by new one. I need some pointers to consider before we deactivate his licence. Is there anything we need to do for those batch job scheduled by him and what else do we need to consider? Please advise.
The baseline is the same: https://help.salesforce.com/HTViewHelpDoc?id=deactivating_users.htm
http://www.opfocus.com/blog/deactivating-a-salesforce-system-administrator-without-breaking-the-system/ also outlines some useful tips.
On top of these I'd say:
- check the data storage usage and if needed - transfer all his data to somebody else. Otherwise you'll face lots of "Operation was performed with inactive user" fails. (to be fair people with "Modify all data" will not experience that error, but users will. Which in a way is worse) As a general rule admins shouldn't own any data but distribute it down the tree so sales reps, managers etc. can see it.
- the point above is especially important if you plan to change his role to (blank) or something that'll be effectively top / outside of the role hierarchy (in some companies I saw people moved out of the tree without transferring the ownership. This is stupid, you lose visibility of your own data and if he's not in the roles tree sharing can't help much)
- He might be listed as default workflow user (that's mentioned in the article) but also in inbound email handlers or as Site admin... I think these are pointed out when you try to deactivate him
- The dashboards running under his name (both the normal ones and the ones set up to be emailed on schedule) will fail to run.
SELECT Id, Name FROM Dashboard WHERE RunningUserId = ...should let you identify them all. If you will fail to change the Dashboard or Report user before it's scheduled to run an "emergency" email will be sent out to all sysadmins ;)
- Scheduled reports are listed in setup so it's easy to identify and change the running user. Apex jobs can't be modified, you'll have to unschedule them and schedule fresh under different active user. This might pose somewhat of a challenge if they were scheduled with CRON expression to run with frequency greater than 1 day.
- scan his login history looking for API products (or anything different than a browser really). If his credentials were used in any kind of integration product that'll be silently failing and you'll realize 6 months later that you're not getting some data... Data Loader, Excel connector, Workbench also count as API - checking the IP address might help.
- type his email address to the Search. There might be Contacts or Leads left ;)
- on the day he leaves edit his record. Change his email + tick at the bottom "generate new email & notify the user immediately", that way the change will be instant (without it the new email address has to be confirmed). Only then deactivate.
- repeat above in full sandbox. And if you're worried about IP rights - in configuration / dev sandboxes too (although let's be adults, if he wished to download code or reports he did it long time ago)
- talk with the administrators of your mailing system (MS Exchange?) to forward the messages to one of your team members or some shared mailbox. You might be getting messages from users, system failures (if a trigger fails and he's the last person that modified it). They will also be able to tell if he set up message forwarding to his personal mailbox ;)
Last but not least: squeeze as much info about system as possible. Any kind of documentation artefacts left will save your bacon in the long run. Demand a copy of his Eclipse projects if there's any unfinished work. Get hold of his RealForceEplorer's history of SOQL and Apex snippets (there will be that one data fix that was executed 4 months ago and nobody remembers it but it has to be run again / it broke something horribly). Get the Excel sheets that were used to upload / fix stuff via Excel connector. Etc.