ERP & Enterprise

ERP Roundup: BC29 Arrives With Two Testing Features Its Own Docs Do Not Describe, and a Licence Key Where the Download Date Decides

Sharif George6 min read

Business Central 29 went generally available this week. The two stories underneath are better: a pair of AL testing capabilities Microsoft lists as launched, with no documentation describing how to use them, and a licence key change that looks like simplification and behaves like a dated certificate. No named ERP failure or lawsuit surfaced, so this is a three-story roundup.

1. BC29 is generally available, and two of its testing features have no documentation yet

BC29 is out. Yun Zhu recorded the W1 build as platform 29.0.55365.0 with application 29.0.54011.55407, supported from 30 September 2026 to 5 April 2028. New tenants get it automatically; existing ones wait for the notification. On-premises had not released at the time of writing, which matters below.

Two entries are aimed at people who test. Microsoft's what's new page for update 29.0 lists "Run AL tests from command-line and CI/CD workflows" and "Build extensible and data-driven AL test suites". The roadmap entries, RM573334 and RM573333, are both marked Launched, General Availability, October 2026. The first has ALTool running AL test projects from a script or pipeline "with structured JSON results for test methods and pass, fail, and skip counts". The second has parameterised tests built from reusable data sources, with lifecycle handlers for shared setup, cleanup, logging and reporting.

Then you look for the syntax. The ALTool reference, last updated 21 August 2026, lists eleven commands, none of which runs a test. The testing overview was last updated in October 2025 and describes test runner triggers that have been there for years. Neither mentions a data source, a parameterised test or a lifecycle handler. That is a documentation lag, not evidence the features are absent, and it will probably close within weeks. But today the syntax is unpublished.

What it means for testing

Do not commit either capability to a client plan this month: what you cannot see is the output contract, and a CI gate is only as good as the format it parses. On scope, a JSON pass/fail/skip count is developer evidence; a business owner accepting a process is a different artefact. A greener pipeline does not shorten the UAT pass on a Business Central implementation, because nobody who signs has seen it. Use automated AL tests to protect regression scope between passes, and leave the acceptance layer alone.

2. The new 28+ licence key is forward-compatible in name only

Microsoft told partners on 1 October that new Business Central releases no longer carry version-specific licence keys for on-premises. From version 28 there is one key version, "28+"; versions 27 and earlier keep theirs. It reads like one less thing to track.

The detail underneath reverses that. In Microsoft's words, "the date on which the 28+ license key is downloaded will determine which objects are unlocked on the license file". Their worked example: at version 30 in April 2027, a customer needs a freshly downloaded 28+ key to unlock the version 30 objects, and one downloaded on 1 October 2026 produces a version compatibility warning. So it is not forward-compatible in the sense the name suggests: one key version whose contents depend on when you fetched it, with nothing in the name to tell you which.

Scope matters. This covers on-premises editions and the Dual Use Rights keys online customers download, not an online tenant's update path, and Microsoft states the major and minor release cycle is unchanged, so it is not a cadence change. One trap: DUR keys from the Microsoft 365 Admin Center show version "28" at first, correcting to "28+" by the second week of October.

What it means for testing

This failure arrives in the wrong place. The key is a prerequisite, so a stale one breaks nothing a tester would think to check; it warns or blocks at deployment, in an upgrade window, on somebody else's evening. Put the refresh on every on-premises and DUR client's pre-upgrade checklist, with a named owner and a recorded download date, not a runbook line saying "check licence". Then rehearse it with the key the client actually holds, because that is the only way dated behaviour surfaces before go-live. Same principle as the BC29 changes with no screens to test: the risk is in what the upgrade touches.

3. SmartBear: 46% shipped AI code that failed in production, and 69% of them stayed confident

On 30 September SmartBear published its 2026 State of Software Quality and Testing report, a survey of 1,436 respondents in the US and UK, all using AI in development. The headline pair: 46% of teams have shipped AI-generated code that failed in production, and 69% of those teams remain confident in it anyway. Confidence splits by seniority too, 73% of leaders to 52% of practitioners.

Three numbers matter more. Only 46% validate the specification before AI generates code, 47% cannot explain how AI contributed to a production bug, and 95% of leaders call their code review adequate while 25% of teams review more than 80% of agent work. SmartBear sells testing tooling and this is self-reported, vendor-commissioned data, so take the direction, not the decimals.

This is development teams and production code, not ERP acceptance testing, and no respondent is a Business Central partner. Read it anyway: the half who skip validating a specification are describing the input to UAT.

What it means for testing

Validating a specification before generation is the same discipline as writing an acceptance criterion before a test case, and both are the cheap half of the job. If an AL extension arrives describing what it does but not what the business will accept, a test pass proves only that the code matches itself. Traceability is the figure to act on: a defect you cannot tie to a change is one you cannot close, so the sign-off trail records what was tested, against which build, by whom, and when.

The through-line: three claims, and the evidence for each one is somewhere else

A testing feature marked Launched with no published syntax. A licence key whose validity turns on a download date recorded nowhere on it. A survey where 95% of leaders are satisfied with review coverage and a quarter of teams review most of the work. In each case a claim and the artefact that would prove it have come apart, and the gap shows only when somebody asks what was checked. That is the question Monday's post on what a go-live decision has to leave behind as evidence was about, and why the useful output of a UAT pass is a record someone can still read years later, not a green tick — the same reason a regression scope has to be written down.

→BC29 is GA, supported to 5 April 2028. Its two AL testing features are marked launched; the reference docs do not yet show you how. Do not commit a pipeline stage this month.
→The 28+ licence key is one version with dated contents. On-premises and Dual Use Rights only, no cadence change. Add a dated refresh to every pre-upgrade checklist.
→46% validate a specification before generating code; 47% cannot trace a production bug to AI. Acceptance criteria first, then test cases, then a sign-off record naming the build.

Free ERP UAT checklist (Excel)

A structured workbook covering the full UAT cycle: pre-UAT preparation tasks, test execution tracking, an issue log with severity guide, and post-UAT wrap-up. Built from real ERP implementations.

No spam. We will occasionally send UAT and ERP implementation resources. Unsubscribe any time.

Sources and further reading

Free Plan Available

A Green Pipeline Is Not A Sign-Off

LogicHive gives ERP implementation teams the acceptance layer that automated tests do not cover: structured test cases, named business owners, linked defect tracking, and sign-off built from real execution data rather than a screenshot of a passing build. When an upgrade window opens or a prerequisite changes under you, running a pass is a scheduling decision rather than a project. The free plan runs a real project end to end.

Written by Sharif George

LogicHive Frontman

Sharif is the frontman for LogicHive. He writes the ERP news roundups and the Business Central release coverage, following each Microsoft, SAP and Oracle change through to what it means for regression scope and acceptance testing on live implementation projects.

View all articles by Sharif George
  • ERP & Enterprise

    A Go-Live Decision Taken in 2022 Is Still Setting the Audit Opinion in 2028

    Europe's largest council finally has a working Oracle finance system, with no outstanding priority 1 or 2 tickets — and an auditor who does not expect to sign off a set of its accounts until 2028/29. The gap between those two facts traces back to which modules went live untested in 2022, and to what UAT sign-off is actually supposed to produce.

    28 September 2026 · 6 min read

  • ERP & Enterprise

    Business Central's Record-and-Replay Test Tool Reached GA This Week. It Is Not UAT.

    Microsoft moved the Business Central page scripting tool from preview to general availability with version 29, thirty months after the preview opened, adding multi-row grid selection and dialog-text validation — neither of which the reference documentation describes yet. What a recording actually proves, what it is documented not to reach, and why a replay pipeline is a regression asset rather than an acceptance one.

    5 October 2026 · 6 min read

  • ERP & Enterprise

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

    From version 29, the fields your extensions add to a table are stored in that table rather than in a companion table beside it. No screen changes, so a feature-led test pass finds nothing — while query plans, index behaviour and the field capacity every extension on that table shares all change. What to put in the October regression pass.

    28 September 2026 · 6 min read