When Microsoft D365 for Finance and Operations came out, one of the major changes was the need to extend code and objects instead of overwriting them directly. This allowed for great benefits. D365 continuous updates allow new hotfixes and features to be applied to the system without overwriting custom development. A massive amount of time and money are saved because code no longer needs to be merged every time a new version is released. However, there are still important things to understand about how new versions are applied to environments.
Four New Versions Each Year
Importantly, Microsoft releases a new version of Microsoft D365 for Finance and Operations four times a year. These updates are often called D365 continuous updates. Additionally, they are called service updates.
This Microsoft documentation shows a table with the release schedule of each version.
There are several columns in the table, each showing helpful information. To start, look at just the ‘Release version‘ and the ‘General Availability‘ columns.
First, notice that the Release Version starts with ‘10.0.’ followed by a number that increments with each new version. At the time of this writing, the most current version released is 10.0.41.
Next, look at the General Availability column. Each year a new version is released in March, June, September, and December. Note, that these dates are subject to change, but Microsoft tries to follow this predictable pattern every year.
Only Two Updates A Year Are Required
Even though new D365 continuous updates are released four times a year, Microsoft only requires administrators to apply two updates a year. Specifically, administrators can pause (i.e. skip) one update, but then they must take the next update. Two updates in a row cannot be paused.
Of course, D365 administrators can take all four updates each year. However, to save on testing time, they often choose to only take two updates a year.
To explain, it is highly recommended that users apply the updates to a TEST environment first. This is to ensure any customizations made to the system are working with the new Microsoft updates. Since testing is often a manual process, reducing the number of updates applied each year can save time.
This means that when only two updates are applied each year, administrators will take the updates that are released in March and September or in June and December.
Automatic Updates
By default, Microsoft will automatically apply each new version to the PROD and Stage environments on a scheduled timeline. Many administrators choose to let these D365 continuous updates be applied automatically as scheduled.
Although the way code is written in D365 means that Microsoft’s updates will never overwrite any custom code, there is still a risk. Developers can add code that will run anytime base Microsoft code runs. This is useful for adding additional validation or functionality to an existing form or process.
However, if Microsoft changes the base code, the custom code may no longer work exactly the same way it did before. While not common, issues can occur that require the custom code to be changed to work with the new code. Therefore, it is highly recommended that any D365 environments that have custom code first test the new version in a TEST environment before applying the update to a Production environment.
When Does The Automatic Update Occur?
Whether you choose to let the D365 continuous updates occur automatically, or you manually apply the new version after testing, it is important to know when the automatic update will occur.
Importantly, Life Cycle Services will only allow you to ‘pause/skip’ the automatic update if the Production environment has been updated to the new version. Therefore, this means you must have completed your testing of the new version in TEST, then updated STAGE, then PROD before the automatic update is scheduled to run. Essentially, it is your due date when you must have these steps done.
For better or worse, the actual date the automatic update will apply is based on the settings in Life Cycle Services (LCS). Therefore, it can vary between D365 projects, and isn’t always the same date.
LCS Update Calendar
First, the most accurate place to look for the date of the D365 continuous updates is in Life Cycle Services (LCS).
To do this, open a browser and navigate to lcs.dynamics.com. Next, select your D365 Project from the list. If you don’t see one listed, you have not been added as a user to the D365 project. Ask your Administrator for help.
After entering your project you should see your production, stage, and test environments on the right-hand side main page. You may have a different number of environments or give them a different name.
Next, click on the three lines menu button, and select ‘Project settings’.
Then, on the page that opens click the ‘Update settings’ tab. This page is where the settings exist for the D365 continuous updates. Notice the two links ‘View the update calendar’ and ‘pause upcoming update’.
As can be seen, both of these links show the same calendar. However the ‘Pause upcoming update’ provides checkboxes that when checked will pause the upcoming updates.
In this example, the Production environment will be automatically updated on 2024-11-09 to version 10.0.41. This first row with an ‘Active’ status gives us the due date of when we must manually have updated Production and then pause these updates.
After manually updating the Production environment to the new version, a user needs to come back to the ‘pause upcoming update’ form and check the checkboxes, then click ‘Next’ and ‘Confirm’ in the dialog box, to pause the updates.
The Upgrade Process
Whenever a new D365 continuous updates version is released, these are steps to fully test and update your system. If you choose to let the automatic update run, you can skip this section. However, it is highly recommended that if you have custom code you follow this process.
Download and Apply The Package
First, download the service update to the asset library in LCS. See this article I wrote for more details on applying the package.
TEST
After downloading the new package, secondly, apply a package with that new version to your TEST environment.
After that, test thoroughly in the TEST environment to ensure everything is working as expected. This is the longest step and could take weeks depending on how many tests you need to perform. This can include manual tests as well as tests using automated tools.
Notably, Microsoft will have thoroughly tested all of its base functionality. Therefore, users should focus testing on any place where custom code or integration exists. If an issue is found, most likely it is in these places.
Additionally, users should test all critical business processes. Processes that if they do not work will have a high impact on your business; such as creating and invoicing a sales order. Even if you do not have custom code in this area, it is worth your time to double-check that these processes are indeed working.
STAGE
Third, after all tests have passed, apply the exact same package you previously applied to the TEST environment to the STAGE environment.
It is important that this is the same package. Even though the overall version number may be 10.0.41, Microsoft continuously released additional hotfixes on top of that release. Importantly, if you were to use LCS to get a NEW 10.0.41 package it would likely contain additional hotfixes than what was in the version you tested in TEST.
While more hotfixes sound good, the issue is that you are introducing additional code that was not there when you performed all of your tests. Therefore, it is risky to take that even newer version without first testing again in TEST.
If you find that you need a specific hotfix to correct an issue with a critical business process, then you should take a new version into TEST, re-test, and then apply that same package to STAGE when testing is complete.
After the package is applied to STAGE, consider testing the core business processes once more. The reason for this is that the TEST environment is typically connected to a test code branch. Whereas STAGE will be connected to your release code branch. The same as Production. Therefore, there could be small differences between the custom code in TEST versus STAGE.
Production
Fourth, mark the package in STAGE as a release candidate and then apply to Production. After the package is applied confirm all critical business processes are working as expected. If they are not, you can consider rolling back the update.
Pause The Automic Update
After applying the D365 continuous updates to Production, there are still two important steps to complete.
The first step is to pause the automatic updates that are scheduled in Life Cycle Services. Again, if this automatic update is not paused, an additional package will be applied that will contain more code than what you tested. Therefore, the automatic update should be paused until the next time an update comes out, or you decide to take an update.
First, as stated earlier, open a browser and navigate to lcs.dynamics.com. Next, select your D365 Project from the list.
Next, click on the three lines menu button, and select ‘Project settings’.
Then, on the page that opens click the ‘Update settings’ tab. Click the ‘pause upcoming update’ link.
Finally, check all enabled checkboxes to pause all upcoming updates. Then click the ‘Next’ button. In the next dialog, enter a reason as to why you are pausing the update, such as ‘pending validation’. Finally, click the ‘Confirm’ button.
Additionally, for more information on pausing updates see this Microsoft documentation.
Update All Remaining Environments
Finally, the last step in the D365 continuous updates process is to go back and manually update all remaining environments to be on the same exact version as your Production environment.
Specifically, you may have a fourth Tier 2 machine, such as a GOLD or Performance testing environment. Update these.
Additionally, in Life Cycle Services (LCS), go to the three lines button, then ‘Cloud-hosted environments’. This will show you all of your development environments and build environment if you have one. Update these to be the exact same version as Production.
To explain, there are a couple of different reasons why it is important all environments are on the same version.
First, when using a development environment to debug a production issue, the development environment must have the same code as production. Otherwise, you might not be able to replicate the issue.
Second, often times you will take a backup of the Production database and restore it to a development environment. Perhaps you are doing this to debug an issue that occurred in Production. Or, you are doing this because additional data was added in Production and it saves time to restore it rather than manually add it to a development environment. Either way, the database restore will likely fail if the development environment is not on the exact same version as the database it is being restored to. This is because a different version may have tables or fields that do not exist in an older version.
Additional Ways To Determine The Automatic Update Date
Previously, I showed you how to view the ‘pause upcoming update’ form in Life Cycle Services (LCS) to see the specific date that the automatic update will run. However, there is a second way, using the update settings in LCS, you can use the calendar Microsoft provides to calculate this date as well.
First, navigate to Life Cycle Services (LCS). Second, click on the three-line button, and select Project Settings. Third, click on the ‘Update settings’ tab to see the following form.
Next, note the value of ‘Cadence’ and ‘Day of the week’ settings. In this case, the settings are such that the Production environment will always update the ‘Second’ ‘Saturday’ in the month. Unless some user changes these values, this will apply to every D365 continuous updates process.
But what month is it referring to? Navigate in a browser back to the Microsoft page ‘Service update availability‘. Next, scroll down to the table that shows the Release schedule.
First, locate the ‘Release version‘ you are upgrading to in the first column. Second, find the corresponding month in the ‘Second autoupdate schedule for production start date‘ column.
Example
Let’s look at two examples. First, when upgrading to 10.0.41, the month in the ‘Second autoupdate’ column is November. The second Saturday in November is the 9th. Therefore, I would expect to see in the ‘pause upcoming update’ calendar that I must upgrade Production by November 9th. And that is the case.
Second, if I look ahead and want to know when I will need to finish upgrading to 10.0.43, I can look at the table above and see that the month in the ‘Second autoupdate‘ column is May. Additionally, my LCS settings say that the automatic update will be scheduled for the Second Saturday of the month. The second Saturday of May 2025 is May 10th. If I check LCS, I can confirm that if I pause every update I can, the next one that I cannot pause is on May 10th.
Note, that this formula is based on the assumption that you are pausing every possible update LCS will allow. This is done to give you the most time to test the new version. You can always choose to update earlier.
Automatic Update Of Acceptance Test Environment
In addition to the Production Environment, Microsoft also automatically updates the ‘Acceptance Testing’ environment. Specifically, the environment specified in the ‘Update settings’ page here:
This can be any Tier 2 environment, but it typically is set to whichever environment is the pre-production or STAGE environment.
In the “update calendar” form, you can see that this is always scheduled to be automatically updated one week before the Production environment is updated. The purpose of this is to allow users to see if there are any issues with the new version in a non-production environment before the new version applies to Production.
This is helpful, but it may not be enough time to complete all necessary testing. That is why we recommend following the process outlined earlier and applying the update to a TEST environment when the new version is released.
Importantly, since both this Acceptance Testing environment and the Production environment must be on the new version before LCS will allow you to pause any more automatic updates, you actually should plan to update Production before this date. In this example, it is the FIRST Saturday of the Month.
To explain, if you wait until after the first Saturday of the month, the automatic update will run, and upgrade the Acceptance Testing environment to the very latest version, and not the version you tested in TEST. Therefore, since you cannot revert to an earlier version, you will need to redeploy the ‘Acceptance Testing’ environment to the same version that TEST is on first. Then, you can mark that package as a release candidate and promote to Production.
Ultimately, this takes extra work and time that is not necessary if you instead upgrade Production before the ‘Acceptance Testing’ automatic update runs, and then pause all updates.
Conclusion
Microsoft has created a great architecture in which new versions can be applied as D365 continuous updates without overwriting custom code. Because applying a new version no longer requires the code to be merged, this saves a massive amount of time. However, there is always some risk that the existing custom code will not work the same as with the new version. Therefore it should be tested. The existing automatic update schedule will update an ‘Acceptance Testing’ environment one week before Production is updated. Oftentimes, more time is needed to complete testing. When that is needed, this article explains the steps to manually apply a new version, pause the automatic updates, and understand the timeline.
