Business Central 2026 Release Wave 2: What's Changing and What US Businesses Must Do Before Go-Live

Most Microsoft Dynamics 365 Business Central updates arrive quietly and leave little trace. Release Wave 2 for 2026 is not that kind of update. Version 29.0 is a scheduled production rollout that introduces breaking changes, including the full retirement of SOAP web services, AI-embedded process shifts, and integration behaviour updates that will expose every untested customisation in your environment the moment it hits production.

For US businesses, the risk is straightforward: organisations that treat this as a routine auto-update will spend the weeks after go-live firefighting issues that a structured readiness process would have caught in advance.

This guide is built for the teams who want to get ahead of it. You will find a step-by-step preparation framework covering SOAP integration audits, extension validation against Version 29.0, end-user training requirements, and a pre-go-live sign-off checklist. It also addresses US-specific compliance and reporting implications that generic release notes rarely surface.

If your organisation runs Business Central and the production rollout is approaching, this is the preparation roadmap your project team needs before the deadline becomes the problem.

What Business Central 2026 Release Wave 2 Actually Is (And Why It Is Not a Routine Update)

Business Central 2026 Release Wave 2 ships as Version 29.0, and its defining characteristic is that it is not optional. Microsoft controls the production rollout schedule. Your organization receives a scheduled update with dates you can adjust within defined windows, but you cannot prevent the rollout from arriving entirely.

That distinction matters because Version 29.0 is not a patch. Minor updates adjust behavior at the margins. Version 29.0 removes legacy technology support and changes integration behavior at a structural level. Environments that have not been tested against it will not simply behave differently; they will break. Integrations built on deprecated endpoints will stop functioning. Extensions referencing removed platform objects will throw errors. The failure mode is hard, not soft.

Two categories of change drive that risk. First, Microsoft is retiring SOAP web services support for UI pages, a hard cutoff that severs any integration still calling those endpoints. Second, Wave 2 is expected to introduce AI-assisted capabilities in standard workflows; review the release notes for the modules your team uses daily to identify where user-facing behavior may change. Neither change is cosmetic.

If your organization has historically absorbed Business Central updates as background events handled quietly by IT, that approach will not survive Version 29.0. This update requires the same project governance applied to any ERP go-live: a defined readiness owner, a formal milestone schedule, and a sign-off gate that confirms the environment is validated before the production rollout reaches your tenant.

For organizations looking to build foundational context on how Microsoft's Dynamics 365 product family is structured and what Business Central actually covers, that grounding matters here, because Wave 2's scope extends well beyond a single module or feature set.

The sections that follow translate this into a concrete, sequential preparation process.

The SOAP Retirement: The Breaking Change Every CIO Needs to Understand

Of all the changes Version 29.0 introduces, the SOAP retirement carries the highest immediate risk for organizations with established integration landscapes.

Microsoft will permanently remove support for publishing UI pages as SOAP web services when Dynamics 365 Business Central reaches Version 29.0. This is not a deprecation warning with a future enforcement date. The moment Version 29.0 reaches your production tenant, any integration consuming those SOAP endpoints stops working.

Retail, manufacturing, and trading businesses are among those most likely to be affected, given that their integration architectures were often built during the era when SOAP was the predominant ERP connectivity standard. Those connectors were deployed, tested, and then largely left alone as long as they kept working. Many have never been migrated because nothing forced the issue until now.

The replacement path is REST and OData APIs. However, migration is not a find-and-replace exercise. It requires mapping each affected endpoint individually, rewriting authentication flows, and retesting every connected system end to end. The complexity scales with the number of integrations and the degree to which those systems are controlled by third-party vendors rather than internal IT.

The risk is also broader than the most visible ERP connections. Tools such as reporting solutions, document management systems, and workflow automation, any that were built against SOAP web service endpoints may be affected. Businesses in operationally complex environments, including the kinds of multi-tenant commercial and retail operations discussed in Business Central's capabilities for modern ERP environments, frequently discover SOAP dependencies in unexpected places during audit.

CIOs who have not yet produced an inventory of which systems are calling SOAP endpoints are already behind the timeline this remediation requires. The audit steps that follow translate that risk into a concrete action sequence.

What to Inventory Before You Begin the Readiness Audit

Before the audit itself begins, you need a structured baseline. Jumping straight into remediation without a complete inventory produces gaps that surface as production incidents after go-live.

1. Integration inventory

List every active integration connecting Business Central to an external system. For each one, document the direction of data flow (inbound, outbound, or bidirectional), the trigger frequency (real-time, scheduled, or event-driven), and the authentication method in use: SOAP, REST, OData, or file-based. This list is your remediation register. Missing one integration here means discovering it broken in production.

2. Customization and extension catalog

Document every active customization and extension in your environment. Flag whether each was built in-house, delivered by an implementation partner, or sourced from AppSource. The source matters because AppSource extensions require vendor confirmation of Version 29.0 compatibility. You cannot assume a published extension is ready. If the vendor has not published a compatibility statement, you need that confirmation in hand before testing begins.

3. Business process criticality ranking

Identify which business processes depend on automated data exchange, then rank them by operational impact. Payroll feeds, customer order imports, and financial reporting extracts are high-priority. Low-frequency batch jobs sit lower on the remediation queue. This ranking determines where your team spends time first.

4. Ownership mapping

For each integration, document who owns it technically inside your organization and who owns the connected third-party system commercially. SOAP-to-REST migrations that cross vendor boundaries may require contract amendments, third-party development work, and procurement cycles. Internal IT capacity alone will not be sufficient for those cases. Understanding this early prevents timeline surprises during remediation.

5. Sandbox readiness

Confirm you have a Version 29.0-compatible sandbox environment provisioned and available. No testing is valid unless it runs against the Wave 2 version. If your sandbox is not yet upgraded, that is the first action item before anything else proceeds.

Step 1: Run a Full SOAP Integration Audit Across Your Environment

With your inventory complete, the next action is to extract the raw SOAP exposure data directly from your Business Central environment.

Navigate to Web Services in your Business Central administration interface and pull the full list of published endpoints. Filter the results to display only SOAP-type services. That filtered list is your remediation register, every item on it represents a potential breaking point when Version 29.0 reaches production.

For every endpoint, identify which external system calls it, how frequently, and what data volumes it moves. Critically, pull last-used timestamps to separate live connections from orphaned configurations. Legacy Business Central environments commonly carry SOAP endpoints that were published years ago for integrations that no longer run; retiring those requires no migration work, only confirmation and documentation.

Once you have distinguished live from orphaned, classify each active SOAP integration into one of three categories:

• Migrate to REST: The external system supports REST and development capacity exists to remap the connection before go-live

• Replace with an AppSource connector: A supported, Version 29.0-compatible connector exists in AppSource and eliminates custom development

• Retire: The integration serves no current business process and can be decommissioned with business owner sign-off

For integrations that touch systems you do not control, contact the third-party vendor immediately. Vendor REST readiness, documentation quality, and available development capacity vary widely. Some vendors will require a formal change order before beginning any migration work, which adds procurement lead time you cannot compress later.

Log every finding in a structured audit register. Each row should carry an assigned owner, a target completion date, and any dependency flags that tie the remediation to your broader go-live sign-off checklist. This register becomes the single source of truth for Wave 2 integration readiness throughout the preparation period.

Step 2: Validate Every Customisation and Extension Against Version 29.0

With your SOAP audit register taking shape, the parallel workstream is your extension portfolio. Every customization installed in your Business Central environment needs a confirmed compatibility status before Version 29.0 reaches production.

Contact every AppSource extension vendor directly and request written confirmation of Version 29.0 support. Log each response in a single tracking document with three categories: confirmed compatible, update in progress with a committed date, and no published roadmap. That third category requires an immediate escalation decision, not a follow-up reminder.

For in-house or partner-built AL extensions, schedule a focused code review against Microsoft's published deprecated features in the application and the corresponding platform deprecation list. Reviewers should target AL code that calls deprecated objects, references SOAP-adjacent API patterns, or subscribes to platform events flagged as changed in the Wave 2 release notes. These are the failure points compilation alone will not catch.

Deploy Version 29.0 in a sandbox and run your full extension suite against it. Compilation errors appear immediately. Runtime failures in posting routines, approval workflows, and integration triggers require scripted test scenarios built around realistic transaction volumes. A sandbox test using five sample records will not surface the failure a 500-line journal entry batch will expose on day one in production.

Triage by business impact. Extensions touching financial posting, inventory management, and customer-facing processes take priority. Failures here carry direct operational consequences that can extend to revenue and reporting.

Build a compatibility status dashboard mapping each extension to its current remediation state: confirmed, in remediation, or blocked. Business stakeholders and IT leadership need a shared, current view of go-live readiness without requiring a technical briefing on every status call. One document, updated weekly, eliminates the ambiguity that stalls executive decisions.

Step 3: Build and Execute an Integration Validation Test Plan

With extensions validated, the next step is proving that your migrated integrations actually work end-to-end under realistic conditions.

For every integration converted from SOAP to REST, write explicit test cases covering the full data lifecycle: OAuth or API key authentication, payload structure, field mapping accuracy, error handling, and retry behavior under simulated failure conditions. Each of these dimensions can fail independently, and a passing authentication test does not guarantee accurate field mapping downstream.

Do not stop at happy-path testing. The scenarios that surface in production during the first week are edge cases: null field values passed from external systems, payloads at or beyond maximum size limits, duplicate record submissions triggered by retry logic, and out-of-sequence message delivery caused by network latency. Write and execute explicit test cases for each of these conditions before go-live, not after.

Test end-to-end, not just in isolation. Run integration tests in a Version 29.0 sandbox connected to staging instances of your external systems, including your ERP, your CRM, your payment processor, or any connected platform. Unit tests within Business Central alone cannot confirm that the full data pipeline behaves correctly across system boundaries. Cross-system validation is the only test that counts.

Include performance testing for high-volume integrations. REST endpoints carry different latency and throughput profiles than legacy SOAP connections. Batch jobs that previously completed within acceptable processing windows may require throttling adjustments, increased API call intervals, or pagination changes to remain viable under Version 29.0 behavior.

Document every test result formally, recording pass/fail status, the tester's name, and the date of execution. This record serves two purposes: it is the evidence base for your go-live sign-off, and it protects your organization if post-production issues require root cause analysis.

If your team needs a structured framework for this process, reviewing how experienced Microsoft Dynamics 365 partners evaluate integration readiness before go-live can sharpen the criteria you apply.

Step 4: Assess the AI-Embedded Process Changes and Their Impact on Daily Users

With integration validation complete, the next risk layer is behavioral. Wave 2 is expected to introduce AI-assisted capabilities in standard workflows; review the release notes for the modules your team uses daily to identify where user-facing behavior may change. Most users will not receive a notification explaining that the underlying process has changed. That gap between platform reality and user expectation is where post-go-live escalations originate.

For each AI-assisted feature shipping in Wave 2, identify the business processes and user roles it touches, then classify the change as either additive or substitutive. An additive change introduces a new capability alongside an existing step; the user can adopt it or ignore it without breaking anything. A substitutive change replaces or alters a step the user currently performs manually, meaning the old behavior is gone and the user must adapt. Substitutive changes carry the higher risk and require earlier action.

Prepare role-specific documentation for substitutive changes before go-live. Updated process documentation and one-page quick reference guides, scoped to the affected role, should be ready before the production rollout date. Users who encounter unexpected screen behavior during peak periods, month-end close for example, will either work around the new feature or log it as a defect. Both outcomes are avoidable with pre-distributed guidance.

Brief process owners, not just end users. Department leads and process owners should understand what will look or behave differently from day one. This is not a full training cycle; it is a targeted briefing that gives the people responsible for each workflow enough context to answer questions from their teams without escalating everything to IT.

Build a structured feedback channel for the first 30 days post-go-live. Without a dedicated intake mechanism, AI-related friction surfaces as scattered helpdesk tickets that appear unrelated, masking a broader adoption pattern that would be visible if captured together. A simple shared log or brief daily standup during the hypercare window is sufficient to detect systemic issues early.

Step 5: Execute Targeted End-User Training Before the Production Cutover

Segment your audience before you build a single slide deck. Finance users navigating reporting changes in Microsoft Dynamics 365 Business Central need different content than warehouse staff adjusting to AI-assisted pick suggestions. A single all-hands session dilutes both groups' learning and wastes time on changes that are irrelevant to half the room.

Train power users and team leads first, and train them differently. These individuals will absorb the first wave of colleague questions after go-live. They need to understand what changed in Version 29.0 and why, not just how to click through updated screens. A team lead who can explain the rationale behind a changed approval workflow deflects far more support tickets than one who can only say "it looks different now."

Use a Version 29.0 sandbox loaded with your own environment's data, not a generic demo tenant. Users who practice against their actual item numbers, customer records, and posting groups encounter realistic friction during training rather than in production. They also ask sharper pre-go-live questions, surfacing configuration gaps while there is still time to fix them. Training structured around client-specific sandbox environments addresses this directly.

Schedule sessions two to three weeks before production cutover. This window keeps knowledge fresh while preserving enough runway to act on issues that training uncovers. Training completed six weeks out risks retention decay; training completed three days out leaves no remediation time. Business Central implementations typically span several months, and the training window is a small but critical slice of that timeline.

Record attendance and completion as formal go-live sign-off criteria. Undertrained user populations generate post-go-live support surges that are routinely misdiagnosed as technical defects, delaying root cause resolution and eroding confidence in the update.

US-Specific Considerations: Compliance, Reporting, and Industry Implications

Beyond training, US businesses face compliance and operational risks that are specific to their regulatory environment and integration ecosystem.

Sales tax integrations warrant early confirmation. If your organisation uses a third-party sales tax connector such as Avalara or Vertex, confirm with that vendor that the integration has been tested against Version 29.0 before your rollout. A gap in sales tax reporting creates operational and potentially compliance risk.

Regulated industries should review release notes carefully. Healthcare-adjacent services, food manufacturers, and financial services firms should review the Wave 2 release notes for any changes to audit trail behavior, document posting logic, and approval workflow structures, and assess whether those changes affect how they meet federal and state reporting obligations.

Retail and e-commerce connector compatibility should be confirmed. Businesses running connectors to platforms such as Shopify, BigCommerce, or Amazon Marketplace should confirm with their connector vendors that the current version has been tested against Version 29.0. Connectors that have not been updated may rely on endpoints affected by the SOAP retirement.

Manufacturers should test complex production scenarios in sandbox. Organisations using Business Central for production order management and materials requirements planning should run their most demanding production scenarios through a Version 29.0 sandbox, particularly if AI-assisted scheduling or demand forecasting features are included in the new release.

Multi-entity configurations require dedicated intercompany testing. US businesses with intercompany posting and consolidation routines should test those routines specifically in Version 29.0. Integration behavior changes in multi-company environments can generate reconciliation errors that are difficult to trace once they reach production.

The Pre-Go-Live Readiness Checklist: Your Sign-Off Gate Before Wave 2 Hits Production

Once your US-specific compliance and integration risks are mapped, every finding needs a formal status before production opens. Use this checklist as your sign-off gate. No item closes until the evidence exists, not just the intention.

☐ SOAP audit complete Every active SOAP endpoint is identified and resolved (the three categories established in Step 1: migrate, replace, or retire), with formal business owner sign-off on any retirement decisions. An unresolved endpoint is an open break.

☐ Extension compatibility confirmed Every AppSource and custom extension in your production environment holds one of three statuses: a Version 29.0 compatibility confirmation from the vendor, a tested and approved update deployed to your sandbox, or a written remediation plan with a completion date that precedes the scheduled production rollout. No extension without a status ships to production.

☐ Integration test plan executed and passed All migrated integrations have completed end-to-end testing in a Version 29.0 sandbox. Results are documented with tester name and date. No critical or high-severity defects remain open. Happy-path pass results alone are insufficient; edge-case and failure-mode scenarios must be included.

☐ AI process change briefings completed Every department lead and process owner has been briefed on the AI-assisted workflow changes relevant to their area. Updated process documentation is available and reviewed before cutover, not queued for post-go-live.

☐ End-user training completed All affected user groups have completed role-appropriate training on a Version 29.0 sandbox loaded with representative data. Attendance records are logged. Feedback from training sessions has been reviewed and any resulting action items are resolved or formally accepted as post-go-live items with named owners.

☐ Hypercare plan in place A defined support structure covers the first 30 days post-go-live. It includes escalation paths for integration failures, a named technical contact reachable for critical incidents, and a structured feedback loop for AI-related user experience issues so patterns surface before they become crises.

Treat any unchecked item as a go-live blocker. A partial checklist is not a reduced-risk launch; it is a deferred incident.

Where Organisations Fail: The Most Common Wave 2 Preparation Mistakes

Even organisations that complete the checklist above fall short when preparation is structured around the wrong assumptions. These are the failure patterns that surface most consistently.

Treating Wave 2 as an IT-only event. SOAP retirement and AI-assisted process changes alter how finance teams close periods, how operations staff process orders, and how department heads review approvals. Organisations that route all preparation through IT and brief business leaders only at go-live create user adoption failures that are entirely avoidable. Finance leads, operations managers, and department heads need seats in the preparation process from the start, not a demo the week before cutover.

Underestimating third-party vendor timelines. Vendor timelines for REST migration can extend well beyond what internal teams expect, often spanning multiple weeks of scoping, development, and joint testing. Opening vendor conversations too late leaves no room to absorb that lead time before go-live.

Testing in the wrong environment. Validating extensions and integrations against a pre-29.0 sandbox produces false confidence. Compilation may succeed, but runtime behavior under Version 29.0 can differ materially. Every readiness test must run in an environment confirmed to be on the Wave 2 version.

Ignoring low-frequency integrations. Month-end financial extracts and quarterly reporting feeds rarely appear on a daily-operations-focused audit. A broken extract discovered on the last working day of the month triggers a crisis whose severity is entirely out of proportion to its technical complexity. Audit by calendar cycle, not just by daily transaction volume.

Skipping the hypercare plan. Without a defined escalation path and a named technical contact for the first 30 days, routine post-go-live surprises become unnecessary crises. Plan the support structure before go-live, not after the first incident.

What to Do Now: Turning This Guide Into an Active Preparation Timeline

Knowing the failure patterns is not enough. The remaining risk is failing to act on them before the calendar runs out.

Start the SOAP integration audit this week. The audit itself takes days; what it uncovers can take months to resolve. Vendor negotiations, third-party development work, and end-to-end integration testing collectively consume the majority of preparation time, and none of that work can begin until the audit identifies what needs to be fixed. Every week spent waiting is a week removed from remediation capacity.

Assign a named Wave 2 readiness owner immediately. This person is not a project coordinator; they need the authority to escalate directly to the CIO level when vendor timelines slip or extension compatibility issues exceed internal resolution capacity. Without a single accountable owner, critical blockers stall in group inboxes while the scheduled rollout date advances.

Bring in external capacity if your internal team cannot run a Version 29.0 sandbox validation. A structured readiness assessment from an experienced Dynamics 365 Business Central implementation partner like Index of Solutions applies a proven audit framework from day one, compressing the timeline that an internal team would spend building methodology before executing it.

Set two formal readiness review meetings now: one at four weeks before the scheduled production rollout date and one at two weeks. Use the checklist in this guide as the agenda for both. Every sign-off gate item must have a named owner and a visible status before either meeting concludes. Organisations that run these reviews reactively, after problems surface in production, consistently spend more time and money than those that run them proactively as structured gates.

Conclusion

Business Central 2026 Release Wave 2 is a structural shift, not a routine update, and US organisations that treat it as one will face costly production disruptions. The SOAP retirement alone creates breaking-change risk that demands immediate action. Every customisation, integration, and user workflow requires validated compatibility against Version 29.0 before go-live.

The path forward is clear: start your audit now, assign a named readiness owner with real authority, and use the checklist in this guide as your formal sign-off gate. Do not wait for sandbox access to begin the work you can start today.

Organisations that prepare with structure and urgency will absorb this wave confidently. Those that delay will absorb the consequences instead. The production rollout date is controlled by Microsoft's schedule; your preparation window is not. Start this week.