Upgrade Readiness
AI built your Business Central extension in an afternoon. Your next upgrade will take it apart in minutes.
The speed at which AI generates AL code is genuinely impressive. The speed at which poorly architected extensions fail at upgrade time is equally impressive — and considerably more expensive.
Microsoft ships two mandatory Business Central updates per year. That cadence isn’t slowing down — if anything, the AI-driven pace of platform development means the release cycle is accelerating. Every one of those updates is a moment of truth for every extension running in your environment.
For extensions built thoughtfully, by people who understand the BC platform deeply, updates are manageable. A review, some targeted adjustments, a test cycle. Inconvenient, but controlled.
For extensions built fast — by AI tools that optimise for getting the code to work today, with no visibility into what Microsoft’s roadmap holds for tomorrow — updates are a different experience entirely.
“AI-generated code solves today’s problem. Upgrade-safe code solves today’s problem in a way that won’t create tomorrow’s crisis.”
Why AI-generated extensions break
The four patterns that cause upgrade failures — and why AI keeps producing them.
AI code generation tools are trained on what works now. They have no awareness of Microsoft’s deprecation roadmap, no visibility into which APIs are being retired, and no judgment about which architectural patterns are fragile versus durable. The result is code that is technically correct today and structurally vulnerable tomorrow.
|
⚠ Direct table access instead of API calls AI frequently writes code that reads or writes directly to BC tables rather than using the published API layer. Microsoft regularly restructures internal tables between releases. Direct table access breaks without warning when that happens. |
|
⚠ Deprecated function usage AI tools trained on historical AL code will confidently generate calls to functions Microsoft has marked for deprecation. The code runs fine — until the release where the function is removed. No warning. Just failure. |
|
⚠ Hard-coded platform assumptions Page IDs, table numbers, field references — AI often hard-codes these rather than using symbolic references. Microsoft’s platform modernisation work regularly renumbers and restructures these. Every hard-coded reference is a time bomb. |
|
⚠ Missing upgrade codeunits Extensions that modify data structures need upgrade codeunits to handle data migration when the extension version changes. AI-generated extensions rarely include these. The result at upgrade time is data loss or corruption that can be extremely difficult to reverse. |
“The test of a BC extension isn’t whether it works on the day it’s deployed. It’s whether it still works on the day of the second mandatory update after deployment.”
What upgrade-safe looks like
Four principles that separate durable extensions from fragile ones.
The good news is that upgrade-safe AL development isn’t mysterious. It follows a clear set of principles that experienced BC developers have internalised over years of working with the platform’s update cycle. The challenge is that these principles require platform knowledge that AI tools simply don’t have.
|
✓ API-first architecture Always interact with BC data through the published API and interface layer, never directly through tables. APIs are versioned and maintained. Internal table structures are not. |
|
✓ Deprecation-aware development Every extension should be reviewed against Microsoft’s published deprecation notices before deployment — and before every major update. What compiles today may not compile in six months. |
|
✓ Symbolic references throughout No hard-coded IDs, numbers, or platform-specific values. Everything referenced symbolically so that platform restructuring doesn’t silently break behaviour. |
|
✓ Upgrade codeunits for every data change Any extension that modifies a data structure needs a corresponding upgrade codeunit that handles data migration cleanly. This is non-negotiable for production environments. |
The practical implication
Use AI to go faster. Use experience to go safely.
We’re not suggesting you abandon AI code generation. Used well, it accelerates development significantly — and there’s no reason not to take that acceleration. But acceleration without architectural oversight is how you end up with a BC environment that works beautifully right up until the moment your mandatory update drops.
The right model is AI-assisted development with experienced review. AI drafts the extension. A senior BC developer who has lived through multiple update cycles reviews it against the deprecation roadmap, checks every table interaction, verifies every reference, and adds the upgrade handling that AI will never think to include.
That review step is not bureaucracy. It is the difference between an extension that serves you for three years and one that fails on the first update and takes your finance team’s critical process with it.
At NAV SEAL, every AI-assisted build goes through exactly this review. Not because we don’t trust the tools. Because we’ve seen what happens to the organisations that do.
Building on BC with AI assistance? Make sure it’s upgrade-safe.
NAV SEAL reviews AI-generated AL extensions for upgrade safety before deployment — and audits existing extension libraries for known vulnerability patterns ahead of mandatory updates.
Visit navseal.com or connect with us on LinkedIn to start the conversation.
#BusinessCentral #Dynamics365 #ALDevelopment #BCUpgrade #ERPArchitecture #MicrosoftPartner #NAVSEAL #AIStrategy
