Vendor Economics: The Email in November

Contents11 sections

Technology leaders negotiate hard on the thing they are buying and then sign whatever the renewal terms say. I did this for years. A purchase was always a project: executive attention, a committee, a competitive process, a decision memo. The renewal was an email in November carrying a 7 percent uplift, approved by somebody in procurement because the alternative was a migration nobody had budgeted. Multiply that across a portfolio and compound it across a decade — a 7 percent uplift doubles a line in ten years — and the renewals cost more than the purchases ever did.

This is the least glamorous article in the series, and probably the one with the highest return per hour of attention.

Where the recurring spend hides

One pattern runs through all seven: the initial decision gets scrutinized and the growth does not. Nobody approves seat creep. It arrives one onboarding at a time; by the time anyone looks, it is the baseline.

Perpetual licences and the end-of-life squeeze

Traditional enterprise software sold a perpetual licence plus an annual maintenance stream, typically 18 to 22 percent of list price, and that maintenance buys support and version upgrades, which sounds like a service contract and behaves like an annuity the vendor owns and you fund. Three mechanics decide the cost.

Maintenance is priced off list rather than off what you paid. You negotiated 55 percent off the licence; the maintenance is frequently calculated on the undiscounted figure, so the great deal carries an escalating annuity that is much larger against your actual spend than it looks against the list price.

Dropping maintenance is usually a one-way door. Lapse it and reinstatement typically costs back-maintenance plus a penalty, which is deliberate (the penalty is the product, not an oversight): it makes the decision to stop paying a decision to migrate.

End of life is a forcing function. The timing belongs entirely to the vendor. When a version is declared end of support you are choosing among an unsupported production system, an expensive extended-support contract, and an upgrade project nobody planned. Track the published support lifecycle for everything material and put those dates on the same roadmap as your own work, where they compete for the same quarters.

Licence audits are a revenue channel, and they arrive with a settlement offer attached. Inventory is the defence, rather than argument. Know what is deployed, where, on how many cores, under which metric, continuously. A company that can produce that in a week settles cheaply; a company that needs three months to assemble it pays for the delay as well as the shortfall.

Cloud commitments behave like debt

This deserves its own section, because it is the largest unmanaged obligation in most technology organizations, and because nothing on the balance sheet will tell you it is there.

Every one of these lands on the profit and loss statement as operating expense, and every one of them behaves like an obligation. A three-year enterprise commitment signed against an aggressive growth forecast is a liability nobody on the technology side is tracking as one.

The failure runs in both directions. Over-commit and growth comes in under plan, so you pay for capacity nobody consumed; the FinOps dashboard then reports it as waste rather than as a commercial decision made two planning cycles ago by somebody who has since left. Under-commit and you pay on-demand rates on a workload that has been stable for three years, which is less visible and roughly as expensive.

Flexera's 2026 report put self-estimated wasted infrastructure and platform spend at 29 percent, up for the first time in five years, with AI workloads making forecasting and rightsizing harder. In the same population, 85 percent still named managing cloud spend a top challenge, 63 percent ran formal FinOps teams and 71 percent ran a cloud centre of excellence. So the governance matured and the waste went up. Does that mean FinOps failed? It means commitment sizing is a forecasting problem, and AI workloads have made forecasting materially worse.

Commit to the confident floor and layer shorter instruments above it. The floor is the spend that survives a bad year, the expected case is a forecast, and a forecast signed for three years is a bet placed by whoever holds the budget next.

Provider migration funding

All three hyperscalers run structured migration programs with money attached, and most mid-market companies migrating at scale never ask. Asking costs an email.

The AWS program is the best documented of the three, and five things about it generalize to the others.

1. It is partner-led. A partner files on your behalf and the funding arrives as a cost reduction rather than as a cheque.
2. It is earned against milestones and consumption rather than granted upfront. Credits commonly land somewhere between 15 and 25 percent of first-year run-rate spend, and the figure moves with scope.
3. It generally needs meaningful scale, often quoted at around fifty servers or the equivalent (a guideline rather than a rule, and a partner will tell you where the line actually sits).
4. It requires resource tagging so the provider can attribute migrated spend, which means the tagging convention has to be agreed before cutover rather than reconstructed after it.
5. As of 2026 the programs cover generative AI and agentic workloads as well as infrastructure moves.

One rule governs all of it. Ask for the funding before committing to a direction, then choose the architecture as though the money did not exist. Credits are a discount on a decision that should already stand on its own. I watched a company pick a provider for a credit worth 4 percent of a five-year total — the credit did arrive, on schedule — and then spend more than that inside eighteen months on a worse architectural fit. The partner offering the biggest number is rarely the partner whose assessment survives six months of life after cutover.

Building the renewal position

A renewal position gets built twelve months out. By the time the quote arrives, what you did and did not do during the year has already set it.

The highest-value artifact on that list is utilization data. A vendor quoting a renewal for 4,000 seats has a weak hand when you can show that 1,900 people signed in last quarter. That is fewer than half the seats on the invoice. Most organizations cannot show it, and that is why most renewals go the vendor's way.

Next comes a credible alternative, where credible means scoped and costed with the migration effort included. "We could always move to a competitor" is a sentence rather than a position, and a vendor can tell the difference in about two questions.

The support-tier question

Cloud enterprise support is frequently priced as a share of spend, so it grows automatically as you grow, with no matching increase in what arrives. On a large account it becomes one of the bigger line items, and at enterprise-agreement scale it is negotiable.

One question settles it, asked honestly: in the last twelve months, what did this tier give us that the tier below would not have? A named technical account manager who has actually been useful is worth keeping. Faster routing on tickets you rarely file is worth a conversation about stepping down.

What I actually do

1. Keep a live vendor register with the contract end date, the notice period, the auto-renew clause, the annual value, the escalator, and a named internal owner. One spreadsheet has saved more money than any tool I have bought.
2. Diary every notice period the day the contract is signed. An auto-renewal with a 90-day notice window is how a vendor gets another year for free.
3. Treat maintenance as something that lapses only on purpose, since reinstatement penalties are designed to trap whoever forgot.
4. Track published end-of-life dates on the engineering roadmap beside our own work, where they compete for the same quarters.
5. Keep the deployment inventory current enough to survive an audit at a week's notice.
6. Size cloud commitments to the confident floor and layer shorter instruments above it.
7. Treat every commitment over a threshold as a board-visible obligation, with the forecast it was signed against recorded next to it.
8. Ask for migration funding early, then decide the architecture as though the money did not exist.
9. Review support tiers once a year against what they actually delivered.

All of it is boring, which is precisely why it is still available. Boring work has no competition.

Glossary

References

• AWS, Migration Acceleration Program documentation
• Opsio, "AWS Migration Acceleration Program (MAP) Explained: Funding, Phases, and What Actually Gets Approved"
• flashdba, "Cloud Provider Funding 101: MDF, Migration Funding and POC Credits Explained", covering the Azure Accelerate consolidation and the Google program
• Atomic Computing, "How the AWS Migration Acceleration Program Works"
• Flexera, 2026 State of the Cloud Report, on waste, FinOps maturity and centre-of-excellence adoption
• Microsoft partner program updates, the Azure Accelerate announcement, October 2025

Best next read

Part 8, AI Spend: Three Budgets Pretending to Be One. AI is the fastest-growing line in most technology budgets and the hardest to forecast, which is exactly the condition that breaks commitment sizing. Part 8 splits it into the three things it actually is.

The full series

This series is an introduction for technology leaders. It is accounting and tax context rather than accounting or tax advice. Treatment is fact-specific. Model it with your CFO and auditor before you commit.