I wrote a longer piece a while back on evaluating SQL Server managed service providers and a shorter one on Linked In with 3 questions I’d ask before hiring one. Both of those are more about who you’re trusting – and that’s really the most important thing to consider. This one’s more mechanical… the actual stuff I’d put on a checklist if I was the one doing the buying. Some of it overlaps a little with the other two, but some leadership coach once said my job as a leader is to be the chief repeating officer.
1. What starts the SLA clock?
Every proposal says something like “15 minute response SLA.” Nobody ever asks what starts the timer. Is it when your ticket lands? When someone acknowledges it? When it gets assigned to an actual DBA? I’ve seen firms where the 15 minutes doesn’t start until a human picks it up, which means the real number is “15 minutes plus however long it sits in a queue,” and that second number is the one that matters at 2am. Is it different during business hours and after hours? That can be fine, as long as they explain it so you know what you are getting into.
2. Do they test restores, or just check that the backup job said “success”?
A green checkmark on a backup job tells you the job ran. It doesn’t tell you the backup is restorable. Ask when they last did an actual test restore on your environment, not a generic one, yours. If the answer is “we haven’t needed to,” that’s not reassuring, that’s untested. (For full disclosure – this is something we push towards, many clients allow it, some we negotiate on but with all – it’s imperative to us and something we strive for so long as we can.)
3. Who has access to your data, and how do you know?
This one matters more every year, and it matters a lot if you’re in healthcare or finance or anywhere with PHI or PCI in the mix. Ask if DBAs use individual logins or a shared service account. Ask about MFA. Ask whether sessions get logged if they use a tool for remote access. And if you’re a healthcare organization, ask point blank whether they’ll sign your BAA or whether they expect you to sign theirs. We review and sign the client’s BAA rather than pushing our own form on people, mostly because it’s one less thing for their compliance team to fight about, but ask whoever you’re evaluating what their answer is, because “we’re HIPAA compliant” as a phrase on a website means less than you’d hope. We’ve signed a lot of BAAs and support many Credit Unions and many health care providers and insurers – and they each have slightly different implementations of security. Ask before you sign if your provider will work with your security. They should send your their connection info and talk about access before sending a contract.
4. What happens to the tooling and the history if you leave?
A lot of managed DBA shops run their own monitoring stack on your servers. Fine, that’s normal, we’ve been building our own. But ask what happens to your historical data, your baselines, your trending, if you ever switch providers or bring it in house. Do you get to review it? If they are using a third party tool like SQL Sentry, can you transfer a license to your own? Do you start from zero with the next vendor? This is the kind of question that never comes up during the sales call and always comes up during the breakup. Do they use a bunch of proprietary, hard to understand, encrypted custom maintenance? Or do they use something like the Ola Hallengren scripts that are industry recognized and supported? Will they knowledge transfer with you when you leave? Will it be helpful or it will they be a hostile witness?
5. Are you locked into a contract, or can you actually leave?
We run a no cell phone contract quarterly retainer at Straight Path, on purpose, because I think being able to leave is part of what makes a vendor relationship honest. If a firm needs you locked into a 2 or 3 year contract to make their numbers work, ask yourself why. Sometimes there’s a good reason (bigger up front implementation work, for example). Sometimes it could be that they know they risk losing you without the lawyers and buy outs. We earn each renewal period.
6. How do they handle patching and version upgrades, proactively or only when you ask?
This is the boring one and it’s also the one that quietly causes the most damage. Ask who owns the patching cadence. Ask what their process is for testing a cumulative update before it hits your production servers. Ask how they handle a SQL Server version going end of life, do they flag it a year out or do you find out when Microsoft stops answering your support tickets. Do they nag you over and over about upgrades?
7. Can they show you real data from real clients about their successes?
Real clients, real feedback. Scores that show trends. Can they speak about how they use client feedback to continually improve their service offerings and grow with you? Do they have long-term loyal clients. Can they talk about actual issues and differences they’ve mad? Actual before and afters that. Downtime reduced from X to Y. Query time cut in half. A migration that didn’t blow the weekend. If a firm can’t point to a specific outcome for specific clients (redacted if needed) they might be great, but you’re taking their word for it instead of seeing it. Can they give you referrals to call and talk to?
None of these 7 replace the 3 questions about who’s actually picking up the phone at 2am, or the longer piece on culture and team depth. Those tell you whether you’ll like working with them. These tell you whether the mechanics will actually hold up when something breaks. Ask both sets.