Service update availability

Microsoft is committed to delivering predictable service updates. These service updates are made generally available for self-deployment before Microsoft automatically applies them. The timing of the package release for self-update relative to the production autoupdates varies. Customers can choose from two autoupdate windows that are four weeks apart for each service update. Organizations can select the update window that better accommodates their validation process and operational schedules. To determine the timing of self-update and autoupdates for upcoming releases, including the second autoupdate window see, Targeted release schedule (dates subject to change). To learn more about twice autoupdate window options, see One Version service updates FAQ.

Customers can take up to four service updates per year and are required to take a minimum of two per year. Customers can choose to pause one update at a time. A pause of a service update can apply to the designated user acceptance testing (UAT) sandbox environment, the production environment, or both environments. After the pause window ends, if the customer hasn't self-updated to a supported service update, Microsoft automatically applies the latest update, based on the configuration in Microsoft Dynamics Lifecycle Services. To learn more about how to pause service updates, see Pause service updates through Lifecycle Services.

Targeted release schedule (dates subject to change)

In the following table:

• An asterisk (*) in the "Release version" column denotes a major release.
• The "autoupdate schedule production start date" column refers to the autoupdate schedule that's configured in the update settings in Lifecycle Services. See Configure service updates through Lifecycle Services.
• The "End of service" column indicates the date when no new cumulative service updates are provided.

Service update overview

Service updates are continuous, touchless updates that provide new features and functionality. They eliminate the need to do expensive upgrades every few years. Because service updates maintain backward compatibility, there's no need to "merge your code." We recommend that you use tools such as the Regression suite automation tool (RSAT) for regression testing.

You're in control and manage how your organization receives these updates. For example, you can sign up for the First Release program so that your organization receives updates first. You can manually apply the updates to any of your environments (self-update). Alternatively, you can remain on the default release schedule and receive the autoupdates when you schedule them by using Lifecycle Services.

Service updates contain both application changes and platform changes that are critical to the service, including regulatory updates. For more information, see Service updates.

Release processes

The Dynamics 365 team designs, develops, and validates each new release. Extensive testing is done on various test topologies. A compatibility checker also runs tests to ensure backward compatibility.

All customers who take advantage of the preview have early access to the upcoming service update. The preview service update is used to validate customizations, learn about new features, and provide feedback to Microsoft. During the preview phase, customers must deploy the service update in a development/test environment. The preview release can't be used in production. After release, customers can download the package from the Shared Asset Library in Lifecycle Services. Customers must agree to the program terms at the time of installation. Sign up for access to preview packages is no longer required. One scheduled update to the preview build is included as standard with every release.

The First Release program is available to all finance and operations apps customers. There are two ways to participate: 

• Microsoft Managed Updates: Fill out the First Release Program: Microsoft Dynamics 365 Finance and Operations applications form and receive a service update that Microsoft automatically deploys, first in a UAT sandbox and then in production after seven days. It isn't possible to pause these updates. 

• Customer Initiated Updates: Customers can pull the First Release build into their UAT sandbox from Lifecycle Services for testing and into production, without autodeployment from Microsoft. 

Typically, the First Release build is the same as the generally available (GA) build. However, if critical issues arise that can't be fixed with a hot fix, a new First Release build is declared, and customers are informed through various communication channels, including Viva Engage and Lifecycle Services.  Microsoft restarts the sandbox and production environments and deploy any newly declared First Release build for customers that receive Microsoft managed updates.  Customers that initiate updates should deploy newly declared First Release builds that are available on Lifecycle Services. 

The service update is made generally available through the Action Center in Lifecycle Services. When the service update is available, customers can manually apply it to all environments, including production. If the service update isn't applied to the designated sandbox or production environment, Microsoft automatically applies it, based on the update settings for the Lifecycle Services project. To learn more, see Configure service updates through Lifecycle Services.