Dynamics 365 Business Central: is my on-premises customer ready for SaaS?

Is my Dynamics 365 Business Central on-premises customer ready to be moved on SaaS?“.

Will the SaaS platform able to handle the transactions of my Dynamics 365 Business Central on-premises customer?“.

Will I have performance problems on moving my existing Dynamics 365 Business Central on-premises customer to the SaaS platform?“.

These are common questions that quite every Dynamics 365 Business Central partner working with large on-premises customers is asking every day and they were also questions that we tried to answer in our Microsoft Regional Session Italy at Directions EMEA in Lyon last week.

As I’ve said in that session, for helping partners on answering these questions, I think we need to separate the answer into two main topics:

  • Platform scalability
  • Code scalability

Dynamics 365 Business Central platform scalability

Dynamics 365 Business Central is a reliable platform designed for scale.

The reliability of the platform is guaranteed by Microsoft. Just to give some numbers, Dynamics 365 Business Central production environments in the last 3 months had an uptime of 99.98% and this means 9 minutes of downtime per month at maximum.

The platform had 14 Billions of sessions created in the last 30 days, 1.9 Billions of API calls in the last 7 days and an average of 2.5K apps installed every day. These are big numbers and a clear sign that the infrastructure is reliable and mature.

The Dynamics 365 Business Central infrastructure now has load balancing and an advanced auto-scaling feature. Basically speaking, UI sessions and web service sessions connect to a compute tier and the compute tier is responsible to handle the database access:

The compute tier is composed of a set of VMs (scale sets) running the various Business Central components (web server, NST, web client). The load balancing feature spreads the load across multiple VMs and the scaling engine adds more VMs or more database capacity when needed.

A database is considered overloaded if CPU, Data I/O and Log Write metrics on the VMs have high values:

If a database has been consistently overloaded within the last half hour, Microsoft automatically adds more capacity to it (scale up).

The scale up of a database is only applied to paid production environments and it’s an automatic process. Scaling rules are the following:

  • The database is scaled up when in the last 30 minutes CPU, Data IO, or Log Write have been high for a total of 15+ minutes.
  • The database is instead scaled down when (all) the database wasn’t scaled up in the last 45 days and in the last 7 days the values of CPU, Data I/O, and Log Write have been very low.

The scaling up of the database handles also spikes on load. Here you can see an example where the database at 15:15 has a spike on load for about 5 minutes, then goes to 0 and after about 5 minutes it has again an heavy load:

Accordingly to the previously mentioned rule, after about 30 minutes the database in this case will be scaled up to handle the intermittent load.

Handling all these complex scaling mechanisms is Microsoft responsibility. Partners should not worry about that.

I have some data coming from the backend team (thanks Christian Heide Damm) and just for your knowledge, 99.85% of the SaaS databases was never overloaded while only the 0.05% of the databases were overloaded for > 1% of the time.

The numbers on SaaS…

Christian was also kind to share with me before Directions some numbers related to Dynamics 365 Business Central SaaS customers that I’ve presented in the Microsoft Regional session Italy but that I want to share also here because I think that could be helpful to everyone to make your evaluations.

One of the common questions I receive from partners is: how many users can Business Central online handle? Just for your informations, at the moment:

  • Most environments have <20 users
  • Thousands of environments have >100 users
  • Several customers have >1,000 users

This means that the number of users is not a problem for the platform and that actually Business Central has large number of users per environment on SaaS.

And what about the database size?

The current SaaS situation is the following:

  • Most databases are <100GB
  • Many databases are >100GB
  • There are much larger databases, even up to 1TB

Lots of these big environments were customers migrated from on-premises environments. There were on-premises environments with > 650 GB moved to SaaS, but obviously as I always recommend to my customers and partners: when moving an on-premises customer to the cloud, it’s always better to start with a fresh new environment and migrate all the needed data, not the entire history.

What about web service calls?

The SaaS platform was currently able to handle the following loads for a single environment:

  • 10,000,000 calls in one day
  • 1,000,000 calls in one hour (277 per second on average)
  • 25,000 calls in one minute (416 per second on average

What about Job Queue scheduled tasks?

Dynamics 365 Business Central SaaS was able to handle the following Job Queue executions for a single environment:

  • 350,000 in one day
  • 15,000 in one hour (4 per second on average)
  • 300 in one minute (5 per second on average

As you can see, these are all very big numbers and a clear sign that the platform is able to scale and to handle very large customers. Please note that these numbers are not the highest at all and they’re not limits of what Business Central online can handle, but they’re just actual data.

I want also to remember that as every scalable SaaS platform, also Dynamics 365 Business Central has some operational limits that are introduced to better handle the tenant resources and avoid starvations. Operational limits are not related to users, database size or browser interactions, but instead are applied to internal operations.

With Dynamics 365 Business Central 2023 Wave 2 release the operational limits change from a per-environment limit to a more scalable per-user limit.

The new operational limits are the following now:

  • Scheduled tasks: 5 concurrently running tasks per user.
  • Web service requests: 6000 web service requests per user in the previous 5 minute sliding window.
  • Concurrency limits for web service requests: 100 concurrently handled (5 processed, 95 queued) web service requests per user.

The more users you have, the more higher operational limits you have…

Dynamics 365 Business Central code scalability

The other aspect to consider when moving a large Dynamics 365 Business Central SaaS customer to the cloud is the scalability of code. While the above numbers clearly say that the platform is able to scale and accomodate very large customers, for code-related customizations an evaluation should always be done. My recommendation on this topic is to do the following:

  1. Retrieve the processes and the number of transactions that your on-premises customer is actually doing (this can be done by asking transaction types and numbers to the customer directly or in a more reliable way by monitoring customer processes).
  2. Create load testing and perform simulations.

When you have the details about the possible critical transactions that the customer needs to do (for example, the customer needs to post > 100 invoice with > 500 lines per invoice in an hour) you can create load testing scenarios by using the Business Central Performance Toolkit (BCPT). For more informations about how to configure and use this tool, you can check my post here.

With the BCPT tool you can create your test scenarios in code and you can create a Test Suite in Dynamics 365 Business Central to simulate the load. What I recommend to do is to create multiple test suites (for example, one for regular load and one for heavy load) and then execute them to check results:

If you have telemetry activated in your environment, all the BCPT data is logged in Azure Application Insights and you can compare runs:

With these runs data you can discover if you have locks growing accordingly to the number of transactions and these simulations give you important details on how your codebase is able to handle large transactions. If you have important performance problems or locking in your code, probably you can act accordingly.

And when your customer is finally fully on SaaS?

Please remember to always monitor it! Use the free Microsoft Power BI telemetry app (https://aka.ms/bctelemetryreport) or create your own monitoring toolset, but monitoring is a fundamental best practice to act if you have customers running on SaaS:

Conclusion

I hope that this post will be helpful when talking with customers that have doubts on moving their on-premises Dynamics 365 Business Central environments to the cloud. Now you have numbers!

The cloud is reliable and is ready to support very large customers. Scaling of the platform is unlimited and this is a Microsoft’s task (don’t worry about that). Scaling of the codebase is something different and you need to test and sometimes change some “bad practices”. But now the cloud platform is absolutely mature and Dynamics 365 Business Central is also for the biggest (if you were in the telemetry session that I’ve done with Duilio Tacconi at last Directions EMEA in Lyon, you saw how we monitor one of the largest customers and you saw some interesting numbers about performances).

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.