Business Central 2026 Release Wave 2 (v29): What to Retest, Not Just What’s New

Business Central 2026 release wave 2 29.0 became generally available at the end of September, and every online environment has until February 2027 to schedule the move. The launch was enormous: one Business Central MVP who indexed Microsoft’s 38 launch-event videos counted 319 features.

Every partner blog has now published its version of that list. None of them answers the question an administrator actually has on update day: what works today and will behave differently tomorrow?

That answer isn’t in the new features. New features are mostly opt-in, and the ones that aren’t only affect people who use them. Regressions come from four other lists, which Microsoft publishes in four different places: what’s removed, what’s switched on for everyone, what changes inside features you already use, and what’s coming out next. This article puts those lists in one place and turns each into a retest plan for Business Central 2026 release wave 2.

A NOTE ON THE NAME Microsoft retired the twice-yearly release-wave announcement model for Dynamics 365 and Power Platform on 25 August 2026, in favor of a continuously updated roadmap. Business Central’s documentation still calls 29.0 ‘2026 release wave 2’, and that isn’t a contradiction. What Microsoft retired was the way updates are announced, not the April and October major-update cadence. v29 shipped on the schedule it always would have. What’s gone is the twice-yearly plan document, which makes the change lists below more important to read, not less.

Why “What’s New” Is the Wrong List to Test From

Three reasons. First, most new capabilities do nothing until someone turns them on, so they carry no update-day risk. Second, the list itself is unreliable as a test plan. The same MVP’s count found 178 features shown in the launch videos but not documented, and 46 where the video and the documentation disagree about whether a feature is generally available or still in preview.

Third, and most important, the changes that break things are rarely described as features at all. A removed endpoint is a line on a deprecation page. An optional feature turning mandatory is a row in a feature-management table. Neither makes the launch keynote.

The five sections below follow this table, highest risk first.

1. What Stops Working: SOAP on Microsoft Pages

This is the one change in v29 that produces a hard failure on update day.

Since version 26, Business Central has blocked SOAP web services on Microsoft’s own UI pages by default, with a feature switch that let administrators turn them back on while they migrated. Version 29 makes the block mandatory. Microsoft’s deprecation register lists SOAP endpoints for Microsoft UI pages as removed in 29.0, and there’s no longer a setting that restores them.

Microsoft’s reasoning explains the whole category, so it’s worth quoting:

“A UI page isn’t an API, so changes to them can happen in a release without being considered a breaking change.”

Publishing a standard page as a web service always meant building an integration on something Microsoft never promised to keep stable. v29 is where that bill arrives. Any integration that reads or writes Business Central data through a standard page over SOAP fails on update day. Bank portals, EDI hubs, warehouse scanners and in-house reporting tools are the usual suspects. SOAP on code units, and on pages hosted in your own extensions, still works for now. Microsoft has said full SOAP support will go in a later release, without naming one.

THE TRAP IN THE OBVIOUS FIX The quickest migration is to switch the same Microsoft page from SOAP to OData. Don’t. Microsoft’s deprecation register also lists OData endpoints on Microsoft pages for removal in version 30.0, the next major release, in April 2027. Moving to OData on the same page buys about six months and a second migration. The durable routes are Business Central’s standard API pages, or a copy of the page hosted in your own extension, which is Microsoft’s documented route for teams that need the page’s exact shape.

Finding your exposure takes ten minutes. Open the Web Services page, filter for published page objects with a SOAP URL, and separate Microsoft’s standard pages from pages in your own extensions. Every standard page on that list is an integration to fix before update day. While you’re there, note the standard pages published with an OData URL: that’s your v30 list.

Then test each replacement the way the integration will be judged: not on whether the call returns success, but on whether the right records land with the right values API contract testing on the other side.

One on-premises change belongs here too

Version 29.0 removes the option to run with only data-defined permission sets (UsePermissionSetsFromExtensions set to false). Installations still relying on it must move to permission sets defined in extensions before upgrading. Then retest every role that matters, because permission gaps fail for the clerk, not the administrator. On-premises deployments on version 24 or earlier must upgrade to version 25 before they can move to 29.

2. What Switches On for Everyone: Six Features Leave Feature Management

Business Central ships many behavior changes as optional features in Feature Management. You can switch them on early to try them, and at a set release they become mandatory and switch on for everyone. In v29, six make that move. If any of them is still off in your production environment today, update day is when you’ll first see its behavior.

Two of these deserve a closer look.

• Manual flushing. Microsoft’s release plan describes this as omitting the warehouse pick for manual flushing methods. If the pick was acting as a control over component consumption, as it is in many warehouses, check that your process still enforces what you need it to.
• Masking sensitive data. Sensitive fields can display masked in the interface. Check the screens people rely on, and anything that reads values from the screen: Page Scripting recordings, RPA bots and UI-level automated tests will see the mask, not the value.

The practical step is the cheapest one in this article. In a sandbox copied from production, open Feature Management, enable the six (some may already be on), and run the processes in the right-hand column. Anything that changes there would have changed in production on update day.

3. What Changes in Place: Behavior You Already Depend On

These changes don’t break anything on update day. They change the result the next time a process runs, which is harder to notice, and more expensive when nobody does.

The Payables Agent matches differently

Version 29 improves how the Payables Agent matches vendor invoices to purchase orders. ‘Improves’ is an average across Microsoft’s test data. What matters is your edge cases: partial receipts, price variances, invoices that span several orders, vendors who quote the wrong PO number. Re-run a representative set through the agent in a v29 sandbox and compare its matches with what it decided on v28. A changed decision on a supplier invoice where people still belong in the agentic testing, whether or not anyone wrote code.

While you’re there, recheck agent permissions. v29 also changes how they’re managed, and an agent with broader access than intended is a control problem, not a convenience.

Shopify order handling

If you sell through the Shopify connector, v29 changes how it handles order edits, exchanges, refunds, returns, and B2B catalogs and pricing, and it adds controls over when sales documents are created. Re-run an order import through to a posted invoice, plus a refund and a return, and check the documents and amounts that result.

Warehouse and manufacturing

Direct transfer orders can now be posted from warehouse-enabled locations, subcontracting can use inventory put-aways and picks, and quality inspections and manufacturing documents have changed. Combined with the flushing change in section 2, any warehouse running production should retest consumption, transfers and subcontracting end to end.

Reports and documents

Financial report changes are now always logged, report layouts have a managed lifecycle, Microsoft has reduced the complexity of report datasets, and the Word add-in has changed. The new document report experience itself stays off until you enable it. But custom layouts for invoices, order confirmations and reminders are what customers actually see, so print and send one of each from a v29 sandbox before go-live.

Platform and performance

Under the surface, v29 changes the data model for table extensions so data loads faster, lets developers turn indexes on and off in AL, and lets administrators turn SIFT indexes on and off. None of that should change a result, but all of it can change speed. Time the list pages and reports your teams use most against v28, especially on tables your extensions extend. Treat any SIFT index change as a change request, because Flow Field totals depend on them.

Dataverse integration

v29 adds the ability to map new testing power platform and Dataverse fields. If you synchronize with Dataverse or Dynamics 365 Sales, re-run synchronization for your mapped tables after the update and check the coupled records themselves, not the job status.

4. What Doesn’t Change until Someone Enables It

Several of v29’s headline features stay off until someone turns them on: Accelerated Depreciation, the new document report experience, the Microsoft Copilot chat experience (preview), the Expense Agent’s new capabilities (preview), finance previews such as multiple excise duties per item and withholding tax on employee transactions, and EDI document exchange in e-documents (preview).

None of these needs retesting on update day. Each one needs retesting on the day someone switches it on, and in most companies that’s a power user on an ordinary afternoon, not a change-controlled event. Add ‘enabling a feature in Feature Management’ to your change-control list and treat it like any configuration change, because that’s what it is.

5. What’s coming out in v30: Test Now, Not in April

Microsoft has already published v30’s removals. The v29 sandbox is the cheapest place to find your dependencies on them.

A note on Peppol: Microsoft’s application deprecation page lists the change under 2027 release wave 1, though its text also mentions version 29.0. Either way, BIS 3.0 Business central e-invoicing testing is the only safe target now, and most Peppol networks have already moved to it.

The Business Central v29 Testing Checklist

Ten checks, in the order that protects update day first.

How Sofy helps

Sofy’s Dynamics 365 test agents are built for releases like v29, where there’s a lot of change and little of it is announced as change.

• Integrations are validated at the data layer. When a SOAP integration moves to an API page, Sofy checks that the right records arrive with the right values, not that the endpoint answered.
• Tests are written as outcomes, so interface changes don’t break them. A test that asserts the consumption was posted, the reminder was sent with the right text, or the report total reconciles doesn’t care whether a field is now masked or a page has moved.
• Agent decisions get checked, not just counted. Sofy confirms which purchase order the Payables Agent matched, and flags when that decision differs from the v28 baseline.
• Coverage runs before your update date zero-day validation. Point the same set at a v29 sandbox and you know what changed before production does.

What Microsoft’s own v29 tooling adds

Two of v29’s developer features are worth knowing about. Page Scripting is now generally available, giving you a free recorder for replaying a click path, which is useful for quick smoke checks. It records actions versus intent, so it carries the same maintenance cost as every recorder when the interface moves. v29 also lets developers run AL tests from the command line and in CI/CD pipelines, and build data-driven test suites. That’s good news for teams testing their own extensions.

Neither tool checks that a business process still produces the right result after an update. That’s the layer Sofy covers. And neither replaces the work only you can do: asking your ISVs whether their apps are ready, and deciding which opt-in features the business actually wants.

Frequently Asked Questions

When is Business Central 2026 release wave 2 (v29) available?

Version 29.0 became generally available at the end of September 2026. New online customers get it straight away. Existing online environments are notified and can schedule the update within a five-month window that runs to February 2027. On-premises installations on version 24 or earlier must upgrade to version 25 first.

What breaks in Business Central v29?

The hard failure is SOAP: SOAP endpoints on Microsoft’s standard UI pages stop working, with no setting to restore them. On-premises, the option to run with only data-defined permission sets is removed. Six optional features also become mandatory, which changes behavior in manufacturing flushing, financial reports, reminders and sensitive-data display.

Can we re-enable SOAP on Microsoft pages after updating to v29?

No. The feature switch that allowed it is gone. Use Business Central’s API pages, or host a copy of the page in your own extension and publish that. Avoid moving to OData on the same Microsoft page, because OData endpoints on Microsoft pages are scheduled for removal in v30. SOAP on codeunits and on your own extension pages still works for now.

Which features become mandatory in BC v29?

Six: ‘Manual’ flushing method without requiring pick; default values for financial reports; new communication texts for reminder terms; disabling SOAP web services on Microsoft UI pages; UI support for masking sensitive data; and per-activity-code VAT settlements (Italy only).

Is v29 still called a release wave?

Yes. Business Central’s documentation calls 29.0 ‘2026 release wave 2’. Microsoft retired the twice-yearly release-wave announcement model in August 2026, but Business Central’s April and October major-update cadence continues unchanged.

How should we approach Business Central v29 testing?

Start with what can fail on update day: find standard pages published as SOAP, and enable the six newly mandatory features in a sandbox copy. Then retest the in-place changes that touch your processes, such as Payables Agent matching, Shopify, reports and performance. Check results at the data level rather than on screen. The ten-point checklist above sets out the order.

The Bottom Line

v29’s launch was about agents, developer tooling and 319 features. The part that decides whether your update day is quiet was much smaller, and Microsoft spread it across a deprecation register, a feature-management table and a line about the Payables Agent.

Read those, not the keynote. Fix the SOAP integrations before your update date, turn on the six mandatory features in a sandbox while you still have time to react, and rerun the processes where Microsoft changed behavior without changing anything you’d recognize as a feature. Then use the same sandbox to find your v30 dependencies, because the next list has already been published.