Below is a
real-world governance pattern that works well for
Business Central SaaS, based on how Microsoft actually rolls out updates (major + minor) and what tends to break in production when you have extensions/ISVs/integrations.
1) First: align governance to Microsoft’s actual cadence (so you’re not fighting it)
What Microsoft does (high level):
- Major versions: GA is typically the first workday of April and October, and you get a ~5‑month update period to pick when your environments move.
- Preview: available about one month before each major release (March/September) for regular tenants; partners can have early access preview with Partner Sandbox.
- Minor updates: generally monthly (except April/October), and Microsoft has introduced more flexibility, including the ability to skip intermediate minor versions in some cases (optional minor updates).
- Update window behavior: updates start inside your environment’s update window; if an update can’t finish before the window ends, it’s canceled and retried 7 days later.
That means your governance model should be a
repeatable release train, not a “panic project twice a year”.
2) A proven governance model (lightweight but effective)
Recommended operating model: BC Release & Change Council (mini-CAB)
Think of this as a small “ERP change authority” that meets more often around releases.
Core roles
- BC Product Owner (Finance/Ops lead) – owns business risk/priority
- BC Platform Owner (IT) – owns Admin Center, scheduling, telemetry, security
- Extension Owner(s) – internal AL dev + key ISV contacts
- Integration Owner – eComm/WMS/CRM/API/Power Automate owners
- QA/UAT lead – runs regression + acceptance sign-offs
Cadence
- Weekly during preview/UAT windows; monthly otherwise.
- Required outputs each cycle:
- Release impact summary (what’s changing + risks)
- Go/No-go criteria
- Sign-off + rollback/contingency plan (SaaS rollback is limited, so “contingency” usually means business workarounds + support escalation, not true rollback)
3) Sandbox + regression structure that minimizes risk
Minimum sandbox layout (most orgs)
1)
Preview sandbox (March/September)
- Goal: “Will anything obviously break on the next major version?”
- Note: preview sandboxes are removed after release (Microsoft states preview + preview-based sandboxes are removed 30 days after official release), so don’t build long-lived test strategies on preview alone.
2)
Prod-copy UAT sandbox (created by copying production)
- This is the real workhorse.
- When you’re notified the update is available, copy production → sandbox → schedule the update on that sandbox and run the full regression/UAT there.
3)
Build/Test sandbox (optional but strongly recommended if you develop AL)
- Where you validate compilation, automated tests, and extension upgrades before UAT users ever see it.
Regression testing structure (practical)
Split your validation into three layers:
Layer A: “Smoke test” (30–60 minutes)
- Login, permission sets, posting permissions
- Core pages load, search works, role center renders
- Job queue is running
Layer B: “Critical path regression” (2–6 hours)
Focus on the handful of flows that financially/operationally hurt if broken:
- Order → shipment → invoice
- Purchase → receipt → invoice
- Inventory adjustments + valuation
- Bank import / payment export
- Month-end close routines (or at least a subset)
Layer C: “UAT by process owners” (1–2 weeks depending on complexity)
- Finance validates posting outcomes and reports
- Operations validates fulfillment, warehouse, replenishment
- Include exceptions, not just happy paths
Tip: keep a living regression checklist and only expand it when you’ve been burned by a new failure mode.
4) Release controls / change-management frameworks that fit SaaS reality
What works best in practice is
ITIL-style change control, but scaled down:
- Define change windows / blackout windows (month-end close, payroll, seasonal peaks)
- Require business sign-off before production scheduling
- Use standard change templates for:
- “Major BC update”
- “Minor BC update”
- “ISV app update”
- “Per-tenant extension update”
Because SaaS updates can be forced at the end of the update period (and incompatible extensions can be removed in certain forced scenarios), you want decisions
early, not at the deadline. Microsoft’s docs on update periods and app maintenance emphasize scheduling within the update period and what happens when incompatibilities are found.
5) Coordinating with Finance/Ops during the update window (the part that actually prevents incidents)
A pattern that consistently reduces chaos:
A. Publish a “release calendar” that Finance trusts
- March: preview evaluation starts
- April: major GA + your target production date sometime in the 5-month window
- Repeat for September/October
B. Add 2 operational controls around the actual cutover
- Posting freeze window (short): for example, “no posting between 9pm–11pm” during update start (depends on your time zone and update window)
- Hypercare window (24–72 hours): rapid triage, owners on standby
C. Pre-stage user communications
BC warns users signed in when an update is about to start, but don’t rely on that alone—send your own coms.
6) Extensions/ISVs/customizations: lessons learned (where most SaaS upgrade pain comes from)
A. Treat “AppSource apps” and “per-tenant extensions (PTE)” differently
Microsoft explicitly notes AppSource apps shouldn’t be treated like PTEs because it creates conflicts, and publishers are responsible for validation.
B. Control app update cadence intentionally
In Admin Center there’s an
Apps Update Cadence concept; default behavior typically updates apps with major updates (with exceptions). It doesn’t affect PTE updates.
Practical rule: don’t let ISV updates hit production “whenever”—apply them first in sandbox inside your regression process.
C. Plan for breaking changes / removed obsolete objects
Business Central has been actively cleaning up obsolete schema and objects across releases (for example, removing obsolete schema elements after more than one major release), which can break custom code that still references removed objects.
Mitigation: keep an internal “extension compatibility backlog” and burn it down during the preview window, not after Microsoft schedules production.
D. Contractual reality: ISV support SLAs matter
If you run critical ISVs (banking, EDI, WMS connectors), budget time and money for:
- their upgrade readiness statements
- coordinated testing
- escalation paths
7) A practical “biannual update playbook” (copy/paste)
T‑6 weeks (Preview window)
- Upgrade preview sandbox
- Compile/test PTEs against preview
- Ask ISVs for compatibility statements + target versions
T‑4 weeks
- Copy production → UAT sandbox
- Schedule UAT sandbox update to target major version
- Run smoke + critical path regression
T‑2 weeks
- UAT with finance/ops sign-off
- Decide production date inside update window
- Confirm update window settings and downtime communications
T‑0 (Production)
- Start update in update window
- Hypercare + monitoring + quick issue triage
- If update fails and reschedules, execute your comms + business workaround plan
Quick questions (so people can share more “real world” comparable approaches)
1) Roughly how many
AppSource apps / PTEs do you run in production?
2) Do you have a hard blackout period (month-end close, seasonal peak)?
3) Are you using preview sandboxes today (and do you have Partner Sandbox access)?
If you answer those, I can suggest a
right-sized version of the governance model (small org vs multi-entity + heavy ISVs) and a regression checklist tailored to finance/warehouse/eComm-heavy tenants.
