Modify your extension so it’s compatible with the version 27.0.38460.39437

BC27 is approaching fast, and the forerunner is (not a car) the warning email about something not being compatible with BC27. In this video, I take a look at upgrading an app to be BC27 compatible. Check it out:

https://youtu.be/ap7LQjL2wZ4

In this video, Erik walks through the process of updating your AL extensions to be compatible with Business Central version 27. The biggest breaking change? The long-standing NoSeriesManagement codeunit has been removed, and you need to migrate to the newer No. Series codeunit. Erik also demonstrates an exciting new preview feature: upgrading a sandbox environment directly to the preview version of BC27 through the Admin Center.

Big News: Preview Upgrades in Admin Center

Starting with version 27 (fall 2025), Microsoft now allows you to upgrade a sandbox environment to the preview version directly from the Admin Center. This is a significant improvement over previous releases where you could only play around with a fresh preview environment.

The workflow is straightforward:

  1. Take a copy of your production environment to a sandbox
  2. Upgrade that sandbox to the version 27 preview
  3. Test your apps and data against the new version

Important warning: Once you upgrade a sandbox to the preview version, that sandbox can never go anywhere else. After the preview window closes (i.e., after the official release of version 27), that sandbox is effectively dead. So treat it as a disposable test environment.

The Compatibility Email

Microsoft provides a valuable service: they take your published apps and attempt to compile them against the next version. If your app doesn’t compile, you’ll receive an email with a subject like “Modify your extension so it’s compatible with the version 27.0.38460.39437”.

The most common error hitting developers right now is:

AL0185: Codeunit 'NoSeriesManagement' is missing

This is affecting a huge number of apps because NoSeriesManagement has existed essentially forever. It was marked for removal in version 24 when the new No. Series codeunit was introduced, and now in version 27, it’s actually gone. That’s a fairly aggressive deprecation timeline — just three major versions.

Why This Matters for Upgrades

If you have an app that isn’t compatible with the next version, it will block your environment from upgrading. Your environment will stay behind on whatever .5 minor version it’s on until either you fix the app or Microsoft eventually removes it and forces the upgrade. You definitely want to fix it before that happens.

Fixing the Number Series Code

The old code typically looked something like this:

var
    NoSeriesMgmt: Codeunit NoSeriesManagement;
begin
    PetNo := NoSeriesMgmt.InitSeries(Setup."Pet Nos.", ...);
end;

The deprecation warning reads: “Please use the No. Series and No. Series – Batch codeunits instead.”

The replacement is the No. Series codeunit (ID 310), which lives in a different module than the old NoSeriesManagement (ID 396). The key method you’ll use is GetNextNo instead of InitSeries:

var
    NoSeries: Codeunit "No. Series";
begin
    PetNo := NoSeries.GetNextNo(Setup."Pet Nos.");
end;

The new codeunit is simpler in many cases — you just pass in the number series code and get back the next number. There’s no need to pass the number as a var parameter like the old pattern required.

Here are some of the key methods available on the new No. Series codeunit:

  • GetNextNo — Get and increment the next number
  • PeekNextNo — See the next number without incrementing
  • GetLastUsedNo — Retrieve the last number that was used
  • TestManual — Test if the series is set to manual numbering
  • HasRelatedSeries / TestAreRelated — Check series relationships

Dealing with Symbol Versions

Erik also highlights an important concept he calls “symbols creep”. The AL compiler, when it finds multiple versions of the same .al package in your symbols folder, will use the newest one. This can be dangerous if you’re targeting a specific older version (for example, for on-premises support). You might inadvertently start using new APIs that don’t exist in your target version.

When updating for BC27 compatibility, clean out your old symbol files and download fresh ones from your target environment to ensure you’re compiling against the correct version.

Other Common Issues

Beyond the number series changes, Erik notes that apps built on very old versions (like BC19) may also trigger the implicit with warning. If your app was built before the NoImplicitWith feature flag became standard, you’ll want to address that as well. In the sample app.json, notice the feature flag is already set:

{
  "id": "a200c67e-58ec-4b14-84c9-4f3a621ca557",
  "name": "WhatsNewInBC26",
  "publisher": "Default Publisher",
  "version": "1.0.0.0",
  "platform": "1.0.0.0",
  "application": "26.0.0.0",
  "runtime": "15.0",
  "features": [
    "NoImplicitWith"
  ]
}

You’ll also want to clean up any unused event subscribers, as the compiler may flag those as well.

Summary

The transition to BC27 brings a significant breaking change with the removal of the NoSeriesManagement codeunit. The vast majority of compatibility emails developers are receiving are related to this single change, since nearly every app that creates records with number series used this codeunit. The fix is straightforward — replace NoSeriesManagement.InitSeries calls with "No. Series".GetNextNo — but you need to do it before the upgrade window arrives or your environments will be blocked from upgrading. The new ability to test preview versions against your own sandbox data makes this process much easier to validate before the official release.

Picture of hougaard

hougaard