Asking Microsoft for support for SQL Server or Azure SQL is a lousy experience these days, whether you’re using a cheaper service tier or the more expensive support tier formerly known as “Premiere Support.” You need to know a lot about the root cause of your problem and how to solve it, or your request will be dismissed with misinformation. You’ll need data and metrics to back up your claims to get the ticket escalated, and you’ll need to provide those receipts multiple times. Once escalated to the Product Group, you may get a helpful response, but it takes a while. If the answer is relayed through a lower support tier, it often won’t make much sense.

These issues aren’t due to bad work ethics or personal failings of support workers. These are good humans trying their best. The problem is worse because it’s systemic.

A culture of guessing at answers

Support staff don’t seem equipped to learn about the products they support. There’s a culture of guessing at answers, which indicates they lack access to subject matter experts. They also have trouble accessing telemetry for hosted services. I suspect they can’t easily see previous messages or emails I’ve sent.

But you’ll still need help from Microsoft to report bugs or outages. The support experience is repetitive, time consuming, and frustrating. Here are my tips for making it through as efficiently as possible.

Start the ticket promptly, but immediately start researching on your own

You’ll have to be the expert here. Many support employees know just enough to be dangerously wrong.

With the cheaper support tier, you’ll need to persistently restate the exact product you’re using. You’ll get responses that only apply to a different SQL Server offering—queries that don’t run, answers from another universe.

With the more expensive tier, they understand what product you’re using, but knowledge about how it works is very limited. It’s like interacting with ChatGPT: you’ll get blocks of complex text that don’t hold up to scrutiny.

For example, if you report I/O errors in an Azure SQL Managed Instance error log, you might be told this is how General Purpose throttles storage and you need to pay for a more expensive tier. This could cost a lot, unless you understand that:

• You can prove I/O usage was well below limits using sys.server_resource_stats
• The error means exactly what it says: 15+ seconds of storage not responding, which is a storage subsystem failure
• This isn’t how I/O throttling works on the service

You might also be told that RECOMPILE hints cause PAGELATCH waits, that you need to be the only active user to shrink a file, or that if a query triggers stack dumps you should just stop running it.

Support quality has degraded significantly in recent years, partly due to Azure SQL products having similar names, multiple rebrands, and blended documentation. It’s hard to learn about these products without real-world experience, and I’ve never seen evidence that support staff get that opportunity.

You may need a consultant

If you don’t have someone on staff who understands SQL Server, it’s worth hiring a consultant to help manage the support process.

I realize this feels like it shouldn’t be necessary. Microsoft Support should be better. But I have little hope it will improve soon—Generative AI will have the same problems. Early versions of Gen AI Advice in the Azure Portal already recommend solutions for the wrong product, just like the cheapest support tier.

Working with someone who knows SQL Server may seem expensive, but so is SQL Server licensing and cloud costs. A good expert will help you call out bad advice from Microsoft Support, which often suggests throwing more money at licenses or Azure to spend the problem away.

I don’t think there’s nefarious intent from support staff—they’re doing their best with the documentation they have, which generally puts an overly optimistic spin on more expensive tiers. But that advice often isn’t in your best financial interest and won’t work. There’s a conflict of interest when your cloud provider also creates the software: organizational incentives are around profit margins, not helping customers find cost-effective solutions.

Keep all your research in a document

You’ll need to provide data repeatedly. Don’t fall into the trap of only entering data into the email thread—it gets long, and people miss information.

I keep a copy of all my research and data in a document so I can quickly restate it without going back through the thread. I imagine support staff can’t see anything I provided previously and work as if they’re in Memento or Groundhog Day. I can’t change the system, but I can make it easier to manage.

This also makes it easy to share with the team: the problem, data gathered, ticket status, workarounds evaluated, and what we need from support.

Save blurbs that block common brush-offs

Support folks work off scripts. You’ll quickly notice patterns: if you report unexpected downtime in Azure SQL Database or Managed Instance, you’ll get long paragraphs about how your application needs retry logic, suggested as a “solution.”

If you already have retry logic (like almost every application), save phrases you can use to head these off proactively or redirect back to the real problem. It’s not worth writing these each time—you get to work off scripts, too.

Frequently ask for escalation to the Product Group

If you aren’t getting a helpful answer, ask early and often for escalation. Depending on your support contract, there may be several levels needed. Folks in the Product Group know the product well and can diagnose problems. They can fix real bugs and give useful advice.

Sometimes you can’t find the right people. For example, I think nobody is home when it comes to the Change Tracking feature and its intermittent problems with synchronous Availability Groups at high load.

But most of the time, if I can get an issue escalated with the right supporting data, I get helpful information back. It just takes a while, and I need to do research and testing on my own, plus come up with workarounds.

Someone’s going to call at the end

Microsoft will call you at the end when you’ve reached some sort of acceptance about your issue, even if you’ve specified you prefer email. I’m guessing metrics show that talking to a human lessens frustration. They’ll ask how your support experience was.

Like all the support people involved, this will be a good human trying their best. But this whole system shows little signs of positive change.