18

Today I received the following mail for every cloud customer we :


Subject: We’re temporarily postponing updates to version 23

We’re temporarily postponing updates to version 23.0, and your tenant has one or more environments currently scheduled to receive this update.
If you have an environment scheduled to receive an update while updates are postponed, your environment will not be updated automatically, but will be rescheduled to seven days after the originally scheduled date.
You can manage the scheduling of environment updates from the Dynamics 365 Business Central admin center.


I checked my mailbox and also found

- We are temporarily postponing updates to version 22.0

- We are temporarily postponing updates to version 21.0

- We are temporarily postponing updates for version 20.5


To avoid problems with upgrades, you should test your upgrades before releasing them to the general public. You don't specify why this is happening and taking our customer, I notice that leaves a bad impression of Business Central and how Microsoft handles quality of major updates.


How about take a copy 10% of cloud databases, put them in an isolated service tier so that nothing can communicate to the outside? And only if all succeed, release this update in 3 update rings (First < 20%, Fast < 40% and Broad 100% (=all) ).

STATUS DETAILS
Needs Votes
Ideas Administrator

Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future. Best regards, Business Central Team

Comments

D

Daniel, you seem to assume that the updates are postponed because of problem(s) with AppSource or PTE apps.

I would rather think that the updates are postponed because of serious bugs in the Microsoft AL code and/or the runtime.

Anyway, we will never know as the reason is not mentioned anywhere.


The biggest issue is the update policy itself (mayor release every half year and CU every month).

There is just not enough time to test properly (and honestly, the test apps do not find all bugs either, just the issues foreseen by the test app developer, nit the weird things end users can do).


Category: Tenant Administration

D

After feedback on Yammer, I like to add:

I'm not saying that Microsoft should solve any problem that a partner or customer causes. They check if the Apps in the cloud environment are compatible with the next version. We got the first mail for BC 23 compatibility on 2023-09-07, a month before, which is great.


What I wish is that they would take 10% of the cloud environments and test their upgrade code with real life data, not just CRONUS data. Sure, the custom apps can prevent the upgrade. I have seen mails where they send us a call stack and the app that is causing it. That way they would know if Microsoft or Partner was causing the problem. They could even uninstall all non-Microsoft apps to test their own upgrade code and that would be all I would want:


Make sure the Microsoft app upgrade code is solid and allow me as Partner to fix our apps by telling me exactly why the upgrade is failing.


When the BC23 upgrade became available, I tried to upgrade my sandbox. The upgrade failed several times, with the update failing with an internal error. The exact error message was "Error: Update failed with an internal error" without any further details. The error message is of course useless. A day later, the upgrade was delayed. So it does not seem to be a small problem that can be fixed quickly.

Category: Tenant Administration