For the past 8 years I have helped IT leaders understand the total cost of ownership for Dynamics 365.  I’ve been using Excel, but that is old fashioned now.  I’ve felt like this information and data has not been easily obtained, although it could be ascertained.  So I’ve made a tool to make it much easier to understand!!  I built a tool where that question always has an answer, and I’m releasing it free today!!

What it is
One HTML file. Download estimator.html from GitHub, open it in your browser, and you’re running. No server, no install, no account, no telemetry. Your work autosaves in the browser and saves out as a JSON file, and every estimate file you ever export will open in every future version. There is a test in the repo enforcing that promise and enabling updates based on new Licensing Guides from Microsoft.

It estimates the Microsoft cloud and licensing run-rate of a Dynamics 365 Finance & Supply Chain Management implementation over up to 60 months:

  • Environments, scheduled by methodology rules
  • Storage entitlements and monthly overage, per pool
  • Copilot Studio credits and packs
  • Azure DevOps seats and pipelines
  • Your own custom items: ISVs, Microsoft Fabric capacity, anything with a price
  • The timeline follows Microsoft’s Success by Design phases: Initiate, Implement, Prepare, Operate. Phased deployments get multiple rollouts, each with its own go-live.

Scheduling rules decide when each environment runs, based on how real projects are delivered. One DEV box per developer, with the lead developer’s box kept for the life of the system. A dedicated data-migration environment starting a month before build, so a corrupted test run can’t hurt the wider project. A hotfix environment after go-live. Disagree with any of it? Override any cell in the environment-by-month grid. Overrides are flagged and reversible.

Storage is where I see the most estimates go wrong. The tool computes entitled capacity (tenant base plus per-license accruals) against the demand of whichever environments are active that month, per pool, and bills the overage at add-on prices. Monthly, the way Microsoft actually bills it.

Every dollar is justified
Here is the part I care about most. Click any figure and you get the cost lines behind it: the formula in words, the rule that scheduled it, and a citation to the section of the Microsoft Licensing Guide the price came from, with its as-of date. The Excel export carries the same citations on its Assumptions sheet.

Being able to defend the number is worth a lot!

Everything opinionated is data, editable in Settings: prices, license entitlements, the environment plan, the scheduling rules. Changes validate against a schema, apply live, and export as a config file you can share with your team. When Microsoft publishes a new licensing guide, updating the prices is a documented procedure you can hand to an AI assistant along with the guide.

What it is not
This is a budgetary estimate, not a quote. Prices are USD list, cited as of a stated date. Your actual pricing depends on your agreement… EA versus CSP, discounts, region. And the project is mine, not Microsoft’s.

See it run
I recorded a full walkthrough on YouTube.

The code is MIT-licensed on GitHub. Issues and pull requests welcome.  If you have ideas, let me know!

If I were you, I’d load your current project into it and compare the storage line against what you budgeted. That line is where the surprises live.

What does your team use today to estimate the ongoing Microsoft bill: a spreadsheet, a partner’s number, or a guess?