I repeated a wrong cost premise all day until I read the contract (SPLA vs Software Assurance)

I spent most of a day building a cloud-migration brief whose entire headline was “we save a significant amount per month if our Windows and SQL licenses have Software Assurance.” It went into the brief, the email to the hosting vendor, and the one-page overview. Then I opened the actual 2022 hosting contract and found out we can’t have Software Assurance on those licenses at all. The premise wasn’t risky. It was already dead in a document I’d had the whole time.

This is a post about how a plausible idea, repeated across three artifacts, starts to feel like a fact. And how a five-minute read of the primary source killed it.

The setup

My brother had an upcoming call with our hosting provider plus the regular staff meeting. He needed two things from me: an infrastructure overview brief, and an email to the vendor. The brief’s swing factor, the one number that would decide whether a cloud move even made sense, hinged on a single question I’d queued up for the vendor: “Do our Windows and SQL Server licenses have active Software Assurance?”

That question carries a lot. If you own Windows/SQL licenses with active Software Assurance, you get License Mobility, which lets you bring those licenses to Azure or AWS and avoid paying for them again in the cloud. That’s the classic BYOL-with-SA savings path. So “do we have SA” looked like the unlock. The whole comparison bent around it.

I built the brief on that frame. I drafted the email asking the vendor to confirm SA status. I wrote the overview the same way. Three documents, one premise, repeated until it sounded settled.

The contract read that broke it

Before sending, I pulled up the 2022 hosting contract to grab the exact license line so the email could be specific. And the contract didn’t say what I’d been assuming. It said something that made the whole question moot.

There was no separate license line. None. The SQL Server line item showed the SQL Server license bundled into the server fee. That bundling is the tell. When a hosting provider rents you a SQL license folded into the monthly hosting charge, that’s SPLA, the Services Provider License Agreement. Under SPLA the provider holds the licenses, you rent them month to month, and nothing is portable. You don’t own anything to bring anywhere.

And here’s the part that retroactively flattened my whole brief: SPLA licenses are explicitly not Software-Assurance-eligible. SA is a benefit you attach to licenses you own through a volume agreement. You cannot bolt it onto a license you’re renting through a provider’s SPLA. So not only did we not have Software Assurance, we structurally couldn’t have it on these licenses. There was no question to ask the vendor. Asking it would have just signaled that we didn’t understand our own contract.

The supposed unlock didn’t exist. It had never existed. And I’d repeated it across three documents like it was the fulcrum of the whole decision.

The comparison the license question was never part of

Once SPLA killed the SA framing, I had to redo the actual math. The useful thing is that the real comparison didn’t need the license question at all. It was independent the whole time.

• Incumbent dedicated refresh: a fixed monthly rate on a multi-year term.
• Azure with Azure SQL Managed Instance (license-included, so no SA required): materially lower on a 3-year reserved commit vs. pay-as-you-go.
• AWS RDS for SQL Server: similar range on the same 3-year basis.

The viable move was Azure Managed SQL, landing real savings against the incumbent refresh. Still a significant number. But notice what’s missing from that calculation: any dependency on whether we own licenses with Software Assurance. The license-included cloud options price the SQL license into the managed service. The savings were always going to come from moving off dedicated metal into managed SQL, not from porting licenses we’d misread as portable.

The original “we save if we have SA” headline wasn’t just wrong about a fact. It was wrong about which fact mattered. The decision never turned on Software Assurance. It turned on dedicated-versus-managed, and that comparison was answerable without asking the vendor anything.

Correcting it everywhere, not just where I first said it

When you propagate a wrong premise across three artifacts, fixing one of them isn’t fixing it. The brief, the email, and the overview each carried the SA framing, so each needed the correction.

The “do we have SA” question came off the email entirely. It wasn’t a question anymore, it was a mistake. The brief and overview got the SPLA reality written in, so the next person who reads them understands why the license question is closed rather than open. The commit that captured the day’s work bundled the SPLA correction in alongside the email rewrite. I tracked the surrounding cost work as its own tickets too, an incumbent refresh quote and the Azure/AWS quotes, so the numbers live somewhere durable instead of just inside a brief that’ll get stale.

There’s a second, very human story riding along with this one, and it’s worth telling because it’s the same lesson from the other side. My brother refused to send my original email. Not because the SA math was wrong, he didn’t catch that, but because it was too technical. It was full of phrases like DDoS scrubbing, upstream null-routing, and Software Assurance, words a non-technical person can’t actually say to a vendor without feeling like they’re reading a script someone handed them. So I rewrote it in plain language he’d genuinely send. The before-and-after on that email was its own little reminder: the artifact has to survive contact with the person who actually uses it. A brief that’s technically correct but unsendable is no more shipped than one built on a wrong premise.

The takeaway

A plausible premise repeated across three documents is still a guess. Repetition feels like corroboration, but all three documents inherited the same unchecked assumption from me. Saying a thing three times doesn’t make it three pieces of evidence. It makes it one guess, copied.

The cost question here was never “do we have Software Assurance.” It was answerable in a contract I already had open access to, in a single bundled line item that told me, if I’d read it first, that the SA path was closed before I ever built anything on top of it. SPLA versus owned-with-SA is a five-minute read. I spent a day not taking it.

So: read the primary source before you build the brief on top of it. Not after, when the framing has already calcified across every artifact and you have to go back and tear the assumption out of three places. The contract is the ground truth. The brief is a story you’re telling about the contract. Make sure the story is checking the contract and not the other way around.

And when you do find you’ve propagated a wrong premise, correct it everywhere it landed. The version still sitting in the email or the overview is the one that’ll get read and acted on, precisely because you forgot it was there.

Related

• Don’t Publish Into a Void: Baking Revenue Attribution Into the Schema on Day One: a different “read the constraint first” lesson, this time in the schema rather than a contract
• The bundle-ceiling model: decoupling subscription cost from per-event cost in SaaS pricing: the pricing architecture where licensing choices directly affect cost structure
• Don’t build a paywall, reuse the gate you already have: another case where checking what already exists changes the build decision entirely
• Don’t Build the Index Until ChatGPT History Lands: Build Triggers as Anti-Over-Engineering: verifying an assumption before committing resources to a direction
• Our grandfathered $25 GitHub plan silently blocked every CI run: a legacy contract detail (plan tier) that silently shaped behavior until someone read the terms

dxdev LESSON - paste into your AI coding agent
LESSON: A Premise Repeated Across Documents Is Still One Unchecked Guess
SOURCE: dxdev.com/blog/spla-vs-software-assurance-read-the-contract-before-the-brief
WHAT HAPPENED: A cloud-migration brief, a vendor email, and a one-page overview were all built around the premise that the company's Windows/SQL licenses had Software Assurance, which would allow porting them into the cloud via License Mobility. Before sending, the actual 2022 hosting contract was read for the first time in this process, and it showed the SQL license bundled into the server fee, meaning the licenses were under SPLA. SPLA licenses are explicitly not Software-Assurance-eligible, so the premise all three documents repeated was already dead, and asking the vendor to confirm SA status would have signaled a misunderstanding of the company's own contract.
THE RULE: Read the primary source document before building any brief, email, or estimate on a premise it could confirm or kill, and if a wrong premise has already propagated across multiple documents, correct it in every one, not just where it was first written.
CHECK MY CODE, then report PASS / FAIL with file:line for each:
  1. Any cost/decision brief, email, or proposal whose headline number depends on a factual premise (contract term, license status, config value) that is never traced back to a quote or line from the primary source document.
  2. Any premise that appears in more than one artifact (brief, email, ticket, doc) where no single one of them cites the primary source, meaning repetition is standing in for verification.
  3. Any outbound message built on an assumption where the primary source that would confirm or kill it was already accessible before the message was drafted.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.