Microsoft Dynamics 365 Business Central received a long list of changes during 2025. For development teams, however, the value of the release was not the length of that list. The useful changes were the ones that made extensions easier to refactor, integrations safer to test and production problems quicker to trace.
That distinction matters when an organisation is planning a Business Central upgrade. A release plan describes what Microsoft intended to deliver. It does not tell you which features apply to your tenant, whether every extension will remain compatible or how an integration will behave under your own transaction volumes and security controls.
The original version of this article focused mostly on Business Central 2025 release wave 1, also known as version 26.0, which became generally available in April 2025. This updated guide keeps that focus. It explains what changed for AL developers, application publishers, administrators and reporting teams, then translates each change into the practical questions a technical team should ask before deployment.
Three key takeaways
- 1.The strongest 2025 changes reduced lifecycle risk. Controlled movement of tables and fields, better build metadata and richer telemetry made mature Business Central extensions easier to maintain and investigate.
- 2.Integration testing became more realistic. Developers could mock outbound HttpClient calls and test failure paths without depending on a live external service or consuming Azure OpenAI tokens during every test run.
- 3.An update still needs engineering discipline. Sandbox validation, automated tests, extension compatibility checks, permissions review and an agreed rollback route remain essential for a dependable Business Central upgrade.
What did the Business Central 2025 release actually cover?
Business Central normally advances through two major release waves each year, alongside monthly updates. The 2025 release wave 1 plan covered far more than development: it also included application, e-commerce, reporting, governance, sustainability, service and Copilot-related work. The source article selected a narrower group of developer and platform features from version 26.0.
It is worth keeping that boundary clear. Profile extension objects, for example, arrived in the 2024 release wave 2 development work and remained relevant in 2025, but they were not a new Business Central 2025 wave 1 capability. Likewise, broad claims about faster SQL, cloud load balancing or manufacturing AI should not be attributed to this release without a specific Microsoft feature and tested evidence from the customer's environment.
Microsoft's historical Business Central 2025 release wave 1 plan and the version 26.0 update notes provide the most reliable starting point for checking the original delivery dates and feature descriptions.
The development changes at a glance
- Extension refactoring What changed: Move tables and fields, with their data, between partner extensions through a controlled upgrade process.. What the team should examine: Treat the change as a data migration with dependency and rollback planning.
- Testing What changed: Mock outbound AL HttpClient calls and control which requests a test is allowed to send.. What the team should examine: Test timeouts, authentication failures, throttling and malformed responses, not just the happy path.
- Diagnostics What changed: Capture client add-in exceptions in telemetry and expose build information for extensions.. What the team should examine: Agree alert rules, retention, access and ownership before an incident.
- Developer workflow What changed: Select extensions from the web client to open in Visual Studio Code and search downloaded symbols.. What the team should examine: Source visibility still depends on IP protection and user permissions.
- Integration security What changed: Validate server certificates for outgoing AL HttpClient calls and simplify App Key Vault onboarding.. What the team should examine: Remove insecure endpoints and establish secret rotation and least-privilege access.
- Reporting What changed: Use the UserControlHost page type for a cleaner embedded Power BI experience and new report-layout properties.. What the team should examine: Confirm licensing, data permissions and report ownership separately from the user interface.
Refactoring extensions without leaving the data behind
Business Central extensions often begin as a single application because that is the quickest way to deliver an initial scope. Over time the codebase grows. Separate functional areas acquire different release cycles, customers use different combinations of features and one monolithic extension becomes harder to test or deploy safely.
Version 26.0 extended Microsoft's controlled process for moving tables and fields, together with their data, to partner extensions. That made it possible to split a mature application more cleanly without asking customers to export and re-import the affected information by hand. For an ISV or Business Central integration partner, this was one of the most consequential technical changes in the release.
Microsoft describes the feature as a way to release and take ownership of tables or fields during an extension upgrade. The capability had existed for Microsoft's first-party apps and was opened to partner extensions in this release.
The word controlled is important. Moving a table is not a routine copy operation. Object ownership, application IDs, dependencies, upgrade code, schema synchronisation and the order in which apps are published all have to agree. A failed sequence can leave an extension unable to install or an upgrade unable to complete. The team should test the full route against a representative database, including uninstallation and rollback behaviour, before using it with production data.
Profile extensions were a useful foundation, not a new 2025 feature
The original article also highlighted profile extension objects. They do matter: they let a developer adjust properties of a profile defined by another extension and add page customisations without copying the whole profile. This can reduce duplicated code and make role-based user experiences easier to maintain.
They belong to the 2024 release wave 2 story, however. In a 2025 retrospective they are better presented as part of the extensibility foundation on which later work continued. Keeping release attribution accurate may seem minor, but it prevents an upgrade business case from being built around functionality that a customer already has.
The current Microsoft Learn guidance for designing Business Central profiles explains what a profile extension can override and how page customisations are applied.
Testing outbound integrations without calling the real service
A Business Central integration is rarely difficult because an HTTP request can be sent. The difficult work is proving what the extension does when the other system returns a 401 response, times out, supplies incomplete JSON, throttles the caller or succeeds after a retry. Tests that depend on a live service are slow, fragile and capable of creating unwanted records outside the test environment.
Business Central 2025 release wave 1 introduced a supported way to mock outbound HttpClient calls. An AL HttpClientHandler can inspect the request and return a defined response while TestHttpRequestPolicy controls whether outbound traffic is blocked, permitted from a handler or allowed more broadly. A development team can therefore test both expected and exceptional responses without making the real network call.
The exact code image from the original article. It illustrates an AL handler returning a controlled 401 response during an integration test.
Microsoft's mocking guidance for outbound HttpClient calls shows how handlers simulate responses. Microsoft also notes that the approach is useful when testing Business Central Copilot or AI features because tests do not need to connect to Azure OpenAI Service and consume tokens.
Mocking should make a test suite more demanding, not merely more convenient. The useful cases are the awkward ones: expired credentials, certificate failures, duplicate submissions, rate limits, partial responses and a remote service that becomes available again after an interruption. The production integration also needs idempotency, useful error messages and a route for replaying failed work without posting the same transaction twice.
Telemetry and build metadata improve incident response
When a user says that Business Central 'stopped working', the technical team needs more than a screenshot. It needs to know which environment and company were involved, which extension or add-in failed, the client type, the error details and the build that was running at the time.
In version 26.0 the Business Central client began emitting a telemetry event when an exception occurred in a client add-in. Microsoft lists the environment, company, extension or add-in, client type, error information and affected user among the available context. That can shorten the path from a vague report to a reproducible defect, provided somebody is monitoring the telemetry and knows what should trigger an alert.
The release-plan page for client, app and add-in telemetry records general availability from 1 April 2025.
The same release also surfaced Build information on an extension's details card in Extension Management. Source metadata had appeared earlier; the 2025 change added the build agent and a URL for the relevant build-system invocation. When an AL extension is produced through a proper DevOps pipeline, that link can connect a production incident to the repository, commit and build that created the package.
Microsoft's explanation of build metadata in Extension Management also makes the release history clear: Source and Build properties began in 2024, Source became visible in the client in 2024 release wave 2 and Build information followed in 2025 wave 1.
Metadata only helps if the delivery pipeline writes it consistently. An extension built on a developer's laptop, renamed manually and uploaded without a traceable artefact will still be difficult to support. A Business Central support partner should be able to show how an installed version maps to source control, automated tests, approvals and a deployment record.
A shorter route from Business Central to Visual Studio Code
Microsoft had already introduced the ability to open Visual Studio Code from a particular Business Central environment. The 2025 update made the route more useful by allowing a developer to select the extensions to include in the project from the Extension Management page.
The resulting project always includes symbols for the selected extensions. Source code is available only when the extension's IP protection settings and the user's permissions allow it. This is a sensible boundary: troubleshooting becomes quicker without assuming that every developer is entitled to inspect a publisher's source.
The exact Visual Studio Code image from the original article. Selected extensions can be downloaded into a development project as source or symbols, subject to permissions and IP protection.
Microsoft's feature description for selecting extensions to open in Visual Studio Code records general availability from 1 April 2025 and explains the difference between source and symbol access.
Searchable symbols and GitHub Copilot context
Downloaded symbol packages also became easier to search through Open Symbol by Name in Visual Studio Code. A developer can find related AL objects across dependencies, inspect the available definition and, where source is present, use that context while working with GitHub Copilot.
This can reduce time spent hunting through a large extension estate, but it does not turn generated code into reviewed code. Suggestions still need to be checked against the target runtime, the extension's data model, permission sets, performance behaviour and the team's coding standards. Copilot can help locate a pattern; it cannot approve the architecture or own a production defect.
The Microsoft release note for searchable app symbols describes the search and context behaviour and dates it to April 2025.
Stronger defaults for integration security
An outbound AL HttpClient call crosses a trust boundary. If the endpoint's server certificate is invalid, expired or issued for a different host, the safe response is to stop the connection and investigate. Business Central version 26.0 made server-certificate validation the default for outgoing HttpClient calls and added telemetry for validation failures.
The original 2025 implementation allowed an app or per-tenant extension to disable validation for a particular call. Microsoft later tightened that position: its current documentation says certificate validation is always enabled from version 27 and cannot be switched off. That is a useful example of why an older release article should be read alongside the current runtime guidance.
Microsoft documents the change and the version 27 restriction on the page for AL HttpClient server-certificate validation. A failed validation should lead to a certificate or endpoint fix, not an attempt to weaken transport security.
Self-service Azure Key Vault onboarding for AppSource publishers
AppSource apps can use secrets held in an Azure Key Vault owned by the publishing partner. Before the 2025 change, onboarding involved a manual Microsoft registration step and could delay availability. Business Central 2025 release wave 1 moved the registration into the AppSource submission process so an approved app could use its vault without the same email-based wait.
Microsoft's self-service App Key Vault onboarding guidance explains the permission required for the Business Central ISV Key Vault Reader application and the reserved AllowedBusinessCentralAppIds secret used to identify permitted app IDs.
Self-service onboarding removes an administrative delay; it does not remove secret-management work. Publishers still need clear vault ownership, least-privilege access, rotation, expiry monitoring and a response plan if a secret is exposed. No secret should be placed in source code or copied into a support ticket simply because the application can retrieve it at runtime.
Reporting changes: cleaner embedding and safer layout evolution
The 2025 wave also included two smaller reporting changes that are useful when they solve a defined problem. The new UserControlHost page type gave embedded Power BI content a slimmer Business Central interface. It removed controls that did not apply to an embedded report, tightened spacing and added navigation and fit controls.
Microsoft's page on the new embedded Power BI experience records general availability from April 2025 and explains how UserControlHost differs from the older Card-page approach.
That improves the viewing experience, but it does not resolve the harder parts of Business Central Power BI delivery. The organisation still needs a trustworthy semantic model, agreed measures, secure access to the underlying data, refresh monitoring and a named owner for the report. A cleaner frame cannot correct a disputed definition of margin or an unreliable data pipeline.
Developers also gained the ObsoleteState and ExcelLayoutMultipleDataSheets properties for report layouts. ObsoleteState helps mark a layout for future retirement. ExcelLayoutMultipleDataSheets allows a particular layout to use multiple sheets without changing the report-level setting and risking existing user layouts. These are modest features, but they support a more controlled reporting lifecycle.
The detail is set out in Microsoft's page on new Business Central report-layout properties. Teams should document who owns each custom layout and how users will be moved away from anything marked obsolete.
What the release did not guarantee
The source article used broad phrases about optimised SQL performance, enhanced load balancing and greater scalability. Those may sound plausible, but they are too general to guide an upgrade decision. Business Central performance depends on the application code, data volume, keys, FlowFields, queries, background tasks, reports, integrations and the pattern of concurrent work in the customer's environment.
A version upgrade can deliver platform improvements and new profiling options, yet it cannot automatically repair an extension that reads far more data than it needs or an integration that creates avoidable locking. The right approach is to capture a baseline, reproduce the important workloads in a sandbox and compare telemetry before and after the change. If a process is slow, the team should identify the AL object, database activity and user action involved instead of assuming that the cloud service needs more capacity.
Practical test: Choose several representative workloads, such as posting a large order, running a month-end report and processing an integration batch. Record duration, failures and telemetry on the current version, then repeat the same work in the upgraded sandbox.
How to assess a Business Central upgrade
A Business Central upgrade should be treated as a controlled change to a live business system. The release notes help with discovery, but the real scope sits in the customer's extensions, integrations, permissions, reports and operating calendar. A useful readiness review follows a small number of evidence-led steps.
- 1.Confirm the actual starting point. Record the tenant version, environments, installed apps, per-tenant extensions, runtime targets and the integrations that exchange business-critical data.
- 2.Map relevant release changes. Separate features that are automatically enabled from those that require setup, licensing, administrator action or a later application update.
- 3.Build a representative sandbox. Use realistic configuration and sanitised data so tests exercise the same extension combinations, dimensions, posting rules and document volumes as production.
- 4.Test processes and failure paths. Cover finance, purchasing, sales, inventory, manufacturing, reporting and integrations, including retries, permission failures and external-service interruptions.
- 5.Plan deployment and early-life support. Agree the change window, owners, communications, monitoring, rollback decision and the evidence needed to declare the Business Central update stable.
For customers with a heavily customised Dynamics NAV or older Business Central estate, the exercise may become a wider Business Central migration or modernisation programme. In that case, preserving every historical customisation is rarely the best objective. The technical team should decide which requirements remain real, which are now covered by standard capability and which custom extensions still earn their cost of ownership.
What should be rechecked in 2026?
A 2025 release article is useful as a technical record, but it should not be used as a current availability statement. By September 2026, later versions had changed some of the implementation details. The certificate-validation switch is one example. Licensing, regional availability, Copilot conditions and supported runtime versions can change as well.
Microsoft also changed how future roadmap information is published. From September 2026, new Dynamics 365, Power Platform and Dataverse capabilities moved to the AI at Work roadmap, while the older release-plan pages remained available as historical references. Before planning work, technical teams should check the tenant's current version, the current Microsoft documentation and the release status of each feature they intend to use.
This is particularly important for Business Central Copilot and agent capabilities. A feature discussed in a release plan may be a preview, may have region or language conditions or may require a particular licence and online deployment model. Treat the current product documentation and the customer's own admin centre as the source for deployment decisions.
Choosing a Business Central partner in the UK
A capable Dynamics 365 Business Central partner should do more than repeat the release notes. It should be able to explain how a feature changes the extension architecture, which risks sit in the customer's environment and what evidence will be collected before production deployment.
For a developer-led release such as version 26.0, that means understanding AL development, AppSource and per-tenant extensions, automated testing, telemetry, DevOps pipelines, Power BI, Azure services and integration security. It also means knowing when no custom development is required. A standard feature that meets the process is usually easier to support than another bespoke layer.
InteliSense IT supports Business Central implementation, integration, upgrades, optimisation and managed services. Our consultants can review the extension estate, test the upgrade path, identify unsupported design choices and help the customer build a practical Business Central roadmap around the processes that matter.
Frequently asked questions
What was the main Business Central version released in April 2025?
Business Central 2025 release wave 1 corresponded to version 26.0. Microsoft made the wave generally available in April 2025, with additional monthly updates following during the wave.
Did Business Central 2025 allow partner extensions to move tables and data?
Yes. Version 26.0 extended the controlled process for moving tables and fields with their data to partner extensions. The change supports modular refactoring, but it still requires careful handling of ownership, dependencies, schema synchronisation and upgrade order.
Can AL developers mock external API responses in tests?
Yes. HttpClientHandler procedures and TestHttpRequestPolicy allow a test to intercept outbound calls and return defined responses. This helps developers test failures and edge cases without depending on a live endpoint.
Did the 2025 update improve Business Central integration security?
Server-certificate validation became the default for outbound AL HttpClient calls in version 26.0, with telemetry available for validation failures. Current Microsoft guidance says validation is mandatory from version 27, so older code that disabled it needs to be reviewed.
Should every customer enable every new Business Central feature?
No. A Business Central assessment should match release changes to real processes and risks. Features that add no operational value still create testing, training and support work. The best upgrade scope is selective, evidence-based and compatible with the customer's extensions and integrations.
How often should Business Central extensions be reviewed?
At minimum, review them before each major release wave and whenever Microsoft raises the runtime or application version required by the tenant. A stronger managed-service model also tracks monthly updates, obsolete features, telemetry, failed jobs and changes in connected services throughout the year.
Plan the update around your own environment
The Business Central 2025 updates gave developers better tools for extension refactoring, test isolation, diagnostics, source navigation, secret handling and reporting. Their value is practical: fewer blind spots during support, more reliable integration tests and a clearer route from a production app back to the build that created it.
The update itself is only the starting point. A safe result depends on knowing which extensions are installed, which integrations can fail, which reports the business relies on and how the team will prove that critical processes still work after deployment.
Speak to InteliSense IT about a Business Central upgrade or health check. We can assess your current version, extensions, integrations, telemetry and release readiness, then turn the findings into a controlled delivery plan.
Availability note: Product behaviour, licensing, previews, regional support and delivery dates can change. Confirm the current Microsoft documentation and your own Business Central environment before making implementation decisions.
