← All postsRelease updates ยท 3 November 2026

The Business Central release wave checklist

Microsoft updates Business Central twice a year, in April and October, and you cannot opt out. The checklist we run with every customer before each release wave, from reading the release plan to the Monday after the update.

Business Central online gets a major release every April and October (2026 release wave 1 was version 28, wave 2 is version 29, and so on), with minor updates monthly in between. You cannot skip a major release; you can choose when within a window of roughly five months it lands. That window is the opportunity, and this is the checklist we work through with every customer, twice a year. The release tracker on the home page shows the current dates.

Eight weeks before: read and plan

  1. Read the release plan. Microsoft publishes it months ahead. Pick out the things that affect you: features switching on by default, Feature Management switches becoming mandatory, deprecations, and anything your extensions touch.
  2. Check the deprecations. Each wave retires something: an old API version, a report, a page-based SOAP endpoint, a field. If an integration or extension uses it, it breaks on update day. Grep the code; ask the ISVs.
  3. Check Feature Management. Features that were optional and are becoming mandatory are the ones that catch people out, because the business never switched them on and never tested them. List them.
  4. Pick your update date. In the admin centre, choose a date that is not month-end, not quarter-end, not peak season, and not the week the finance manager is on holiday. Early in the window is better if you are well-tested; late if you need the time. The deadline is the deadline: miss it and Microsoft updates you anyway.
  5. Tell the ISVs. Every add-on vendor needs to confirm their app is compatible with the new version and when the compatible version will be on AppSource. If one cannot, that is your update date constraint.

Six weeks before: sandbox

  1. Create a sandbox on the preview. A copy of production, on the new version, from the admin centre. This is where everything below happens.
  2. Compile your extensions against the new version. Warnings now are errors next time. Fix the breaking changes; schedule the obsoleted-object warnings.
  3. Install the ISVs' new versions in the sandbox and make sure they load, upgrade their data and do not clash with each other.
  4. Run the regression scripts. The same UAT scripts from the implementation, kept current: order to cash, purchase to pay, month-end, the warehouse, manufacturing, every integration. Super users run them, not consultants. It takes a day for most businesses.
  5. Test the integrations. Every API call, every e-document, every bank feed, every Power BI dataset, against the sandbox. API versions and permission sets change between waves.
  6. Switch on the new features you want in the sandbox and decide whether they go live with the update or later.

Two weeks before: prepare

  1. Release notes for your users. One page: what changes on screen, what is new, what to do if something looks wrong. Microsoft's release notes are thousands of lines; yours should be twenty.
  2. Train the super users on the two or three things that have visibly changed in their area.
  3. Freeze changes. No extension deployments, no configuration changes, no new ISV installs between now and the update, so that the sandbox you tested is the production you update.
  4. Confirm the date and the rollback. Microsoft can roll back a failed update automatically; you cannot roll back a successful one. Confirm the date with the business and the partner, and confirm who is on call.

Update day

  1. The update runs overnight in Microsoft's window; you get an email when it is done or if it failed. If it failed, Microsoft retries and tells you why; the usual cause is an extension that did not compile, which is why step 7 exists.
  2. Morning checks. Log in, confirm the version, run a sale, a purchase, a journal, a report, and every integration. Super users do their areas. Half an hour.
  3. Deploy anything you held back. The extension versions and ISV updates that needed the new platform.

The week after

  1. Watch the first month-end after the update. Report layouts and financial reports are where differences surface.
  2. Switch on the new features you chose in step 11, one at a time.
  3. Update the regression scripts with anything that changed, so the next wave starts from current scripts.
  4. Diary the next one. It is in six months. Put the eight-weeks-before date in the calendar now.

If you have not been doing this

Most businesses that run into trouble on a release wave were not doing steps 1 to 11; the update simply arrived. The first time through takes longer, mostly to write the regression scripts and get the extensions compiling clean. After that it is two or three days of effort twice a year, which is the price of a system that is always on the current version and never needs a big-bang upgrade again. Our health check covers the first pass, and we run release reviews as part of support. The tracker will tell you how long you have.

Talk to us
Want this done in your Business Central?
Book a 30 minute callGet the monthly newsletter

More from the blog