Business Central 29 Moves Extension Fields Into the Base Table: The Change With No Screens to Test

What changes in 29.0, and when

Microsoft's "What's new or changed" article for update 29.0 states it in one line: "With the new data model for table extensions, all fields on an AL table are stored in the same table in the database. This gives faster performance on all database operations that involve table extensions."

A second entry on the same page is the tell that this is structural rather than a tuning change: "The new data model for storing fields from table extensions allows developers to define keys across fields from the base table and table extensions." The compiler used to refuse that, because the fields were not in the same physical table. Now they are.

The dates, from the same documentation: 29.0 has been in public preview since the first week of September, in online sandbox environments only — not production, not on-premises. General availability is October 2026, and preview sandboxes are deleted 30 days after that. The preview window closes this week.

From one table per extension, to one, to none

The performance argument is sound: a query that no longer joins is a faster query. What partners should not do is treat "faster" as a reason to skip testing. Changing physical storage changes which indexes the optimiser can use, so it changes query plans — and a changed plan can be faster in nine places and slower in the tenth.

The field ceiling is now shared

This is the consequence with teeth, and Microsoft documents it in the least-read place imaginable: a compiler warning. AL0915 reads, in full:

When extension fields lived in their own tables, one ISV's appetite for fields was its own business. Now every app on a table draws from one pool bounded by SQL's column limit. A customer running a vertical solution, two add-ons and a per-tenant extension on Item or Sales Header has four parties spending one budget, and whoever installs last is the one that fails.

Microsoft publishes no threshold for the warning, and the table specification limits have not been revised alongside the new model, so I will not put a number on anyone's headroom. What is worth doing is noting which customers have three or more apps on the same busy table, and treating a new install there as a change that needs testing.

Why a feature-led test pass misses this entirely

Most upgrade testing is organised around the feature list: read what Microsoft shipped, test what it touched. That finds nothing here. No screen moved, no field was renamed, no permission changed. A tester walking the order-to-cash script on a 29.0 sandbox will pass every step and report a clean upgrade — right about the functional behaviour, silent about what changed.

That is the standing argument for a customer-shaped regression suite rather than a Microsoft-shaped one, and it matters more this wave than most: as we covered when 29.0 shipped without a release plan behind it, the document partners scoped from is gone.

Version 29 also removes SOAP endpoints on Microsoft pages, which breaks integrations without touching a screen. Two invisible changes in one wave, neither findable by clicking around.

What belongs in the October regression pass

Time the slow things, on both versions. Posting a large sales order, the month-end close, the nightly integration, the reports finance actually opens, any list page users have filtered into a corner. Record durations rather than asking whether it "feels" the same. Without a number from the current version, you cannot tell whether a November complaint is a regression or a mood.

Test the extensions together, in the customer's combination. Each app publishing cleanly on its own proves less than it did now that they share a table. Install order and the full stack are part of the test, not the setup for it.

Check anything that assumes the physical shape of the database. Direct SQL against a companion table, a report on a view, a warehouse job, a BI extract: all assumptions about storage, and storage is what moved. Supported AL and API paths are unaffected by design; anything that went around them is not.

Keep the results somewhere that outlives the sandbox. The preview environment goes about 30 days after GA — roughly when a customer starts asking whether things were always this slow. Our Business Central UAT guide covers a reusable pack per customer, and where regression testing ends and acceptance testing begins is worth settling before October, not during it.