1.2 Customization Lifecycle: Cloud (SaaS) vs. On-Premises

1.2 Update Lifecycle, Release Waves & Cloud vs. On-Premises

Understanding the software release cadence and operational differences between Business Central Online (Software as a Service / SaaS) and Business Central On-Premises is critical for developers. Developers must design extensions that remain resilient across automated platform updates and respect the strict security and resource sandbox boundaries of the public cloud.

1. Microsoft Release Cadence & Update Cycles

Microsoft maintains a continuous delivery model for Business Central Online, structured around two major release waves each year and regular monthly updates:

+-----------------------------------------------------------------------------------------+
|                                 ANNUAL RELEASE TIMELINE                                 |
+-----------------------------------------------------------------------------------------+
  JAN     FEB     MAR     APR     MAY     JUN     JUL     AUG     SEP     OCT     NOV     DEC
                   ▲       ▲                                       ▲       ▲
                   │       │                                       │       │
           Wave 1 Preview  Wave 1 GA                       Wave 2 Preview  Wave 2 GA
          (30-Day Window) (Major Update)                  (30-Day Window) (Major Update)
                   └───────┼───────────────────────────────────────┴───────┼──────────────────
                           │                                               │
                  Monthly Minor Updates                           Monthly Minor Updates
                  (Cumulative Bug Fixes &                         (Cumulative Bug Fixes &
                   Regulatory Patches)                             Regulatory Patches)

Major Release Waves (Wave 1 & Wave 2)

• Release Schedule: Wave 1 is released in April; Wave 2 is released in October.
• Scope of Changes: Major releases introduce new AL language capabilities, new platform features, broad user interface updates, structural data schema enhancements, and deprecated object retirements.
• Runtime Compilation: Major updates may increment the AL compiler platform version (e.g., from runtime 13.0 to 14.0), introducing new compiler rules, warnings, and analyzer checks.
• Update Window Management: Administrators can configure update windows in the Business Central Admin Center (specifying the exact hours during low-traffic periods when the update should apply) and can postpone major updates for up to a designated grace period (typically 60 days post-GA).

Minor Monthly Updates

• Release Schedule: Shipped monthly between major release waves.
• Scope of Changes: Minor updates deliver critical bug fixes, regulatory and tax compliance patches, performance optimizations, and non-breaking application improvements.
• Zero-Downtime Rollout: In the cloud, monthly updates are applied automatically by Microsoft with near-zero downtime, applying schema updates and recompiling active extensions seamlessly.

The 30-Day Preview Sandbox Window

Approximately 30 days prior to the General Availability (GA) of a major release wave (March for Wave 1, September for Wave 2), Microsoft provisions preview platform builds in Azure:

1. Administrators and developers can create new Sandbox (Preview) environments via the Business Central Admin Center.
2. Preview sandboxes run the upcoming major release platform and application bits.
3. Developers deploy their production Per-Tenant Extensions (PTE) and AppSource apps into the preview sandbox to test end-to-end regression workflows before the production tenant is upgraded.

2. Automated Extension Validation Pipelines

In Business Central Online, Microsoft guarantees that platform upgrades do not corrupt customer data or cause unhandled runtime crashes. To ensure this, Microsoft executes an Automated Extension Validation Pipeline against all production and sandbox environments in advance of scheduled major upgrades.

How Automated Validation Operates

1. Automated Background Compilation: The validation service takes copies of all active .app packages installed on the tenant (including PTEs and AppSource ISV apps) and attempts to compile and link them against the upcoming major version metadata.
2. Schema Compatibility Check: The engine verifies that table extensions, companion tables, and key definitions can be synchronized cleanly without data loss.
3. Failure Notifications: If an extension fails compilation (for example, due to referencing a removed obsolete field or relying on an altered procedure signature):
   • An automated high-priority alert email is dispatched to all registered notification recipients configured in the Business Central Admin Center.
   • A failure telemetry event is emitted to the customer's connected Azure Application Insights resource — LC0021 (Extension failed to compile), LC0023 (Extension failed to update), or the runtime event RT0010 (Extension Update Failed).
   • The upgrade of the customer's production environment is paused until the incompatible extension is updated or uninstalled.
4. Remediation Requirement: The developer must resolve the breaking changes in AL, update the version in app.json, and upload the updated package prior to the expiration of the upgrade grace window.

3. Deprecation Architecture & Obsolete Lifecycle

To prevent sudden breaking changes from destabilizing extensions during major updates, Microsoft enforces a strict multi-wave Deprecation Policy using the ObsoleteState, ObsoleteReason, and ObsoleteTag AL attributes.

// Example of a Table Field undergoing Microsoft's Deprecation Lifecycle:
tableextension 50100 "Custom Customer Ext" extends Customer
{
    fields
    {
        field(50100; "Legacy Tax Code"; Code[20])
        {
            Caption = 'Legacy Tax Code';
            DataClassification = CustomerContent;
            ObsoleteState = Pending;
            ObsoleteReason = 'Replaced by standard Tax Group Code in compliance with Wave 2 tax engine.';
            ObsoleteTag = '24.0';
        }
    }
}

The Three Deprecation States

• ObsoleteState = No (Active): The object, field, procedure, or enum value is fully supported and active.
• ObsoleteState = Pending (Deprecation Phase): The element remains fully functional at runtime, but the AL compiler flags every reference to it with a compiler warning (AL0432). Microsoft guarantees that an element marked Pending will remain in the codebase for at least 1 full year (2 major release waves) before removal.
• ObsoleteState = Removed (Retired Phase): The element's code logic or field definition is permanently removed. Any extension attempting to reference a Removed object or field will fail compilation with a hard error (AL0433 — "{0} '{1}' is removed.").

4. Cloud (SaaS) vs. On-Premises: Technical Comparison

While AL is the common programming language across all deployment models, Business Central Online (SaaS) imposes architectural restrictions to guarantee cloud multitenancy security, high availability, and resource governance.

Key Developer Constraints in Cloud (SaaS)

1. File Management via Streams: SaaS developers cannot use File.Create('C:\export.csv'). All file import/export logic must be handled using InStream, OutStream, TempBlob codeunits, or direct streaming to Azure Blob Storage / SharePoint REST endpoints.
2. Isolated Storage: For sensitive settings (such as integration API secrets, OAuth tokens, and encryption keys), developers must use the IsolatedStorage API (IsolatedStorage.Set(), IsolatedStorage.Get()) rather than writing credentials into custom setup tables.
3. Operational Request Throttling: Cloud environments enforce operational request quotas. OData v4 calls that exceed the environment rate limit (600 requests per minute in production, 300 in a sandbox) return HTTP Status Code 429 (Too Many Requests).