Cloud D365FO: How DevOps Can Reduce Total Cost of Ownership

Few people think about what the Total Cost of Ownership (TCO) of cloud D365FO turns into one or two years after implementation. The cost of cloud resources grows, used capacities often increase without systematic control, and the D365FO architecture itself creates mandatory expenses: supporting environments, paid integrations and services, regular updates and the related work.

In many organisations, total operational costs over time exceed the cost of licenses, although partners usually focus on licenses at the sales stage.

That is why a transparent TCO model is critically important, one that reflects the real costs of operating and evolving the system, not only the subscription cost.

In such a model, DevOps practices become a tool for reducing and controlling costs. They reduce the number of manual operations, increase predictability, speed up technical procedures, and help control the efficiency of paid resource usage. At the same time, D365FO specialists are expensive and usually overloaded. Reducing their involvement in routine operations directly accelerates system development: more time is spent on business requirements rather than on release preparation or waiting for data copying.

What the TCO of cloud D365FO consists of

In simplified form, TCO can be divided into four blocks:

1️⃣ Licenses and infrastructure

2️⃣ System development and updates

3️⃣ Operations and support

4️⃣Training, risks, and indirect costs

Let us consider how DevOps practices help reduce TCO in each of them.

1️⃣ Licenses and infrastructure

The main problem of the cloud model in the context of costs is the need to assign and release licenses in a timely manner, as well as to manage paid resources and services. Otherwise, the company starts paying “for air”, and these amounts become significant over time.

Monitoring resource usage and license consumption becomes a key TCO optimisation process.

For this purpose, we use:

• Azure Cost Management Report for regular tracking of cloud resource costs
• automatic shutdown of unused resources and configuration optimisation;
• license optimisation through proper configuration of roles and access rights.

Infrastructure savings example

Assume a customer uses a server for developers.

One server running 24/7 costs around 1,000 EUR per month, including:

• 900 EUR - SKU cost
• 100 EUR - data storage cost

How can these costs be optimised?

➡️ In most cases, there is no reason to keep a development server active 24/7, as the actual useful load is limited to business hours (8/5).

SKU costs with an 8/5 schedule:

900 × 160 / 720 = 200 EUR per month.

➡️ Even during business hours, the server is not used constantly. A developer may connect later, finish earlier, be on vacation, or work on other tasks (training, analysis, communication) that do not require an active environment. We can assume that actual server usage is about 70% of the monthly working time.

SKU costs considering actual working time usage:

200 EUR × 0.7 ≈ 140 EUR per month.

➡️ When the server is turned off, disk space billing remains, and we still pay for data storage. However, automatic switching of disks from Premium SSD to HDD during idle periods allows additional reduction of storage costs - roughly up to 70% of storage cost.

Storage costs considering disk type change:

100 EUR × 0.3 = 30 EUR per month.

Total monthly savings for one server: 1,000 − 140 − 30 = 830 EUR

This is about 83% savings on a single server.

And the more servers there are, the more noticeable the effect becomes due to inevitable infrastructure downtime.

2️⃣ System development and updates

Any ERP in an actively growing company requires continuous investment in development and updates. These are irregular project costs related to changes in system functionality. Excluding infrastructure (which is already accounted for above), development includes:

• internal resources (payroll);
• engagement of external specialists;
• temporary integration solutions;
• user training for new functionality.

At this stage, qualified specialists are engaged in development, testing, documentation, release management, user training, and user support.

How DevOps practices reduce TCO in development

Increased stability through automation:

• automated checks and early error detection;
• alerts about abnormal situations;
• automation of complex multi-step procedures to eliminate the human factor.

Freeing up the time of expensive specialists:

• automated releases;
• database copying;
• environment deployment and updates;
• application updates;
• version control;
• running automated tests on events.

Reduction of Time to Market (TTM) through automation of release processes

For example, manual deployment of a new D365FO development environment at some partners takes 24–40 hours. After automation, this process takes about 4 hours, including database installation, additional software setup, and updating to the required version. As a result, when issues arise with a development environment, it is often easier to deploy a new environment than to spend days on diagnostics.

Another example is copying a database from Sandbox to a development environment. With volumes exceeding 500 GB, this operation can take more than a day (24 hours) and requires constant monitoring. After automation, it is enough to start the process and receive a report via email or WhatsApp. The pipeline can immediately include sensitive data anonymisation, user activation, integration settings updates, and other required operations.

This sounds simple and extremely useful, but we have not seen such automation from any of other partners.

3️⃣ Operations and support

Operations and support are regular, recurring costs related to maintaining system availability: resource usage, data storage, routine operations, incident handling, and bug fixing.

Here, DevOps practices reduce TCO through monitoring, control, and analytics tools:

• automated reporting on security settings and compliance with recommendations;
• reports on resource costs;
• automation of data management strategies;
• infrastructure health monitoring and alerts on limit breaches;
• control of SLA compliance for internal and external services.

For example, D365FO is integrated with an external electronic document management service with a declared SLA of 98.6%. At the same time, users regularly complain about service unavailability. Automated monitoring allows either confirming SLA non-compliance or quickly identifying issues on the D365FO side.

Another automation example is proactive alerts about growth in CPU, RAM, or disk space consumption on servers, which allow preventing incidents and operational downtime before they occur.

4️⃣ Training, risks, and indirect costs

This block is often forgotten when calculating TCO, although it frequently exceeds operational budgets.

It includes:

• user and IT team training time (especially with high staff turnover);
• regressions after platform updates, ISV updates, or customisations;
• risks of losing vendor support due to unsupported customisations;
• unexpected delays and errors during releases due to the lack of standardised processes;
• data losses due to access violations;
• sudden performance degradation;
• additional payments for urgent and emergency work.

The key value of DevOps practices here is risk reduction and increased system resilience:

• automated execution of best practice checks, automated tests, and routine procedures;
• alerts and dashboards;
• access restrictions and controls for critical infrastructure.

For example, during a release, it is important to automatically track which changes and within which tasks were included in the release. It often happens that tasks are formally closed, but new changes related to them are included in a new release and remain untested. Automation allows collecting the full release scope based on code and distributing it to all stakeholders.

Another example is working with multiple vendors. Automated code checks (including Microsoft Best Practices) allow formally improving the quality and stability of applications without manually reviewing the code from all contractors.