Preparing a New DBA to Take Over a SQL Server Environment

Problem

I have spent the last 13 years managing a SQL Server estate as the lone DBA and decided at the beginning of the year that it was time to retire. How do you fill that gap?

Solution

The company had no one else internally with DBA experience and determined there were only two options:

Hire a replacement DBA.
Contract with a SQL Server consultancy (with the possibility of cross-training someone internally to do basic tasks and escalate when needed).

Without anyone lined up to fill the role at the time, the first steps were to do what was necessary regardless of whether a replacement was found.

Documentation

Documentation is critical. I created quite a bit of documentation in 13 years mainly for my own consumption.

The first step was to fully review all documentation, toss out anything obsolete, and review all relevant documentation for accuracy and clarity. The first document was a spreadsheet of basic information like SQL Server name, version, edition, list of databases, business owner(s), notes on why things were configured a certain way, things to look out for, etc.

Over the years, I got in the habit of creating ‘Support Notes’ documents for each platform. Most platforms consisted of two or three Windows Virtual Machines with the SQL Server on one, the application on the second, and in some cases, a combined database/application server on a third. They’re not meant to be all-inclusive but were meant as living documents with basic server information, issues encountered, how to fix them, and advice on dealing with the vendor.

Lastly, I turned my SQL Server install checklist into a detailed Markdown document. The goal was for anyone with some experience installing software on Windows servers to be able to perform an install consistent with the rest of the environment.

Handoff

By the time my documentation overhaul was complete, the company recruited an experienced SQL Server DBA who would be a great fit for the role and was able to start five weeks before my retirement date.

Still in a hybrid remote/office situation, we decided to work two days in the office and three days remotely via Teams. Our goal was to give the new DBA a strong familiarity of the estate and a good foundation to really dive in, then learn on their own after my departure.

The first day was spent hunkered down in a conference room reviewing documentation. We continued the review in the office and remotely for a week or so. This review was a great way to get another set of eyes on the documentation, allowing me to edit any issues, and ultimately leaving solid documentation behind.

Next, we walked through all the maintenance jobs on each SQL Server. While I always tried to keep everything as consistent as possible across all the SQL Servers, there would always be some nuances, such as the timing of jobs, where DBCC checks were offloaded to another server, etc.

Meetings were then set up with relevant business users, Business Analysts, and Developers for each platform. Each session mainly consisted of asking each individual to talk about their role and a general round table of questions and answers.

Finally, we progressed into the new DBA reviewing all the information we had covered so far on their own and putting together lists of questions and observations we’d then work on. The meetings became less structured and lots of Q&A.

Every opportunity was taken during the hand-off period to allow the new DBA to take on any issues that arose and run with them under my guidance.

What I Learned

It’s always important to go back to the fundamentals. I re-learned and was reminded of basic communication skills and staying in scope.

The following are the main lessons learned:

Stay Focused – I was very fortunate to be working with someone with an insatiable appetite for learning. However, my focus had to be on any technology where I was the only one who worked with it. In a small IT shop, you’re working on things other than pure database administration. There were things that could have been learned from others after I departed that could be covered briefly as time allowed but it was important to stick to the core role.
Review Documentation – Again, documentation is critical. But realize perfection isn’t attainable and should not be the goal. Strive to do the best draft possible, get as many eyes on it as possible for constructive criticism, resulting in good, solid documentation designed for the reader.
Open Communication – Keep communication clear and simple. Whether it’s written or spoken words, the words are not meant to show off how much you know; they are to communicate information to the reader/listener. Use clear and simple language. Even ‘DBA Speak-like’ words can mean different things to different people. If someone is listening to you, the presumption is you know what you’re talking about so there is no need to prove it.
Learn By Doing – Don’t give in to the urge when a problem occurs, and think “I can quickly fix it and show the new person what I did.” Unless it’s a very time-sensitive critical issue, it’s more important to let the new person get in there themselves and work it out with your help, if necessary, to get used to the environment.

Next Steps

I hope sharing my experience of transitioning DBAs is helpful. And, whether you’re looking for a new DBA role, looking to hire a DBA, or onboarding a new DBA, here are links to several tips at MSSQLTips.com to help with this transition.

Resources

Community

Subscribe