A couple of weeks ago I got some really good news—I was transferring into a new role at my current company. Since this is an internal transfer, the standard two-week notice stretched to four and I had time to properly transfer my existing projects.
It is important to be as effective as possible in doing this, so you aren’t dealing with your existing projects in your new role.
The first thing I recommend doing is introducing the project contact person (In this case a business user) to the DBA you are handing off to. Ideally, you can do this in person, but since we are at multiple sites, I had to do it over email. Make it clear you will be transitioning all responsibilities over to the other DBA, and are trying to be successful in a new role, so can no longer support this project (be really nice about it—kill ‘em with kindness).
Secondly, if you have an email folder for the project, share it with the rest of your DBA team. If you don’t have one—create one and copy as much mail as you can into it. The search function in Outlook 2010 works really well, and sharing the mail may save you a phone call or two down the road.
Finally, and most importantly, you need to build out a project document. Put as much detail in as possible. I used the below sections for mine:
• Project Contacts—Who you work with, and what is their business function • Vendor Contact Info—Who you work with directly (If a small vendor) or contact/support info for a larger vendor
• Business Purpose—What does this application do, and what does it support? What are the uptime requirements?
• Authentication—How is authentication handled? Are there SQL logins to worry about? • Security Groups—This ties back to authentication, but are there domain groups controlling access to the application? Which groups control which rights?
• SQL Jobs—If the application has agent jobs—what are they? What do they do? How do you handle job failure? Who is the point of contact on the jobs?
• General Narrative—Describe anything else about the application. In our case there are some subprocesses that were failing, so I included that information. I also discussed the application patching process, along with some persistent issues we were trying to resolve with the vendor
. • HA/DR—This was touched on earlier, but how is specifically implemented? Where is the database mirrored/replicated to?
• Architecture—A very detailed Visio showing the whole landscape for the application—client connections, database connections, application servers, any external connections.
This list is in no way complete—feel free to add anything in the comments, I’d love to improve my process.
This is important stuff—in order to be as successful as you can in a new role, you need to be able to transition projects effectively, but this same process can be used to transfer support of an application to an operations team, or outsourcing overnight support.