Customers using Windows Update for Business will lose some ability to delay the deployment of each new Windows feature release once version 1903 goes live.

When Microsoft first started delivering Windows 10 "as a Service" with a regular flow of feature updates, the company planned to have two release tracks: a "Current Branch" (CB) that was consumer-oriented and "Current Branch for Business" (CBB) aimed at enterprises. The CBB track would trail the CB one by a few months, with consumers acting as guinea pigs to iron out bugs before the quality of each release was deemed good enough for corporate customers.

That naming, though not the underlying concept, was changed in 2017 when Microsoft formalized the Windows 10 release schedule and settled on two feature updates per year, one in April and the other in October. The CB track became the "Semi-Annual Channel (Targeted)" (SAC-T), and when this was proven in the real world, it would be pushed to the "Semi-Annual Channel" (SAC), the replacement for CBB. Pro and Enterprise versions of Windows could be set to follow one track or the other, depending on how aggressively an organization wanted to adopt the feature updates. Machines that were set to SAC would automatically wait a few months after each SAC-T release, waiting for the SAC-T version to be blessed as SAC. Typically the gap has been about three months, even for the troubled version 1809 release.

However, "SAC-T" and "SAC" represented the same software on the same development track. Microsoft is ditching the SAC-T labelling and is now just using SAC for all. When version 1903 is released this April, the ability to choose between SAC-T and SAC will be gone.

What does this mean for organizations that used SAC to delay deployment of the feature updates? Installing version 1903 on systems currently set to use SAC-T (plus an optional deferral period) won't cause any change; the systems will update when the mainstream, consumer release is made, plus whatever deferral period they have set. Systems set to use SAC will be configured to defer the 1903 update by 60 days after the consumer release, plus whatever optional deferral period was specified. Microsoft says that this extra 60 days deferral will be handled server-side and won't be reflected in device configuration.

Moreover, that extra 60 day delay is only going to be imposed for version 1903. For subsequent versions, the deferral period will use its configured value and impose the delay relative to the feature update's initial availability.

This means that instead of there being a variable delay between the consumer (Targeted) and enterprise (non-Targeted) releases, with Microsoft able to choose exactly when each release is "good enough" for corporate users, organizations will now have to use a fixed deferral time after the consumer release. Given that Microsoft has taken longer than 60 days to promote previous Targeted releases to non-Targeted, the new policy seems surprisingly aggressive and ultimately less flexible than the current approach. If the most recent feature updates had been plain sailing, that might be justified—and it's certainly desirable that feature updates be good enough for corporate customers from day one. But after the brouhaha surrounding version 1809's release, withdrawal, and subsequent re-release, we can't imagine that administrators are going to be too pleased with this change.