Microsoft Upgrades
As you are aware when on the cloud Microsoft will upgrade your system automatically. A minor upgrade happens every month and at least two major upgrades will happen every year. As more of these major upgrades are happening Dialog is discovering that these can create difficulties, particularly if Microsoft releases changes or features that impact your system. Sometimes, for example, Microsoft deletes a field, renames a field or moves a field. You are using this field but after the upgrade it may no longer be available to your system. As you can imagine this could create a few issues. There could also be schema changes, platform changes and changes to security policies and more.
This naturally creates challenges and the following questions become relevant:
- How do you know when the upgrade is going to happen
- How will you know what changes (if any) with the upgrade are going to affect your specific Business Central
- How will this affect your customisations
- Can you stop the upgrade from happening
We will address these questions below.
Microsoft sends a message to a “notification recipient(s)” that an upgrade is going to happen on or around a specified date. These notifications are sent once a month to advise of pending updates, allowing the notification recipient to control when these are applied to their environments, and view release notes of upcoming changes for major and minor upgrades. Then again once a month (if all goes ok) to advise of successful upgrades.
More than one person in an organisation can be a notification recipient. This person is Dialog by default. We recommend that you also appoint a person from your company to be a notification recipient. The notification recipient has the option to delay the upgrade for up to 90 days. The notification recipient can also request that the upgrade first happen in the sandbox (pre-production) and then later in the production environment.
If no “delay” notification is received from the notification recipient Microsoft performs the upgrade. If this results in an identified error the notification recipient(s) will receive an email stating that an error was encountered, and it will stipulate what this error is. The upgrade will be halted as it has “failed” and you are given time to correct the error. This message may be difficult to understand and may require assistance from Dialog. We may need to analysis the message and determine the cause of the error. This takes time and it is difficult to estimate upfront how much time is needed to understand what the error is and its ramifications. It has also happened (very rarely), that the upgrade has been done and Microsoft has not reported any errors. However, when working on the new upgraded system data links may be missing and functionality is no longer operational.
Most of the time the upgrade process works well but the question still remains: What to do when the upgrade fails or passes but then the upgraded system disrupts day-to-day operations?
Testing is often not sufficient to reveal a problem, however at the very least for ALL cloud customers we encourage you to spin up a test instance for your own production environment and check that the upgrade process would be successful. If not then we can assist you in identifying what might be wrong.
To assist our clients Dialog is proposing three scenarios.
| Scenario | Activity | Time Commitment | Recurrence |
| Educate on self service | Educate you in how to create your own sandboxes. The expectation is that you would nominate a notification recipient who would receive the pending update notices from the Microsoft admin centre. You would run a test upgrade in the sandbox in the period before a major release goes live. If there are issues, log a Response Desk Ticket and Dialog will assist on a time and materials basis. | 2 Hours | Once off |
| Bi yearly upgrade review service | We can create the sandbox for you (twice a year) and monitor the upgrade. We will also view any compilation warnings for extensions in VS Code on that sandbox. Three possible outcomes exist. A: The upgrade passes. B: An upgrade in the sandbox fails. We provide a summary of what failed, and a time and materials estimate of what is needed to achieve success. C: Upgrade passes but there are per tenant extensions that have warnings such as for pending deprecations, and again a summary of what is needed and estimate of action required to avoid issues if deployed. | 7-9 Hours 2-3 to create sandbox from production and test upgrade. 5-6 hours to connect vs code to sandbox, and assess upgrade errors and warnings | Each Major Update |
| No service | You receive the notifications from Microsoft and if any issues are found and assistance is required then you contact Dialog | Time and Materials | Not Applicable |
As stated above, testing may not identify every eventuality but at least this is a pro-active approach and a way to reduce the risk of failure during the upgrade. It is also important to note that in most cases the upgrades are successful first time around.
Please feel free to contact us for more information. Otherwise if you do encounter difficulty please log a job with the Response Desk.