In the first 90 days of a healthy DBA as a Service relationship, the provider should have a thorough understanding of your environment, establish reliable access and monitoring, identify and plan for your most serious risks, begin reducing recurring disasters, and settle into a working rhythm with clear priorities and communication.
By Day 90 you should feel less blind and less on your own with SQL Server. Our clients describe it as the ability to sleep at night without worrying about their SQL Servers. You’re onboarding with a vendor, but it shouldn’t feel like it.
This post talks about what a healthy first 90 days should look like and where things commonly get harder than the sales conversation implied so you can be aware of it, look to make your part smoother and call out where it feels off. This is part of our Buying DBA Services series of posts. Whether you buy from us or a friend in the business, we want you to be equipped as you make that selection.
Prefer to watch? I sat down with Evan, our COO and the person who oversees our onboarding process, to talk through what actually happens after a new DBA as a Service client signs, what tends to slow onboarding down, what happens when there’s already a fire, where we’ve gotten onboarding wrong, and what should feel different by Day 90.
Full Video Transcript
This transcript has been lightly edited with ChatGPT for readability. We left the conversation itself alone.
Mike: So hey, Evan. As you know, we’re doing a bunch of blog posts and videos about the journey of buying DBA services. One of the things I wanted to write about and talk about was what onboarding should look like.
I know that’s a loaded question because every onboarding looks different, but I spend a lot of time talking to our customers about what DBA as a Service is. You’re on those calls too. And then I sell them something, and you have to implement it and make it work.
Hopefully I’m not making your job too difficult. You’re on the calls, so you can catch me if I’m saying something I shouldn’t be saying. But who better to talk to about what onboarding should look like than you? As our operations officer, you’re like the chief onboarding person too, for lack of a better title. You know what it looks like.
So happy to talk to you. You’re here voluntarily and willingly, right?
Evan: That’s right.
Mike: Perfect. Good.
I just want to ask maybe six questions and run through them. Maybe I’ll ask questions as follow-ups if something comes up, but we’ll see where it goes.
Let’s just pretend I signed a new DBA as a Service client. Actually, we did just sign one. We signed a contract today.
What happens now? What’s happening for that client? Don’t say their name, obviously, but what’s going on with them?
Evan: As soon as they sign, our office administrator, Sheila, starts moving extremely quickly to get them assigned a Lead DBA. She works with you and me on that because once we’ve determined who the Lead DBA is, really the next thing that happens for the customer is the kickoff call.
We also send over their onboarding document. That’s a set of information that tells them a little bit about how we work. It tells them about the different things we’re going to be doing, like installing our tools in their environment and collecting data from their servers so we can assess them.
It also gives them an opportunity to provide us with information that helps us move forward more quickly with the onboarding. That might be the primary contacts we should communicate with for things like building a VM for us to install our tools on, or who the decision-maker is if we see something we really need to call out right away.
We also get information about the group of people we’ll be working with. Maybe there’s a distribution list we can send our daily health check reports to. Or if we’re responding to an alert, we can send an email there and know they’re going to get it as a team and be able to jump on it as quickly as possible.
The kickoff call getting scheduled is the most critical thing as soon as they sign. Once that happens, they’ve been given the opportunity to ask questions. They’ve heard from us about how we operate, and they’ve also given us an idea of what they feel success would look like in the first 90 days.
If we’re onboarding a new client, we might have an idea in our mind of what we think should be done in the first 90 days. But if the client has a different idea in their head and we don’t speak that expectation, or they don’t have the opportunity to, we might knock it out of the park in our minds with the onboarding but miss a critical piece.
Maybe they had a SQL Server we didn’t discuss right away for whatever reason. Although if it’s causing them pain, we probably did.
But maybe they just had an expectation we didn’t draw out of them during that onboarding phase. We think we’ve had a successful onboarding, but they were left a little disappointed because we missed something, whether it was communicated or not.
So the kickoff call is really important for us to understand what success should actually look like, so we can look back after 90 days and know it was a successful onboarding.
The kickoff call and the onboarding document are the two things that happen.
Mike: And the kickoff call is where they meet the Lead DBA we’ve assigned, right?
Evan: Correct. Yep. The Lead DBA gets the opportunity to ask questions about their environment, their team, their pain points, so they can start building a relationship with them that hopefully is going to last for a really long time and be really productive.
Mike: Perfect. What do you think slows onboarding down the most? I already know the answer to this question probably, but I’m curious what you say.
Evan: I think we’ve blogged about it before and probably always will, but it’s access.
We’re being given privileged access to critical environments. Especially in cases where there isn’t an immediate need, there’s going to be some red tape around getting that access provisioned.
As you know, a customer who’s in pain because of their environment…
Mike: Throws the keys to everything.
Evan: Things just open up a little bit more quickly for the people who can fix the pain.
But especially if it’s an environment where it’s more proactive of them to reach out to us for help, the red tape around getting that access provisioned is usually the biggest challenge.
We harp on that. Even before our kickoff meeting or the onboarding document gets sent along, we really try to help them understand what we need and how important it is to get it for us.
Inevitably, maybe once or twice a year, we bring in a customer where they seem to understand the access piece, but it’s different than we expected and it still drags along.
Mike: We’re getting better at it, though. We send a security questionnaire ahead of time to many clients where we can tell it’s going to be access or firewall connection problems and all that.
Evan: Exactly. Sometimes we know when it’s going to drag along and we do our best to prevent that.
But that’s the biggest thing that slows it down because until we can get in there and start solving problems, discovering problems, and installing our monitoring, we’re blind to the environment and our hands are tied behind our back.
Even if we know something is wrong through a screen share, email communication, or a phone call, we really can’t do a whole lot. So it’s definitely the access.
Mike: Okay. This is a loaded question because it really differs, and maybe you can talk about the “two trains on the tracks” thing that I always tell people on our calls.
What are we really trying to accomplish in the first, say, 30 or maybe 60 days of the relationship?
Evan: On our side, we’re trying to understand their environment, and we’re trying to solve any problems that, as you always say, you can’t go to sleep at night knowing about.
On their side, we want them to be confident in the first 90 days that there’s nothing in their environment they don’t know about. There are no skeletons in the closet that haven’t been discovered, and we have our monitoring going.
A big part of that is getting our daily health check report process going with our support team. Then they’re hearing from us every day, and they can check their email first thing in the morning and understand whether there’s anything they really need to worry about on the SQL side that day.
Building the confidence and trust between us and the customer is the number one thing. That comes through communication. It comes through our monitoring. It comes through the questions we’re asking them.
So building the confidence is really important.
Then number two is resolving any of the immediate pains they came to us because of. Sometimes that’s really acute, and it’s something we address within the first week because it’s so important to them and causing them so many issues.
Or maybe it’s just their top priority. It isn’t hurting them badly at the moment, but it’s their top priority, and we really want to drive forward and solve that within the first 90 days if we can.
Mike: Or we see they have no backups and they didn’t know it.
I still get surprised when I see that. Do you get surprised? I probably shouldn’t be.
Do you get surprised when you do an onboarding and see, “Oh, you haven’t had backups in years,” or the backups you thought you were taking aren’t?
Evan: Yeah, I do.
I get more surprised as AI becomes more prevalent in everyone’s workflow because even when we come into companies that don’t have a dedicated DBA, or they have somebody who’s the dedicated DBA by attrition, they’re just assigned to that role because…
Mike: They can spell SQL, I always say on the sales calls.
Evan: They’re the sysadmin. They can spell SQL.
And as AI becomes more prevalent, it’s one prompt you’d need to write that says, “Hey, I just got saddled with the responsibility of taking care of our company’s SQL Servers. What are the main things I need to worry about?”
It gets more surprising over time because that prompt would be really simple to write. But whether it’s busyness or just a lack of awareness, it’s still a thing.
We still come into environments that don’t have backups.
The other big one is integrity checks. We run into that all the time, maybe more than backups.
Mike: Oh yeah, a lot more.
Evan: Those are just foundational pieces of managing a SQL Server environment.
Mike: Or the too-many-backups problem with Veeam and all.
Evan: Yeah. We have conflicts in the backup chain, and ultimately it comes down to not having a restore strategy.
People have a backup strategy, but maybe they don’t have a restore strategy. Backups are one piece, but can you actually recover using them?
Those are big questions we hope to solve within the first 90 days too.
Mike: And I know this almost never happens, so you can tell me sarcastically: What happens when we find a client on fire in the first 30 days?
I should just say it almost always happens because people don’t call us very often and say, “Hey, I don’t know if we’re good or bad, but can you just come and be our DBA team because we realize we should have one?”
They normally have something going on.
So talk about the two trains on the tracks and what we do with that. Because we care about the basics, but they care about their application not working and their website timing out.
Evan: Right. The two trains on the tracks is a good way of putting it because we don’t want to slow down the first train.
The first train is the onboarding. It’s getting our monitoring tools in place. It’s doing a deep-dive assessment of at least a handful of their SQL Servers to get an idea of what’s going on.
That’s not always the immediate pain. That’s base configurations, backups, integrity checks. Those are the standard items we want to look for in any environment.
We want to make sure we’re discovering those things on that first track during onboarding, and we don’t want to slow it down because something else came up.
So when something else does come up, which it almost always does, we throw a second train on the tracks.
The best way I’ve found to handle that is to segregate responsibilities a little bit. Our support team does a great job with the onboardings, and I still help out with that as well to take some of the load off the support team.
But if we discover something serious, like a client in the real estate industry that we brought on recently, they had serious performance issues. They had applications going down frequently that were tied to SQL Server.
We kept that onboarding track going, but we brought in their Lead DBA. You jumped into the fray a little bit. We were solving those problems simultaneously with a separate communication cadence so we could keep the onboarding moving while also solving that immediate problem.
Mike: Technically speaking, their onboarding isn’t even supposed to start until October 1st.
Evan: Yeah. They haven’t even technically started their onboarding.
Although with a client like that, and really any client when we have the bandwidth, we start the onboarding as soon as they’ve signed because that gives us maybe even more than 90 days to hit that target of making them feel comfortable and building confidence in us in the first 90 days.
The two trains on the tracks has been a great tool for us because it shows the client we’re not going to force them to go through this standard, rigid onboarding process before we can actually start solving the problems hurting them today.
But it also allows us to accomplish those foundational things that make for a good relationship, give us eyes on their environment, and provide all the other pieces that come with DBA as a Service.
So we can solve the immediate fire and make them feel better right away, but also build confidence that we’re going to take great care of their whole environment and not just the one SQL Server causing the pain today or this week.
Mike: Is there a moment when a relationship feels like it’s no longer onboarding and they’re now a part of our team?
Our clients stay with us, knock on bald guy’s head, as I always say, for a long time. But when does it feel like we’re their partner and not just their onboarding strangers?
Evan: It depends. The DBA answer.
If we have a client that comes in with their hair on fire and we’re able to solve that, we burn the midnight oil with their team. We’re having those conversations that happen at 2:00 AM on a Teams call while you’re solving a high-priority problem.
That can happen really quickly.
You can build those relationships in the trenches and have a partnership with a customer within a week. If you come in and you’re a key piece of solving something essentially grinding their business to a halt, it can happen right away.
In a more normal onboarding where that doesn’t happen, I think it’s after our initial assessments have been completed, we’ve delivered them in a meeting with the key people at the customer, and the recommendations we’ve made have been implemented.
Once that has happened and our monitoring is in place, they’re hearing from us daily. They know their environment isn’t on fire, and they’re seeing improvement from the changes we’ve recommended with our initial assessments.
Then we start to shift our focus to how we can help them move forward down the road.
What’s coming up? Are we going to start upgrading to a newer version of SQL Server? Do you have a migration project that’s going to help you consolidate and save money?
Those are more proactive things that a lot of times a client comes in not having the bandwidth to think about.
As soon as we’ve made it so they’re very comfortable with where their environment is, there aren’t things breaking all the time, and we’ve delivered those assessments and implemented those recommendations, sometimes that’s as soon as the second monthly check-in. So that could be halfway through, or maybe two months into, their first quarter.
Sometimes it’s a little longer because enough things turn up during the health check process that it might take a quarter to get them all implemented. Some of those changes aren’t easy.
Mike: Especially…
Evan: Especially if you have a really busy environment and it’s difficult to get a maintenance window.
On average, I’d say it happens by the end of the first quarter because we’ve had a chance to meet with them quite a few times. We’ve reviewed their environment, made sure they’re aware of everything that might need to be changed, and they’ve started getting into a regular cadence of communicating with our team and working with us to solve problems.
They trust us by the end of that first quarter, usually. That is the goal.
So I’d say by the end of the first quarter is when that starts to happen.
Mike: That goes into my last question, I think, anyway.
By Day 90, what should feel different for the client? Obviously the relationship is there, but what else do we expect to be different for that client after 90 days that wasn’t true at the beginning?
Evan: It’s the confidence.
It’s the confidence, and I think for many clients it’s having the bandwidth to worry about other parts of their job that maybe they were having to disregard because SQL was on fire.
Or maybe it’s having the bandwidth to think about the future of SQL Server. How are we going to upgrade? How are we going to consolidate? Whatever their goals are, they now have the freedom to think about that because the day-to-day anxiety of whether things are okay is on us.
We’ve hopefully proven they don’t have to worry about that because if something is wrong, we’re going to let them know within 15 minutes and we’re going to be on it.
So confidence is what changes in the first 90 days.
For many clients, that’s a tangible thing because there are a lot of clients that come to us where one of the first things we hear is that their DBAs are spending a bunch of time overnight and on weekends checking on things because maybe they have processes that are so bad and slow that they have to be monitored almost 24/7, and they’re doing that manually.
If we’re able to allow a client’s DBA to sleep, that’s super impactful.
It feels great to make that kind of difference. And the sleep is ultimately coming from the confidence that their environment is taken care of.
So again, it’s the confidence piece.
Mike: That makes sense.
Let me ask a bonus question. We’re trying to be transparent with all these. I have the post talking about the ways it can go wrong and the ways I’ve messed it up.
When you think about onboardings, what are lessons we’ve learned? Or lessons you wish maybe I still had to learn?
Here’s your chance to give me a complaint about something. Maybe it’s something I promised a client in the past that we stopped doing. Maybe it’s the access thing.
Where have we gotten it wrong, and what have we done about it? Or are we still getting it wrong anywhere?
Evan: I think a lot of the time in the past, it’s been not effectively putting those multiple trains on the tracks when we’ve needed to.
You and I both have this desire to understand what a client’s problems are and help solve them. So when a client comes to us with immediate pain, whether we’re in the sales process or early in onboarding, we’re naturally going to gravitate toward solving that.
I’ve been doing operations here for a handful of years. I don’t know how long. But while I’ve been involved in the onboarding process, our documentation and our process mindset have always been evolving.
Especially early on, we would get hyper-focused on those immediate problems.
Mike: The fun things.
Evan: Yeah.
And that would mean the boring part of onboarding, that first track, wasn’t moving the way it needed to.
Maybe we solve the fire and realize we’re a month and a half into onboarding, but we don’t have our assessments done. Or our monitoring tools still have roadblocks that need to be cleared so we can really watch the whole environment.
Those basics could get skipped or delayed because, for lack of a better term, we got distracted by the thing that was on fire.
That’s one of the things I think we’re still prone to if we’re not careful. But we’ve made a lot of effort toward making sure we protect the basic part of onboarding even while those other things are going on.
Ultimately, the main way we can fail in an onboarding is communication.
If a client has expectations we’ve given them that we don’t meet, or expectations that just weren’t discussed, that’s a communication issue. That’s the number one way I think any relationship can get off on the wrong foot or sour over time.
Mike: Any kind of relationship, yeah.
Evan: Yeah. So communication is the big one.
Then just delivering on what we’ve promised is the other big thing.
If we promise we’re going to get eyes on the environment and have our daily health checks going, and then that doesn’t happen, even if it was for noble reasons, that’s the biggest reason we could fail or not meet what we strive to meet as far as an onboarding being successful.
Mike: Yeah, that’s right.
And that’s why we try to limit ourselves to two or three onboardings at most per month.
It happens that we have three onboardings right now, but that’s our max for October, and all of them started some earlier version of the process.
But the fourth one, I promise you, I’d say no to. I’d push it into November because we can only put so many trains on the tracks. We have the other 130 customers we support and have to keep doing that work, so we don’t want anything to get lost.
Evan: Yeah, absolutely.
Mike: And I think in the past, maybe in the early days, I said yes a lot more to clients too, even when they weren’t great fits.
Evan: Yeah. As we’ve grown, it’s always been an effort to make sure the structure is there to support all the different things we’re trying to do for a customer.
Mike: Cool. Anything else you want to add about onboardings or what the first 90 days should look like?
Evan: I think if you’re a customer and you’re looking for a DBA as a Service provider, being able to define what it is you hope to get out of the relationship is really helpful.
If you’re going to work with a good DBA as a Service provider, it could be us, it could be any number of other ones, being able to define what you hope to get and your expectations from the relationship gives your provider a target to shoot for.
Anybody worth their salt is going to do their absolute utmost to meet that.
So if you’re able to clearly define it, you’re setting yourself and the DBA as a Service provider up for success.
That’s the only thing I’d add.
Mike: Perfect. I love it.
Well, thanks for your time. You should probably get back. Sheila literally sent us a bunch of messages about that new client onboarding.
Evan: Yeah, I’ve got a bunch of onboarding to work on.
Mike: So you’ve got to do some onboarding work now.
Thanks, Evan.
Evan: Yeah, absolutely.
Define What Success Looks Like Before You Start
This is something pretty important and it should be part of your kick-off call. Evan got to this in the video and I wanted to add it to the post. Whether you work with us or another provider:
You should tell your DBA provider what success looks like to you.
That sounds obvious, but it’s easy to skip. Your provider may have a perfectly good 90-day onboarding checklist. They may get monitoring installed, review your backups, find configuration problems, check integrity, document the environment, and feel like they knocked the onboarding out of the park.
Meanwhile, you’re wondering why nobody fixed the performance problem that caused you to hire them in the first place.
That’s a failed onboarding, even if every box on the provider’s checklist is green.
Before you start, I’d make sure both sides can answer this question:
“Ninety days from now, what needs to be different for us to consider this relationship a success?”
The answer might be fewer outages. It might be getting your DBA out of the 2 AM alert business. It might be knowing whether your backups can actually be restored. It might be getting a specific performance problem under control. Or it might simply be understanding the risks you don’t know about today.
The provider should have an onboarding process. But your definition of success needs to be part of it.
What happens immediately after signing?
Onboarding with us doesn’t always wait for the official start date.
After signing, a provider typically sends welcome and contact information, schedules a kickoff meeting, provides onboarding documentation and forms for you to use for access. They begin identifying key contacts, and usually start access work as soon as you are ready. In many cases the client can already reach the team for advice or issues, and monitoring or health-check work can begin as soon as usable access exists even if it’s a bit ahead of the “official start date.”
At Straight Path, we like to start each DBA as a Service retainer on the first of a month and we limit ourselves to two to three active onboardings per month, so no one falls behind.
Signing on August 15 for a September 1 start does not automatically mean everyone sits idle until September 1. Many providers (including us) would rather begin solving access and visibility earlier and effectively give the first quarter a little extra runway than spend the first several weeks of the official engagement still blind.
What access does a Remote DBA team need?
A DBA team needs sufficient access to actually perform DBA work. That commonly includes remote connectivity, appropriate SQL Server permissions (SA access is really necessary to truly effectively be your DBA team. We can use a PAM tool and have non-admin and admin accounts, but it’s just necessary to succeed.) Jump-servers need to be setup for many providers, including us, and coordination around MFA/PAM/VPN needs to happen. Firewall internal and external connectivity for monitoring needs to be solid.
Effective working access is one of the biggest variables in onboarding speed.
How customers can make this easier
- Identify who owns VPN and security access before kickoff
- Test credentials before sending them
- Document VPN, MFA, and PAM procedures
- Determine who can grant SQL-level access
- Bring the MSP, network, or security team into the process early when needed
- Know who actually owns administrative access to vendor-managed systems
A real-world pattern worth noting: some organizations discover during onboarding that they do not actually possess the level of SQL Server access they thought they did, especially around vendor-managed applications. We’ve seen this happen at Credit Unions and a couple radiology practices that have “over-protective” vendors. That discovery itself can surface risk.
How us providers can make this easier
- Provide options for shared access and use a SOC/HIPAA/PCI compliant tool that a client can use as an option with logging, MFA and controls already
- Document your needs ahead of time and get that to the clients before a sales decision is made
- Provide a secure portal to share information consistently
- Suggest an access kick off meeting – sort of a pre-kick off kickoff meeting where the access is squared away.
- Ask the provider to test the access first, remind them that onboarding eats into billable hours and we want to use those hours to make a difference.
Days 1–30: Stop being blind
The primary job in the first month is visibility. Visibility for the Remote DBA provider and with their tools, hopefully much more visibility for you and your support teams.
Clients often hire a DBA provider because of a problem that is seen by all and obvious to the business… Performance, migration, upgrade, recurring outages, a recent ransomware, a failed compliance or regulatory exam, capacity, or technical debt. Those matter. But before spending the bulk of the engagement tuning a query, the provider should understand whether the environment is fundamentally recoverable and safe enough to work on. I always call that, “the things that we can’t sleep at night knowing you have wrong.”
Initial work should look for high-risk issues such as missing or broken backups, including the ever-present “rogue backup” we find with sp_CheckBackup, restore/recoverability problems, corruption, missing integrity checks, serious configuration issues, broken maintenance, capacity or storage threats, obvious HA/DR risk, and dangerous preexisting conditions (Yes I mean it’s not normal to get a stack dump and failover every day when change tracking cleans up with the busier afternoon cleanup…)
Two trains on the tracks
Sometimes we have to do what I call “putting two trains on the tracks” in sales and onboarding calls… We have a team for a reason and we can multi-task even for one client.
One train deals with the scary things capable of causing data loss, outages, or serious business risk. The other deals with the reason the client originally called.
A good provider should not refuse to touch the performance problem until a 97-point checklist is complete. It also should not spend 30 hours tuning queries while nobody notices the database has not had a valid backup in six weeks. It’s balancing those that makes a difference. The best tuned database doesn’t matter when Murphy swings by and breaks it all hard because we all agreed to save that “boring” stuff for later.
When should monitoring be installed? Ideally very early, even before the official start date is what we strive for when the access is good and we sign early enough. Installing monitoring is not the same thing as managing the environment, though. Once data starts flowing, someone still has to review it, understand what matters, tune noise, escalate real risk, learn what is normal for this environment, and prevent recurring alerts from becoming “the one we ignore.” That first month we are titrating alerts, negotiating on which errors are really “acceptable”, fixing maintenance, and trying to make the daily checks more green and make your server become a happier, quieter server in our dashboards.
What happens if something dangerous is found immediately? There is no true catch-all answer. Every company has different change-management expectations. Some say “just fix it.” Even then, a good provider will explain what was found, why it matters, and what is about to change. Anything requiring downtime needs an approved plan or window. If something is truly dangerous and the client is not responding, escalation may move from tickets to emails to phone calls to increasingly more direct communication. Part of onboarding is learning how your company makes technical decisions and approves change.
How are priorities decided? A useful model is the one I talked about in the health check blog post last month: Finding → Risk → Priority → Owner → Action. In practice the provider and client has their own priorities, but a provider also is coming at this from being burned a LOT. Corruption, for example, is rare for most folks – but a SQL Server consultancy sees it all the time and gets those phone calls where the answer is “sorry we can’t do anything, you should have called us last week.” The provider may be most concerned about recoverability; the client may be most concerned about the performance issue users feel every afternoon. Both matter. Sometimes work can proceed in parallel. Sometimes available hours or severity mean lower-priority work genuinely has to wait.
How many DBA hours does onboarding consume? It varies substantially. For many engagements it falls in the 5–10 hour range, but access problems, security processes, multiple teams approving the various accounts and VPNs and firewalls, poorly documented VPN/PAM systems, vendors with SA access approving access, and unavailable customer resources can stretch it.
Sometimes the right answer for us is to delay the formal onboarding date rather than burn a client’s paid DBA hours fighting an access problem they are not yet ready to solve.
What should be different by Day 30? Green everywhere is not the test. But the big risks absolutely should be calming down.
By approximately Day 30, monitoring and daily reporting should be flowing, major access issues should largely be resolved, the primary relationship should be established, the scariest findings should be decreasing, backup and recoverability gaps should be understood and being addressed or, frankly, solved where the provider can just fix it, missing maintenance should be improving, and overall stability should be moving in the right direction. A terrible environment may still have plenty of red. It should simply be safer than Day 1.
How disruptive is onboarding to your team? There is some disruption. Someone (or 3 teams) on your side will need to help with access, answer environment questions, and participate in prioritization. We’ll send inventory documents that your team needs to fill out identifying owners and purposes of servers. The better providers keep that load as reasonable as possible, but it is not zero. It does go down with time once we are onboarded. We do a check-in call at least monthly and the more folks impacted by the SQL Servers and who impact it that show up, the better. Though we find it a lot easier with one owner on the client side ultimately responsible for the final answer and direction.
What if a major incident happens in week 3? A provider that has already established access and started the process of learning the environment should be able to respond without starting from zero. The response will still be constrained by the access, change control, and vendor relationships that exist at that moment, but that’s why you hired us – and the DBA life is a fun life with new challenges and problems – a good team is jumping in and helping, but success may not come as quickly as it would have on day 67.
Days 30–60: Stabilize and begin solving the original problem
The second month should start moving forward in a more steady way.
You are still remediating findings, reducing scary risks, cleaning up remaining access issues, tuning alerts, and challenging recurring “acceptable” errors. The support team has stabilized much of the environment, best practices are becoming the norm, the most critical servers are good, the other ones are getting the checks. The Lead DBA is meeting at least monthly and the performance, migrations, upgrades, architecture, technical debt, or projects you brought the DBA as a Service team in for are being addressed and planned.
This is the transition from pure onboarding and discovery toward normal managed DBA work and a DBA relationship.
When does the Lead DBA actually know your environment? There is no magic date. Context begins accumulating immediately through sales notes, kickoff, onboarding data, and early tickets. “Knowing the environment” does not mean memorizing every database name. It means understanding the applications, business priorities, unusual vendor requirements, maintenance windows, decision-makers, recurring issues, known landmines, architecture, what absolutely cannot go down, and what the client is trying to accomplish.
You should not have to reintroduce your company every time you open a ticket and the consistency from the lead DBA being involved and meeting regularly really helps that. And the full team is made aware of what is going on with the clients because we let our team take vacations.
What happens if the plan is clearly undersized once the real backlog is visible? This can happen. At Straight Path we often talk about that risk in sales calls where we have our discussions about managed DBA services pricing. A good provider raises that potential directly instead of waiting for the “Oh crap” moment. Options usually include adjusting the plan, extending the timeline, or accepting that some items will remain lower priority. It should depend on the needs and budget of the client – and that’s why we used to call our service “FlexDBA” – clients can still flex up or down when the needs dictate.
Days 60–90: Heading towards a normal rhythm
By the third month you are learning what the real ongoing relationship looks like. You should have met with your main contact at least a few times towards the end of that 90 days.
Initial firefighting should be declining. There is actual evidence of how many hours the environment consumes, what recurring responsibilities exist, what projects are coming, how much technical debt remains, and whether the current service level is properly sized.
This is the natural point to ask what success looks like three, six, and twelve months out, and whether the service level still makes sense for the next quarter. And at Straight Path that’s what we do – we want to plan for the future with you. “Where do you want to be in a year?” is something we should know by the end of the first quarter and a plan should be formed that helps get there. Titrated to the budget and your competing priorities and the time we need.
What can make the first 90 days go badly
Common failure patterns:
- Access is not ready. Credentials untested, no clear owner, security teams not aligned
- Nobody can approve anything. Risk is found but remediation cannot be authorized
- Prolonged email tennis between provider, MSP, sysadmin, and security. When that happens, stop emailing and get the right people into a meeting
- Fun with Software Vendors. An application vendor complicates ownership and no one is sure where vendor responsibility ends
- Expectations were never set and aligned.
- The client expects the provider to “take everything over tomorrow”. That is fine but we need the access yesterday for that to happen
- The plan is undersized relative to the real backlog. This is a real risk, it’s why often in sales calls when we price per hour – I’ll suggest a lot of clients move to Gold or Diamond the first quarter and give them a one time rollover of all unused hours one quarter – 45 hours with Gold saves the client about $1,500 over 45 hours with Silver and overage.
What you should expect by Day 90
From a healthy DBA as a Service relationship by Day 90:
- The provider understands the environment at a useful level
- Access is established
- Monitoring is producing useful information
- Serious risks are known and being addressed
- Urgent problems are less frequent
- Priorities are understood
- Communication has a workable rhythm
- There is a forward plan
- You know who to call; they know who you are
- The relationship no longer feels new
They should begin to feel like part of your team rather than a vendor or ticket queue. If you’ve ever watched a pet cat or dog go to sleep, you know that deep sigh they do right before they fall asleep? Content, happy, calm? You should be able to do that (for a brief moment, before you wake up and remember we’re only there for your database world. Sorry…)
How transparent should the provider be about remaining risk at Day 90? Very. A useful conversation includes what is improved, what is still outstanding, what is deferred and why, and where residual risk remains. “Everything is fine” is rarely accurate. Honesty and transparency go a long way to a long-term relationship. You should know the risks that still exist and the plan around them.
What this looks like at Straight Path
The expectations above are what any healthy DBA as a Service relationship should produce. How individual providers deliver them varies.
At Straight Path the model includes a named Lead DBA, support from the broader team, structured daily review processes, and deliberate attention to relationship continuity and internal accountability so context does not live in only one person’s head.
This is not the only valid way to deliver the service. It is how we have chosen to do it.
Closing
The first 90 days should not be measured by whether every health-check item has turned green.
Measure whether you are less blind. Measure whether the most dangerous things are becoming less dangerous. Measure whether recurring problems are starting to disappear. Measure whether the DBA team understands what actually matters to your business. And measure whether you are beginning to spend less time worrying about SQL Server and can sleep even just a bit better.
By Day 90 you should not feel like you are still onboarding a vendor. You should feel like you have added a DBA team to your existing team. You should feel confident in the health of your database estate. Otherwise you just onboarded one more thing to worry about.