Awhile back I wrote about how acquirers can maximize ROI with their SQL Server during due diligence. That post was about the deal and using some expertise to help before. This post is for some choices after the ink dries on your new acquisition.
There’s a pattern we’ve lived through many times at Straight Path. A client we’ve served for many years gets acquired. Sometimes they are folded into a larger holding company and the client is held forever, sometimes they are raided for their contracts and a few people, sometimes it’s a private equity group making a platform play maybe there’s a strategic benefit. In all cases, eventually – sometimes months – sometimes years – later new leadership comes in for the mandated expense review and contract review. Where can the cuts happen? Where can EBITDA be protected? And they usually find us… We don’t do cell-phone contracts, each quarter is renewed if it’s earned, and if it’s not – we don’t want to force a bad fit. That model really works and it helps us operate within our values even before we’ve sent an invoice. But here? The model can break. For us, sure, we’ll be fine and find new clients, but also for the company we’ve served for a long time. We’re the easy cut. No long term contract, we aren’t even that expensive, so how much value can we really be adding?
Cutting the niche database managed services provider is a pretty easy decision on paper. No severance, no HR talks, not even a contract to really unwind. Surprisingly, we wind up staying more often than not – and for many of those firms we’re still with them as a resource across their entire portfolio of clients because they get the value a team with breadth and depth in SQL Server, Cloud, Databases, Performance, etc that operates in a fractional model. Sometimes we get the cut. A couple of times we’ve gotten the cut and then called back in later…
I’m obviously a bit biased… I run a company that I founded with a team that has grown with me and stays with the company and I think we do a great job. But we also help sometimes with due diligence work FOR these acquirers and we’ve even helped some clients hire the right full-time DBA that replaces us when that is the best answer. So I want to talk about the case for and the case against keeping a company like us…
The Case Against Keeping DBA as a Service Team
There are real reasons to cut a service like ours. Below are a few and if any hit where you are – you probably should cut us or the company like ours.
You have a genuine shared services team with capacity and expertise
Some acquirers – especially the larger vertical software guys have built amazing central platform/database teams that serve their entire portfolio of companies. If that team exists, has senior SQL Server people on it (today SQL server is our platform, though we are in the midst of also becoming a Postgres team, more on that soon) and it can absorb another platform – you absolutely should consolidate that support. You have one standard operating book, one toolset, and you still get one throat to choke – but instead of it being mine it’s the leader of that team. I think the key emphasis here is on genuinely having that. If they are stretched across platforms in your portco, generalists and don’t have the bench of MVPs, authors, trainers, bloggers, etc that your partner has – it could become a case to keeping us around a bit.
The product is being managed down.
Business is business, and I hate to see a product team I loved to work with and build a relationship with have their product be the one chosen to be redundant to the software the new owners already had. But if the buy was for quieting a competitor or moving the MRR to the new product, it’s the decision. Some products get invested in, some get maintained, some get milked along towards sunset and migrations. If the plan for a product is slow wind-down, no new onboardings and sales and customer retention and experience matters a bit less – you may not need as much proactive database support. You don’t need the architectural advice and support, the tuning to keep the clients happy and leaving good reviews or the team catching the P1 before it happens. You still need to test your restores, keep your client’s data secure and stay out of the news with a breach headline – but you maybe can split the tasks among your team or have us wind down to just some hours to support and no actual monitoring and best practices ahead of the curve. We’ll sell you a bucket of hours to help you if you’d like but it makes sense to manage it less if you’re winding it down.
The workload justifies investing in a DBA team.
We tell folks before they sign with us – if you need 40 hours a week of DBA team, we’re too expensive. I have a post coming out in a couple of weeks that does all of that math – and it’s actually closer to 15 hours of consistent steady work – if you are looking at a numbers by the hour game only – we lose there. Sure I believe having one DBA is the same thing as having none and I blogged about that last week. Maybe it’s time to really invest if the work is not getting done and you need a DB developer or DBA there full time. We can help you transition that work to someone and even help you find and train that person. And if you get a team of DBAs who can cover you around the clock for emergencies, the case is closed – you don’t need us in there, and you can save that $20,000 – $72,000 a year you’d spend on us depending on the level.
You’re reducing vendor count for real risk reasons.
This one is a little trickier. We are in the midst of our SOC2 audit and it’s going well, should have our report in hand in a month. And we serve credit unions, banks, healthcare providers, insurance, governments, etc. I think the risk factor isn’t there with us, and we answer plenty of security questionnaires for vendors and haven’t failed one yet. That said – we’re your DBA team so we need certain access, we need certain tools in place, and if we can’t get that for a real risk reason or that’s just the policy from on high – then why pay for a service that you can’t fully utilize.
The Case for Keeping The Service
Your ARR sleeps in your database
Monthly recurring revenue is the lifeblood of the vertical SaaS company world. Your customers have a seemingly endless number of places to put their monthly fees and I could have sworn I wrote a blog post long ago about why Inertia was a terrible customer retention strategy – I can’t find the post or a draft so I’m not sure, I mentioned it in the M&A advice post at least. I still think it’s a poor strategy either way. Customers will leave eventually when that is the strategy. And the renewals go down, the EBITDA slips… Cutting the team who helps keep you in a proactive stance, teaches your team, tunes the environment, and stays ahead of the future corners and has been lobbying the existing team for upgrades and improvements for years is risky.
The math usually doesn’t math the way the report from finance suggests…
A single senior DBA with all-in costs runs somewhere around $190,000 – $220,000 (I just did some review for the post coming in a couple of weeks) or more once benefits, taxes, training,etc is added. And like I already said above, one is none – you have no coverage and if you don’t keep them interested – they’re gone. Not every company, though, always needs the full time DBA hands on keys, so a lot of that salary for many (not all) companies can become an expensive insurance policy. Our team is bringing our own monitoring tool, SQL Sentry, and a team of experts to be your DBA team. For a fraction of the cost – and for many companies at, say, our Gold level, we’re talking about $56,000 per year if they aren’t on an annual arrangement with a slight discount – even if you add in two emergencies and a migration with some overage – you’re easily under $75k for the year. And many clients who are in a niche SaaS industry are getting my with Silver ($40k a year) or Micro ($24k a year if bought by the quarter, $20k if bought by the year) with our team as their team. And all those monitoring tools are run by SaaS companies who want more MRR and longer deals, so we’re saving you from contracts with them since the tooling comes with us.
You’re gonna need that deep DBA bench at somepoint again
Assets get sold, even when the plan was to hold permanently – the economy shifts and stuff moves, merges happen later. When that day comes the new buyers are going to ask those questions about performance, security, compliance, why haven’t you upgraded? Prove out the RPO and RTO the SLA says you offer. Those questions are a lot easier when the DBA team is an extension of your team and, as our reviews suggest, operates like a part of your team. We make those questions get answered with ease and the proof is in the pudding usually.
The spend is already shaped like the way you probably operate
At least when Straight Path is your DBA as a Service provider. Probably most of our friendly competition also. Our model is pretty simple: a relationship based model priced quarterly, renewed quarterly if earned, no long-term exit clause in the contract and it can flex down when spend goes down and flex up when the needs are higher (saving you money from overage.) If integration means there are some aspects of service your central services/platform/DB team can deliver, we can reduce our costs and hours. If you bring in a multi-hat wearing person who can take on some of the work but still need us a backstop or mentor – we reduce and mentor. And you still always get a chance to exit us every 90 days as things change. This seems pretty aligned to a disciplined portfolio management strategy as any outside vendor relationship can get.
Five Questions to Answer Before You Cut the Line Item
- Who watched the databases at 2AM last month? Who was ready to swing in and fix the issue with a simple phone call and could fix it while the leadership team slept hopefully unaware? Who will watch it after the cut? How quickly will they solve it?
- What did the last unplanned outage cost? In dollars? In renewals? In reviews? Who fixed it? Who fixes the next one?
- If we move to the central team, how busy are they? How much attention does this new platform get? How expert are they at the specifics of this environment?
- Who will push us to make the right decisions based on working with hundreds of customers? Do we know enough about what we don’t know? Do we have the wisdom across a lot of clients to know why one decision isn’t as good as the other? Will the new folks be unbiased or will they prefer a certain direction because of their own incentives?
- What are we actually saving net of monitoring tools, on-call coverage, the hire we will need and the risk we’re asking to take on?
If the answers and the info above still push towards making the cut – then cut and any great managed services provider worth keeping in your contacts will do a clean knowledge transfer and leave that bridge in-tact and door open. We do every time because tech is small and the industry is small. The relationships often outlast the transactions and we get called in when someone moves on – and we’ve literally been called back when the big company management team switches out the leadership team again and they realize that the databases weren’t getting the love they needed.