In partnership with
In Tuesday's post, I tested the new local time zone support in Azure SQL Database. If you haven't read it yet, start there. It covers the possible benefits, the possible impacts, and a final recommendation that fits a lot of scenarios.
That post started with a conversation. A customer asked me about the possible impacts of this new feature. After the call, I kept thinking about other customers and other conversations I'm part of. Many of them have the same thing in common.
So today's tip isn't about time zones. It's about what to do when you choose a path the vendor doesn't recommend.
Not recommended isn't the same as forbidden
Every time you change a setting, adopt an architecture that isn't listed as recommended, or turn on a new feature, you need to know exactly what you're doing.
Vendors publish recommendations for a reason, and this isn't only Microsoft. Today those recommendations come from experience, real cases, and telemetry from a huge number of systems. They describe behavior someone has already seen.
So follow the recommendation. Yes, "it's recommended to follow the recommendation" sounds redundant. I say it that way on purpose. Most of the time, it's the right call.
But not recommended doesn't mean forbidden. Sometimes you'll have a good reason to do something else. Setting a database to local time instead of UTC is one example, and Tuesday's post showed when it can make sense. Those are the moments this tip is about.
How I answer "is this OK?"
On the database side, I get questions like this all the time. "I'm changing this setting from A to B. Is that OK?" "If I put this server here and connect it to that one, will it work?" "What do you think?"
When you work at Microsoft, or at any large company, you have to answer these carefully. I need to give the most correct answer for what the customer needs. And I can't contradict what we officially recommend.
I'm also honest with my customers. If I know of problems with what they want to do, I tell them. And I don't tell them what to do. I give recommendations (yes, that word again), and they make the decisions.
Those recommendations aren't vague. They're based on our official documentation, on real support cases, and on my own research with my team, our partners, and the product engineering team.
The answer usually ends in one of three places:
It's a hard requirement. The conversation stops there. I won't recommend something Microsoft says not to do.
There's a documented recommendation for a different way. I say so clearly in my report, with the link, and I make it clear that Microsoft's position is to recommend that way. The decision is theirs.
It's open. I do the research and the conversations, and I write in my report that I found nothing that would make me tell them not to do it. Then the customer decides.
The step I almost never see: write it down
There's one thing I recommend every single time, and I rarely see customers do it. I rarely hear anyone talk about it openly, either.
If you choose an option the vendor doesn't recommend, and it works, and nothing mandatory blocks it, document that decision inside your company:
When the analysis was done
Who took part, on your side and on the vendor's side, by name
Why you chose this way
What you gain from it
What could go wrong, if anything
Links to the documentation and reports you used
Why names? Because "I talked to one of your colleagues" doesn't help much. When I ask "Who?", the answer is often "I don't know." And I need the name. If a colleague of mine said something I don't agree with, I want to talk to that person. There may have been a good reason that I just don't know about.
On my side, I keep these reports archived, especially the ones that could be misunderstood later. That way I can help the customer again in the future if they need it.
And they often need it. Another department may question the decision. Someone new joins the company and asks why. A new leader arrives and wants to know who approved it.
Let's be honest. If your non-standard setup works beautifully, nobody will complain. But if something goes wrong, and you open a case, and it turns out this wasn't the recommended way, or it was clearly explained as a non-traditional one, things can get harder. The record is your precaution.
Free email without sacrificing your privacy
Gmail is free, but you pay with your data. Proton Mail is different.
We don’t scan your messages. We don’t sell your behavior. We don’t follow you across the internet.
Proton Mail gives you full-featured, private email without surveillance or creepy profiling. It’s email that respects your time, your attention, and your boundaries.
Email doesn’t have to cost your privacy.
Know why every non-default setting is there
The second habit comes from the same idea.
When I review a server and see a setting that isn't the default, I ask about it. "I see this setting is set to this value, and that's not the default. Do you know why it was changed? What was the goal?"
Here are answers I hear a lot:
"Honestly, I don't know."
"It was like that when we got here."
"Someone changed it, but they're not with the company anymore."
"What does that setting do again?"
Each one is an immediate red flag for me, especially for settings that can have side effects you don't want.
To be fair, not every setting deserves this attention. Many of them you can change from A to B to C and back again, and almost nothing happens. The ones that matter are the ones that can cause real trouble. Those are the ones I ask about.
This Friday's tip: two habits
1. Write a one-page decision record for every choice that goes against the recommendation. It doesn't need a special tool. A page in your team's wiki works. Here's a template you can copy, filled in with a made-up example based on Tuesday's post:
Decision: Set SalesDB to Central Standard Time instead of UTC
Date: 2026-10-20
People: (full names and companies, both sides)
Recommended: Keep UTC (link to the documentation)
What we chose and why:
The app was moved from a server that ran on local time,
and its reports expect local time.
Benefits: Existing reports keep working without code changes
Risks: Daylight saving hour, mixed UTC and local rows, BACPAC export
How we watch: Test DST dates in March and November; test every export
Review on: When the feature reaches general availability2. List your non-default settings, and make sure someone can explain each one. In Azure SQL Database, Azure SQL Managed Instance and SQL Server 2017 or later, this query lists the database scoped settings that were changed from their default:
SELECT name, value, value_for_secondary
FROM sys.database_scoped_configurations
WHERE is_value_default = 0;For each row, ask the same question I ask my customers: why was this changed? If nobody knows, find out, and write it down.
Your Friday homework
This applies far beyond databases. Any time you go against the advice of someone who has seen more cases than you, keep a record of why.
Pick one setting this week that isn't the default, and write three lines about it: who changed it, when, and why. If you can't, you just found your next conversation with the team.
Then reply to this email and tell me: have you ever found a setting nobody could explain? I read every reply.
If you know someone who inherited a system full of mysteries, forward this to them.
How I write: every post starts from my own notes and experience. I use AI tools to help draft and edit, and I review every word before it goes out.
Disclaimer: The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of Microsoft. The author is a Microsoft employee. All technical details and product behaviors described are based on publicly available Microsoft documentation as of October 2026 and are intended to provide a high-level overview for educational and architectural planning purposes.
