Calculating Total Cost of Ownership Moving From AX to Dynamics 365

As good a source as any for this purpose, Wikipedia (abridged) defines the Gartner coined acronym, Total Cost of Ownership (TCO), as a financial estimate intended to help buyers and owners determine the direct and indirect costs of a product or system.

TCO, when incorporated in any financial benefit analysis (like an ROI calculation), provides a cost basis for determining the total economic value of an investment.

A TCO analysis includes total cost of acquisition and operating costs and upgrades as well as costs related to replacement at the end of a life cycle. A TCO analysis is used to gauge the viability of any capital investment and is commonly applied to the analysis of information technology products by those seeking to quantify the financial impact of deploying a product over its life cycle.

TCO answers the question “How much is this going to cost?” Calculating TCO is valuable for:

  • Planning, budgeting and cashflow forecasting
  • Making decisions between competing investment decisions
  • Use in ROI calculations and cost/benefit analysis as part of a business case presentation

A TCO calculation is NOT a Return on investment (ROI) calculation. That is, the TCO looks at the cost side of the ledger, and does not introduce the value side. It does not answer the “how much better off am I going to be in choosing to upgrade over not upgrading” question. For that, you need to know the TCO but you also need to look at the benefits/value. This blog only looks at TCO.

Before we start, a TCO in itself is interesting for planning and budgeting, but comparative TCOs are incredibly useful for supporting decisions.  Should I upgrade and what will it cost? How do I compare that with the cost of not upgrading or delaying the upgrade for a year?  I would recommend you consider the options you want to compare, and build a TCO for each choice.

1 Calculating Total Cost of Onwership for Upgrading to Dynamics 365

Close your eyes and imagine a spreadsheet. This should be easy for anyone who was interested enough in this topic to land on this page! Down the page are the cost components. Across the page are months or years. First we’ll look at building this spreadsheet down the page. Then we’ll look at the across the page components, and considerations when putting together the numerical content for the body of the spreadsheet.

1.1 Infrastructure / Platform

These are the costs to provide the foundational systems required to effectively run, manage and secure the ERP solution.  For On-Premises applications, this includes server and networking hardware, security appliances and software, storage array hardware, operating systems, databases and data failover/redundancy facilities, along with related datacenter costs like electricity and rent. This can also include the overhead cost of I.T resources to deploy the platform and provide the ongoing support to ensure it is operated and maintained at optimum performance.

For F&O, the cost of the infrastructure (IAAS) and platform (PAAS) is bundled into the application cost (SAAS).  However, you should also consider the ongoing costs of additional sandboxes.  These are the development, testing and training environments that may be spun up in addition to the two sandboxes that come with the application subscription. We have found that during implementation it is necessary for clients to subscribe to two or more additional sandbox environments – including extra sandboxes for developers (the Tier 1 sandbox is single user), a sandbox to hold the tested final configurations, and if relevant, a temporary environment for load testing.  After your solution is deployed and live, you may also want a permanent additional sandbox to use for testing during the continuous update cycles.  Your Dynamics Partner should be able to give you good advice on what you will need in your scenario.

The cost of networks (Local and Wide Area), desktop systems (e.g. workstations) and devices (e.g. scanners), can be included but do not generally represent a variable cost when comparing system alternatives.

Note that if you search the web you should be able to find TCO calculators that give you estimates for infrastructure costs. Check out the Cloud platform hosts, they have lots of material on this as they entice people to swap on premise / data centers for their clouds.

1.2 Application software

For Dynamics AX on-premise, this is the purchase cost of the software for AX and ISVs, plus the maintenance fees you pay to your partner or to Microsoft or the ISVs to keep current. When you are considering comparative TCOs for an upgrade, the original purchase price may be fully written off, or it may still be being depreciated. The depreciation is a non cash cost you should include in your calculations.

This is the cost of the actual Dynamics 365 F&O software application or in cloud parlance, the subscription service. Add to this the cost of subscriptions for the ISV solutions you will need (most ISVs now provide subscription pricing).

1.3 Implementation services

This is the cost of deploying, configuring, developing and customizing the application(s), migrating data, and training users to a point where the application performs in a live environment in accordance with the business requirements. This includes both internal (employee resources) and external (vendor resources) costs. It includes all costs that support the project, such as solution selection, change management, process auditing, process re-engineering, and project management.  Ask your partner for an upgrade estimate. Make sure you have the fully loaded cost – including things like travel and accommodation, and if relevant travel time. I would suggest you add an incremental allowance to cover the risk of going over budget. Depending on where you are now (AX2009, AX2012), the scope of the upgrade, the changes you anticipate making as part of the upgrade; these will all make a difference to the risk percentage you will want to allow for.

1.4 Carrying Costs

For AX on premise, include the cost of maintaining the stack of applications implemented, including loading of fixes, patches, updates and full version upgrades as well internal and external end user functional and technical support. This can also include the cost of keeping the application solutions current and secure, and anticipated growth (additional users, growing data storage demands) or innovation (new business models, business process re-engineering etc.).

For D365 the carrying costs should include the cost of maintaining the continuous update cycle. This new approach effectively takes the historic big-bang cost of upgrades, reduces it materially, and spreads the balance more evenly across the life of the application.  Instead of spending a million dollars every 5 years, you’ll be spending (considerably less) money evenly across the 5 years to keep yourselves current.

Again, I recommend asking your partner to supply you with information on how much effort and cost goes into working with the continuous update cycle.

1.5 Decommissioning Costs

You should also consider the cost of decommissioned legacy platforms, including trailing annuities and remaining depreciated cost of retiring assets. For example if you are moving from AX2009 to D365 you will not be bringing your historical transactions across. The general approach is to push this data into a data warehouse (on premise or cloud) and then use a tool like Power BI to pull reports from both the old and the new data sources.


Now you have identified the line item costs that you will use in your TCO calculation, you need to consider “across the page” data for the spreadsheet (that is, how far out your calculations will go). And there are other things you should think through before presenting the information you have gathered:

2.1 Capture all the costs that can be reasonably predicted

There are the obvious, reliably estimated and anticipated costs that are clearly identifiable when first considering TCO. Then there are the hidden, unknown, indirect or unreliably estimated costs that could end up being a material component of the TCO. Ultimately the purpose of a TCO is to provide visibility for decision making, and to compare and decide between options. As with most data-based decisions, the quality of decision is dependent on the quality (completeness, validity, accuracy, consistency, availability and timeliness) of the data from which the decision is made.

TCO calculations may be manipulated, either intentionally or unintentionally, by missing material costs or lacking equivalency (required for a fair comparison). Vendors may not provide you with visibility of all costs. Vendors estimates and quotes often exclude any costs that are not directly revenue to them but are still costs to you (like travel/expenses). It is important to review any vendor provided TCO calculations carefully. We would advise starting with as full and complete a list of all costs as possible. Identify contingencies and unknowns – exclude them from the numbers but be sure to notate any analysis accordingly.

Lastly, it is important for the TCO to include a line item for costs that are material and have a medium to high degree of certainty. As with most forecasting however, there will be events that carry a potentially material cost that lack the certainty needed to justify being included as a line item in your calculations. For these costs, a supporting narrative is more valuable, as including material numbers with a high level of improbability will unduly skew the TCO assessment. Also, consider the level of materiality. Line items can be material because of the dollars associated, or they may be material due to their nature. The best option here is to look at the estimated amount as a percentage over the total cost, make a judgement call based on that percentage, and state your assumptions.

2.2 State Assumptions

Your TCO will be based on many assumptions. There is no way to avoid this. With lack of certainty, transparency becomes more important, so ensure the assumptions are clearly listed. When creating multiple TCO calculations for comparing options, assumptions should be consistent across the options.

2.3 Consider Certainty, Predictability, and Risk

As with any forecasting activity, there will be numbers that will have a high degree of certainty, and numbers that do not.  How certain are you that your vendor quote for implementation will be met, and the project will be on time and on budget? In the same way, costs that will be incurred sooner will be more easily estimated than costs in years to come. Will Microsoft raise the subscription cost of Dynamics after the 3-year contact on the Enterprise Agreement (EA)? The Cloud Solution Provider (CSP) pricelist is monthly and the fine print includes the ability for Microsoft to raise prices at any time, with notice. Some TCO preparers will look to add contingencies to reduce the risk of underestimating costs. It is useful to include contingencies but they should be classified separately, so that the element of risk is separately visible in any summary analysis.

2.4 Cover a relevant Duration

ERP TCOs typically span multiple years to capture costs over the “life of the product.” Many product vendors suggest that the product life could be virtually “forever.” This is because the new Cloud-based SaaS solutions are continually patched and updated and users are contractually obliged to keep their systems current – there will be no more “revolutionary” upgrades in the future. Most TCOs for IT solutions go out at least as far as 5 years because 5 or 6 years has historically been considered the useful life of a server and the TCO needs to capture that On-Premises refresh cost. However, the life of an ERP system has often been quoted as 8 years, and many industry commentators suggest that historically, the actual number is more like 10 years. How often an enterprise renews, rebuys, or refreshes their ERP very much depends on the organization’s growth and development as well as their approach to keeping their original purchase upgraded and well maintained. Consider your organization’s past approach to approving upgrades. We recommend a duration of between six and ten years for your TCO, particularly if there is an anticipated and significant bump in costs in either option in years 6-10.

2.5 Considering Opex versus Capex

When you look at TCO through finance eyes, you look at numbers a little differently than when you look at them from an accounting perspective. If possible, you should collect data sufficient to look at TCO from both viewpoints. For analysis and particularly for calculating an ROI, it is the finance model most often used. For corporate budgeting, the impact on the financial accounts will be required. To ensure the TCO can feed into both perspectives, the TCO model should include non-cash impacts like depreciation as well as extended cash impacts such as taxation calculations.  It is also worth considering the accounting treatments for Cloud applications. For more information, please refer to this document.

2.6 Comparing TCO results

The difficulty with comparative TCOs is that at times you might be comparing two scenarios that are so significantly different that there is little overlap of data points. Further, when considering TCO for ERP decision making, simply comparing the numbers does not give the audience enough information to make an informed decision. Consider the risk inherent in the numbers, comparatively speaking. What level of variability does a Cloud subscription to compute resources have compared with a properly serviced data center? What TCO comparisons you prepare, will very much depend on where you’re coming from, and the choices you are open to considering. Invariably one of the options will be to do nothing. In this context, this means to NOT upgrade or implement. A fair assessment of the “Do Nothing” TCO is always important for decision makers – even if they have expressed 100% commitment to an upgrade or system change.

It is also useful to consider preparing a TCO for various scenarios. Presuming high business growth (say 15%) will create a different TCO than assuming no growth. Presuming that you are “all-in” with your ERP options, including all Independent Software Vendors (ISVs), all Business Intelligence options, a full roll out, will give you a different result than if you take a more conservative or “phased” approach. When deciding how many models to prepare, consider the most likely scenarios as well as alternative scenarios for comparison. This may help you determine a possible TCO range, which is more reliable than a single number.

2.7 Reporting the Quantitative AND the Qualitative Findings

When we talk about TCO, we are focused on the cost side of the ledger. And when considering costs (just as we do when considering benefits) it is important to provide a framework to assess the qualitative data that might differentiate the choices. A way to consider qualitative costs, (the difficulty finding qualified technical employees for example) is by identifying the costs and presenting them using impact/cost quadrant graphics. This way, your TCO report can consider costs that are not quantifiable but could be material to the overall investment.

I hope this has been useful as a starting point for building your business case. If you have any questions or need assistance in calculating your TCO move from Dynamics AX, please contact us!

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author