We sell DBA as a Service here at Straight Path. Managed DBA services work most of the time, but sometimes it doesn’t, even for our clients.
Remote DBA services can go wrong because the provider fails, because the client makes it difficult for the service model to work, or because neither side clearly defined the ownership, expectations, and relationship in the first place.
Usually when it goes poorly, everyone involved on both sides is competent and has the best of intentions, but nobody ever really clarified what “DBA as a Service” means.
We’ve been a company for 15 years, since July of 2011, and we’ve been delivering DBA as a Service with a team the way we do today for about 10 of those years. That means we’ve seen versions of all of these… Situations where we’ve taken over a relationship, or given some advice, and even even situations where we could have done better ourselves and learned along the way.
If you’re thinking about moving forward with a Remote DBA firm/Managed DBA services/DBA as a Service firm (insert your favorite phrase here – Fractional DBA as some friends in the industry call it works, too) – here’s a list of some problems worth thinking about before you sign an agreement. With us, or any of our friends in the space.
This post is part of our series about Buying DBA Services. Some thoughts and tips to help you on your journey to buying services from us or our friends in the industry.
1. What happens when nobody knows who actually owns the SQL Server problem?
Any new partner will create some gaps in ownership without great communication. A managed DBA relationship can definitely create friction when who owns what and who does what isn’t clear.
Internal IT, the DBAaaS provider, an outside MSP, application vendors, developers, the cloud provider, storage/network teams, and SaaS application support can all assume someone else is watching. They can all assume they are the ones who should make the change, sometimes unilaterally. Backups, restore testing, storage alerts, Windows patching, SQL patching, vendor escalations, maintenance best practices, performance response, and downtime approval all need clear owners.
When something breaks, “that’s not us” is a failure mode. So is the quieter version where everyone assumes the managed DBA team is covering something they were never scoped to own (or any of the teams are expected to own something they never should have.)
Healthy version: responsibility, accountability, consultation, and information are explicit.
2. What happens when your Remote DBA provider never really learns your environment?
If every ticket feels like starting over… “Which application is this? Who’s the vendor? Why is it configured this way?” and the basics are never moved past, you don’t have an established DBA relationship. You have consultants with a recurring invoice.
Institutional knowledge should accumulate: architecture, business context, which servers are fragile, which vendors require unusual settings, what changes the organization will not tolerate, and the history of prior decisions.
Documentation, a named lead DBA with a regular meeting cadence learning the environment (and then documenting it for the rest of their team), and a team that actually uses ticket history and reads the notes are the difference.
* – This is an area we’ve seen a need for improvement over the years. In the early years I pretty much knew it all – there are IP addresses I still remember for some of our clients who are still clients ten years later – but we are a bigger team, and standardizing documentation, making sure we track the important details and properly work on hand off is a key part of what Evan is doing as we continually mature operationally.
3. Can DBA as a Service become too reactive?
Yes. Admittedly it can happen. The opposite is also scary, and I still think maybe a bit more scary…
A provider can look excellent on response metrics while repeatedly fixing the same underlying condition. Ticket → fix → ticket → fix. The SLA stays green while the real problem never gets addressed. That’s the “Security monitor” thing I always get at when I show my team that old Geico commercial I referenced in an earlier post.
The useful question is whether the team has both the capacity and the incentive to ask “why does this keep happening?” and then do something about it. Purely reactive managed DBA is just expensive break-fix. We’ve taken over from some of the break-fix only services. But as I get at in that post I just linked to, some clients really just want the quick and reactive “fix” and not the solution.
Know what you want here and ask the questions to understand if the approach will match what you need.
4. What happens when you buy too few DBA hours?
Undersizing can make for some awkward conversations without good, regular check-ins from your sales rep or Lead DBA (we don’t have sales reps here, but really – whoever manages your relationship with the provider. For us, it’s your lead DBA.)
When there isn’t regular communication and a clear idea of desires, confusion wins. The client becomes reluctant to use the team. The DBA becomes reluctant to spend hours. Proactive work gets deferred. Technical debt survives. Six months later everyone wonders why nothing meaningful improved.
Providers can contribute to this by underselling to win the deal. A correctly sized service is often cheaper than a cheap service that never has room to do the work. When usage genuinely drops, a good provider should tell you to move down a tier. A model that doesn’t fix someone at a level but allows flexing up and down to save on overage helps, also.
5. What happens when the DBA team gives good advice the client cannot (or will not) act on?
The recommendation is sound. The maintenance window never appears. Restore testing has no resources allocated and the budget excuse comes up. The upgrade keeps sliding to the point a client is open to security risks that impact their compliance. The vendor configuration stays broken because of politics, competing priorities, or a vendor that refuses to change.
Sometimes the provider failed to translate the recommendation into clear business impact, realistic effort, and a next step that accounts for how your company actually works. Sometimes the client truly cannot or will not act. We find with good communication, a compromise and approach to getting towards compliance can happen. Sometimes impasse wins, and that’s a situation that is waiting for a big and bad moment and, I think, ought to be discussed.
DBA as a Service cannot outsource the client’s ability to make decisions or navigate internal reality, but a provider needs to be willing to have the tough conversations and “lead” the client – accepting that not every hill is a hill to die on. On the sales and onboarding calls be honest and open about your “can’t budge” scenarios, and get a sense for how the provider will or will not work around that.
6. What happens when communication is bad?
Technical accuracy is not the same as successful communication. “MAXDOP is wrong” is a simple finding to use here, but insert any other one, phrased without context, and a finding can land as noise. Something the client experiences as urgent can look routine to the DBA. Sales language about “monitoring” can be heard as “a human is watching and will fix everything automatically.” For some shops they mean that for others they literally mean the monitoring, but the humans are watching during certain hours and days.
Ticket updates the provider considers sufficient can be invisible to the people who actually need to know. Expectations always fail first in the “setting” phase – then they can fail in the meeting phase. A lot of the times, the situations I get brought into are almost always on the “failure to set and communicate side.” Turns out humans are humans and communicating well isn’t universal (I struggle with it – there are 2-3 clients over the past 15 years who would tell you all about my failures there.)
Ask your provider how regular updates happen. Is it a “QBR” with a sales and account exec? Is it a monthly meeting with the DBA? Who can you call for escalations? Does someone review tickets and coach their team? Do others join our calls?
7. What happens when emergency and after-hours expectations aren’t clear?
“24×7,” “on-call,” “monitoring,” “15-minute response,” and “emergency support” can describe very different realities and there are a host of other nuances to add to those.
Who notices the problem? Does the client have to initiate? What actually qualifies as P1? Does “response” mean acknowledgment or active troubleshooting? Is remediation included? What happens if the primary person doesn’t answer? What happens after hours?
Ask any provider to walk you through exactly what happens at 2:13 a.m. when production is down. The clarity (or lack of it) is revealing.
I’ll tell you right here – we don’t have a 24×7 NOC watching alerts. It’s worked really well for our 130+ clients who we manage. Many manufacturers with 3 shifts, hospitals, Credit Unions who manage their own online banking with 24/7 up time SLAs, SaaS companies who make their year around Black Friday, and more have seen success with our support model. And we are fine without having that NOC – I personally believe that a DBA shouldn’t be the first tier of support. We are very clear about that on the sales calls. We have an on-call rotation with our full-time DBAs – you call the number and within 15 minutes a DBA is on a call with you.
8. What happens when the lead DBA leaves or the relationship with them breaks?
Even in a team model, most clients form a primary relationship with one person. At Straight Path we believe in “it takes a village”, and most of our clients get to know a lot of the folks on our team. But they still have a Lead DBA. We don’t have a salesperson doing a QBR – we have a Lead DBA in a monthly meeting (some clients are weekly or bi-monthly during active projects and some just need it for their relationship with all that’s going on.) When that person leaves the provider, changes roles, or the working relationship stops clicking and a client is better served by a different lead (for communication styles, skill depths or any number of reasons), context and tribal knowledge can disappear.
A mature provider should have real documentation, shared history, and enough depth that the loss is painful but not catastrophic. Many do not. The client then experiences the service as starting over with someone who doesn’t know them.
If the value of the relationship lives mostly in one human’s head, you still have key-person risk. Ask how they handle the transitions, what lessons they’ve learned over the years with it,
* – We’ve dealt with this ourselves. We have a really good “Sabbatical/Major Leave” transition plan and policy. No one’s sabbatical can occur until they’ve done really thorough handoffs and intros are made and our leadership team watches that handoff. It works amazingly well. But we never really thought to apply that same rigor to the “oh no a DBA is leaving!” – that happens so infrequently, our team just stays, but we learned that this year when a DBA left – a couple clients were not lost, but not handed off as well as they could have been to their amazing new DBA. We’ve worked on that with internal policies and a lot more review with DBA to DBA transitions, even when we’re just shuffling clients around for scheduling.
9. Can a managed DBA provider create too much dependency?
An unhealthy version of retention looks like this: “We can’t leave them because nobody else understands anything.” I think inertia should NEVER be a customer retention policy for a provider – because eventually the cruddy performance or repeat issues will erase their loyalty and there is nothing to keep them. Gatekeeping and knowledge hoarding are, likewise, a terrible retention plan for a DBA as a Service relationship. So is “the contract has an exit penalty…”
If leaving would create an operational crisis solely because knowledge, credentials, architecture decisions, and history lived only in the provider’s heads and they always said “why are you asking that, just let us press those buttons, we got it, ignore us…”, then you’re in for a rude awakening someday…
Healthy relationships document, transfer knowledge, keep access belonging to the client, and make transition possible. Clients should stay because the relationship continues to provide value, not because departure has been made artificially difficult.
Ask if they mentor your team. Ask if it’s a sign of success to see a client downgrade a level because their team took on knowledge. Ask if they’ll tell you when it’s time to hire someone and how they can help you hire and train them. Listen carefully to the answer and push into any answers that make you question the authenticity. This is your environment, after all. And any managed service provider is here as a guest who should be staying because they are so helpful you can’t think of any other scenario than them staying – not because you have a fear of what can break when they leave.
How to avoid these problems before you sign
| Ask the provider… | What you’re trying to learn |
|---|---|
| Who owns what in the environment? How will you call the ball? | Whether responsibility gaps are clear |
| Who will actually work with us over time? | Continuity and context |
| How do you learn and document our environment? | Whether knowledge accumulates |
| How do you balance proactive vs reactive work? | Whether you’re buying more than tickets |
| What happens if our hours are consistently too low or too high? | Whether incentives align and they’ll let you adjust levels |
| What do you do when you recommend something we can’t act on? | Whether they adapt to political and operational reality, see if there are hills they’ll die on and consider if there’s a reason they’d rather lose a relationship than let you have that risk. |
| Walk me through a 2 a.m. production outage. | What emergency coverage actually means, who calls, how it’s activate, if there’s a codeword and who has to notice it first |
| What happens when the lead DBA leaves or the relationship isn’t working? | Whether context survives people |
| What happens to knowledge, access, and documentation if we leave? | Whether departure is operationally possible |
| How do you follow-up with me? How do I escalate? | Is there a path to talk to someone when you feel the values aren’t being lived out? Do they do regular independent surveys and follow-up rigorously on feedback? |
Can Straight Path have these problems?
Yeah. I’ve highlighted a couple specific areas above with asterisks, but absolutely we can and have. I could come up with examples for most of these where we’ve learned somewhere over the past ten years, or are still learning.
We’re humans running a service business. We have undersized engagements. We have had communication misses. I’ve picked the wrong hills to die on and learned. I’ve been over-protective of team members. We have had relationships where expectations weren’t aligned as cleanly as they should have been. We’re learning and growing, Clearly Rated has named us as Best In Service for IT Providers for the past two years and we build relationships that really last here, so it’s not all bad. But, yeah, there are a few I wish I could take back over the past ten years, and a few clients who I would have helped move on much much sooner because they weren’t a great fit.
We have also had the more ordinary failures: moments where we needed to explain something differently, where a lead relationship wasn’t clicking and we were slow to adjust, or where we didn’t surface a constraint early enough.
The interesting question is not whether a provider has ever experienced these failures. I’d be skeptical of anyone who’s been doing this for years and claims otherwise. The better questions are how they notice, how they course-correct, how clients can escalate, what happens when a lead relationship isn’t working, and what they actually learn when something goes wrong or a client leaves.
That is the conversation worth having.