Business Central Upgrades: Stay Current, Stay Competitive

Part 11 of 11 in the Business Central Implementation Series

Published: January 2026 | Reading Time: 11 minutes

Introduction: The Cloud Advantage - But Only If You Stay Current

You've implemented Microsoft Dynamics 365 Business Central—congratulations! You're now on a modern, cloud-first ERP platform with enterprise capabilities. But here's what many organizations don't realize:

Business Central isn't "set it and forget it."

Microsoft releases two major updates per year (April and October), plus monthly service updates with bug fixes and minor enhancements. Each release brings:

• New features (AI/Copilot capabilities, automation, improved UI)

• Performance improvements (faster reports, better scalability)

• Security enhancements (compliance with evolving regulations)

• Integration updates (deeper Microsoft 365 integration)

• Bug fixes (resolve known issues)

The Challenge: Organizations that don't keep up fall behind—missing out on capabilities their competitors are leveraging, accumulating technical debt, and eventually facing a costly "catch-up" upgrade.

The Opportunity: Organizations that embrace continuous upgrades stay at the cutting edge—adopting AI-powered insights, automation, and productivity features as soon as they're available.

Successful upgrade management requires experienced Microsoft Solutions Partners who understand both the technical upgrade process and change management required to realize value from new capabilities.

This guide explains Microsoft's release cadence, how to manage upgrades effectively, and how to ensure your Business Central environment stays current without disrupting your business.

🔄 Quick Answer: How Often Does Business Central Update?

Business Central releases two major updates per year (April and October "Release Waves") plus monthly cumulative updates (bug fixes, security patches). Cloud users receive updates automatically; on-premises users must manually apply updates.

Business Central Release Schedule:

Major Releases (Semi-Annual):

1. Wave 1 (April) – Preview in February, GA April 1st, new features and capabilities

2. Wave 2 (October) – Preview in August, GA October 1st, continued innovation

Monthly Cumulative Updates:

• Released first Tuesday of each month (e.g., CU 15, CU 16)

• Content: Bug fixes, security patches, minor improvements

• Frequency: 12 updates/year

Total Updates Per Year: 14 (2 major + 12 monthly)

Cloud vs. On-Premises Upgrade Differences:

💡 Pricing & Timeline Note
All cost estimates and timelines in this article reflect typical Business Central implementations as of January 2026.

• Geographic Context: Estimates based on Western Europe and North America markets

• Regional Variation: Implementation costs vary significantly by region (typically 30-60% lower in Eastern Europe, Asia-Pacific, and Latin America)

• Microsoft Licensing: Verify current prices at aka.ms/BCPricing as these change periodically

• Effort-Based Budgeting: Use the consulting hours estimates with your local partner's rates for accurate budgeting

These are reference estimates for planning purposes. Request detailed quotes from Microsoft Solutions Partners for your specific requirements.

Do I HAVE to Upgrade?

• Cloud: Yes, within 6 months of major release (Microsoft enforces)

• On-Premises: Technically no, but strongly recommended (security, compatibility, support)

Upgrade Cost Estimate:

• Cloud (Partner-Managed): $1,000-$3,000 per major release (testing, validation, user communication)

• On-Premises: $3,000-$8,000 per major release (testing, deployment, potential infrastructure changes)

Benefits of Staying Current: Access to AI/Copilot features (10+ new capabilities added in last 2 years), security patches, performance improvements, Microsoft 365 integration enhancements, compliance updates, and competitive advantage.

Understanding Business Central Release Cadence

Microsoft's Two-Release-Per-Year Model

Release 1: April (Wave 1)

• Preview available: February

• General availability: April 1st

• Cloud updates: April-September (automatic or scheduled)

• On-premises available: April (manual install)

Release 2: October (Wave 2)

• Preview available: August

• General availability: October 1st

• Cloud updates: October-March (automatic or scheduled)

• On-premises available: October (manual install)

Monthly Service Updates

• Released: First Tuesday of each month

• Content: Bug fixes, security patches, minor improvements

• Cloud: Applied automatically (minimal downtime)

• On-premises: Optional (recommended monthly)

What's in a Major Release?

Typical Wave 1 or Wave 2 Release Includes:

1. New Features (50-100 per wave)

• Example (2025 Wave 1): Copilot AI for bank reconciliation matching, sales line suggestions

• Example (2025 Wave 2): Enhanced approval workflows with mobile notifications

• Example (2026 Wave 1 Preview): AI-powered demand forecasting, predictive analytics

2. Platform Improvements

• Performance optimizations (report rendering 20% faster)

• UI enhancements (improved search, navigation)

• Mobile app updates (new capabilities, better offline mode)

3. Integration Enhancements

• Deeper Microsoft 365 integration (Teams, Outlook, Excel)

• Power Platform connectors (Power Automate, Power Apps, Power BI)

• API updates (new endpoints, expanded capabilities)

4. Compliance & Security

• Regulatory updates (GDPR, tax law changes)

• Security patches (vulnerability fixes)

• Audit trail improvements

5. Deprecated Features

• Older functionality being phased out (12-month notice)

• Migration path provided for replacements

Release Notes: Your Roadmap

Microsoft publishes comprehensive release notes 2 months before each wave:

Wave 1 Release Plan: Published February, available at docs.microsoft.com/dynamics365/release-plan
Wave 2 Release Plan: Published August

What's Included:

• Feature descriptions (with screenshots, videos)

• Availability timeline (GA, preview, coming soon)

• Target audience (end users, admins, developers)

• Impact assessment (high, medium, low effort to adopt)

Industry Best Practice: Review release plans with implementation partner 6-8 weeks before GA, identifying:

• Features that benefit your specific business

• Changes requiring user training

• Configuration adjustments needed

• Extension compatibility concerns

Cloud vs. On-Premises Upgrade Experience

Cloud (SaaS): Automatic Updates with Control

How Cloud Updates Work:

1. Microsoft Schedules Update

• You receive notification email 30 days before scheduled update

• Default: Microsoft picks date (typically weekends, outside business hours)

• Option: Self-schedule within available window (April-September or October-March)

2. Update Window Options

3. Pre-Update Preparation (2-4 Weeks Before)

4. Update Execution (Typically 2-4 Hours)

5. Post-Update Validation (Monday Morning)

What If Something Goes Wrong?

• Microsoft monitors updates 24/7

• Issues detected automatically (failed upgrade, errors in logs)

• Microsoft support contacts you immediately (or you contact them)

• Rollback possible within 7 days (revert to previous version)

On-Premises: Manual Upgrades with Full Control

How On-Premises Updates Work:

1. Microsoft Releases Update

• Cumulative Update (CU) available for download

• Install at your discretion (no forced timeline)

• Your responsibility to test and deploy

2. Download & Test (Your IT team or implementation partner)

3. Production Deployment (Planned Downtime)

4. Post-Upgrade Validation (Same as cloud)

On-Premises Upgrade Challenges:

• Technical complexity: Requires BC expertise (database upgrade scripts, extension compatibility)

• Infrastructure management: Application server, database server, web server all must be updated

• Testing burden: Your responsibility to catch issues (Microsoft doesn't test your specific configuration)

• Downtime management: Must coordinate maintenance window with business operations

Industry Guidance: Cloud is preferred for most SMBs (reduced overhead, automatic updates, better uptime, lower total cost of ownership). On-premises only if regulatory/data residency requirements mandate it or if specific customizations require on-premises deployment.

Major vs. Minor Upgrades: What's the Difference?

Major Upgrades (Wave 1, Wave 2)

Characteristics:

• Significant new features (50-100 enhancements)

• UI changes (new pages, redesigned workflows)

• Platform version increment (e.g., BC 23.0 → BC 24.0)

• Extension breaking changes possible (AL code may need updates)

• User training recommended (new capabilities to learn)

Effort Level:

• Minimal customization: Low (cloud auto-update, 1-2 hours validation)

• Moderate customization: Medium (1-2 days testing, some extension updates)

• Heavy customization: High (1-2 weeks testing, significant AL code changes)

Partner-Managed Approach for Major Upgrades:

Phase 1: Pre-Upgrade Assessment (6-8 Weeks Before GA)

Phase 2: Upgrade Execution (Update Weekend)

Phase 3: Post-Upgrade Support (1-2 Weeks After)

Minor Upgrades (Monthly Service Updates)

Characteristics:

• Bug fixes (resolve known issues)

• Security patches (vulnerability mitigation)

• Minor enhancements (small improvements)

• No breaking changes (extensions continue working)

• Platform version increment (e.g., BC 23.1 → BC 23.2)

Effort Level:

• Cloud: Near-zero (automatic monthly, minimal downtime)

• On-Premises: Low-Medium (optional install, 1-2 hours testing recommended)

Partner-Managed Approach for Minor Upgrades:

Cloud Clients:

• Microsoft applies automatically first Tuesday of month

• Implementation partner monitors update completion (verify no errors)

• Post-update smoke test (next business day)

• Issue escalation if problems detected

On-Premises Clients:

• Partner recommends monthly CU installation (security best practice)

• Quarterly minimum (March, June, September, December)

• Full upgrade process for major updates only (Wave 1, Wave 2)

Extension Compatibility: The Hidden Challenge

What Are Extensions?

Extensions are add-ons that extend Business Central functionality without modifying core code:

Types of Extensions:

1. Microsoft Extensions: First-party apps (Sales & Inventory Forecast, Banking 365 Fundamentals)

2. ISV Extensions: Third-party apps from AppSource (shipping, EDI, e-commerce connectors)

3. Partner Extensions: Custom extensions developed by your implementation partner

4. Custom Extensions: Your organization's proprietary AL code

Why Compatibility Matters:

• Major BC upgrades can introduce breaking changes (deprecated APIs, changed behaviors)

• Extensions not updated for new version may stop working

• Result: Broken integrations, workflows, reports

Extension Compatibility Lifecycle

Timeline for Major Upgrade (Example: BC 23 → BC 24):

February (8 Weeks Before GA):

• BC 24 preview available

• ISVs begin testing their extensions

• Microsoft publishes breaking changes list

March (4 Weeks Before GA):

• ISVs release compatible versions (or publish compatibility statements)

• Custom extension developers (partner or internal team) update AL code

April 1 (GA Date):

• BC 24 released

• Compatible extension versions available on AppSource

April-September (Update Window):

• Cloud tenants update to BC 24

• Extensions automatically updated to compatible versions (if available)

• If incompatible extension detected: Update blocked until extension updated

Extension Update Best Practices

For Partner-Developed Extensions:

• Compatibility assessment begins 6 weeks before GA (partner tests in preview environment)

• Updates completed 2 weeks before GA

• Tested in client sandbox before production upgrade

• Compatible version deployed during BC upgrade window

For ISV Extensions (Third-Party Apps):

• Implementation partner monitors ISV release schedules

• Alerts client if ISV delays compatibility update

• Workaround plan if extension temporarily unavailable (manual process, alternative app)

What If Extension Isn't Compatible?

Scenario: BC upgrade scheduled, but critical ISV extension not compatible yet.

Options:

Option 1: Delay Upgrade (Cloud Only)

• Delay BC upgrade up to 60 days (request via admin center)

• Monitor ISV for compatible version release

• Upgrade when extension ready

Option 2: Remove Extension Temporarily

• Uninstall incompatible extension before upgrade

• Proceed with BC upgrade (business continues without extension)

• Reinstall extension when compatible version available

• Risk: Functionality loss during gap period (workarounds needed)

Option 3: Replace Extension

• Find alternative extension with similar functionality (competitor app)

• Migrate to alternative before upgrade

• Proceed with BC upgrade using new extension

• Risk: Migration effort, cost of new extension

Option 4: Build Custom Replacement (Last Resort)

• Implementation partner develops custom AL extension replicating critical functionality

• Expensive and time-consuming (typically 4-8 weeks, $10K-$40K)

• Only justified if extension is business-critical and no alternatives exist

Industry Best Practice: Always evaluate extension criticality before adopting. Prefer Microsoft extensions (guaranteed compatibility) or reputable ISVs with fast update cycles and strong support history.

Partner-Managed Upgrade Approach

Typical Partner Upgrade Services

For Cloud Clients:

Pre-Upgrade (6-8 Weeks Before):

• Release plan review (1-hour workshop identifying relevant features)

• Sandbox testing (partner tests critical workflows in preview)

• Extension compatibility check (verify all apps ready)

• Training material updates (new features, UI changes)

Upgrade Weekend:

• Schedule coordination (select optimal date/time)

• Monitoring during update (partner on-call)

• Post-update validation (smoke tests within 2 hours of completion)

Post-Upgrade (1-2 Weeks After):

• User support (answer questions, troubleshoot issues)

• Issue escalation (Microsoft support liaison if bugs found)

• Optimization consulting (configure new features for your business)

Pricing:

• Often included in managed services plans

• Standalone upgrade service: $1,000-$2,000 per major upgrade (Wave 1, Wave 2)

For On-Premises Clients:

Planning & Preparation (4-6 Weeks Before):

• CU download and sandbox installation

• Full regression testing (end-to-end workflows)

• Custom extension updates (AL code changes if needed)

• Deployment runbook creation (step-by-step upgrade procedure)

Upgrade Execution (Scheduled Downtime):

• Partner engineer on-site or remote (client preference)

• Application server upgrade

• Database upgrade (automated scripts, partner monitoring)

• Extension deployment

• Smoke testing (2-3 hours validation)

Post-Upgrade Support (1-2 Weeks):

• Daily check-ins (first 3 days)

• Issue triage and resolution

• Performance tuning (optimize new version)

Pricing:

• Standard major upgrade: $5,000-$8,000 (BC version upgrade, e.g., 23 → 24)

• Minor CU upgrade: $1,500-$2,500 (monthly/quarterly service update)

• Emergency rollback (if needed): $3,000-$5,000

User Training for Upgrades

When Is Training Needed?

Major Upgrades (Wave 1, Wave 2):

Minimal Training Needed (80% of upgrades):

• Most features are additions, not replacements

• Existing workflows unchanged

• Users can continue working as before, discover new features gradually

• QUALIA recommendation: "What's New" email + optional lunch & learn

Moderate Training Needed (15% of upgrades):

• UI changes affecting navigation (menu reorganization)

• Workflow changes (approval routing, posting procedures)

• QUALIA recommendation: 1-hour role-based training session + updated guides

Extensive Training Needed (5% of upgrades):

• Major feature overhaul (e.g., new inventory management UI)

• Deprecated feature replacement (old approach no longer works)

• QUALIA recommendation: Half-day training session + hands-on practice + job aids

Monthly Service Updates:

• No training needed (bug fixes, minor enhancements only)

QUALIA Training Approach for Upgrades

1. What's New Document (Every Major Upgrade)

• 2-3 page summary of relevant new features

• Screenshots/GIFs showing new functionality

• "Why This Matters" for each feature (business benefit)

• "How to Access" (navigation steps)

2. Video Tutorials (5-10 Minutes Each)

• Feature demonstrations (watch over shoulder)

• Step-by-step instructions (narrated)

• Available on-demand (internal knowledge base)

3. Lunch & Learn Sessions (Optional, 30-60 Minutes)

• Casual overview of new features (live demo)

• Q&A

• Pizza provided (engagement boost!)

4. Updated User Guides (Maintained Continuously)

• QUALIA updates all user guides after each major release

• Screenshots refreshed (reflect current UI)

• New features added to relevant sections

• Version noted (e.g., "Updated for BC 24 Wave 2")

Testing Strategy for Upgrades

Sandbox Environments: Your Safety Net

What's a Sandbox?

• Copy of production environment (data, configurations, extensions)

• Isolated from production (testing doesn't affect real business)

• Refreshed regularly (monthly or on-demand)

Types of BC Sandboxes:

1. Preview Sandbox (Microsoft Provides)

• Contains upcoming BC version (2 months before GA)

• Purpose: Early testing, extension compatibility validation

• QUALIA uses for pre-upgrade assessment

2. Production Sandbox (Your Regular Test Environment)

• Copy of your production environment

• Purpose: UAT, training, major upgrade testing

• Refreshed before major upgrades (ensure accurate test data)

3. Developer Sandbox (For Custom Extensions)

• Lightweight environment for AL code development

• Purpose: Extension development, unit testing

• QUALIA uses for custom extension updates

Testing Checklist for Major Upgrades

Phase 1: Smoke Testing (QUALIA, 2-3 Hours)

Phase 2: Functional Testing (QUALIA + Super Users, 1 Day)

Phase 3: Performance Testing (QUALIA, 2-4 Hours)

Benchmarking:
  ☐ Large report generation (e.g., 10,000-row inventory valuation)
    - Before upgrade: [X] seconds
    - After upgrade: [Y] seconds
    - Result: [Faster | Same | Slower]
  
  ☐ Batch posting (e.g., 100 sales invoices)
    - Before: [X] minutes
    - After: [Y] minutes
  
  ☐ Search performance (customer lookup with 50,000 records)
    - Before: [X] seconds
    - After: [Y]

Phase 4: User Acceptance Testing (Key Users, 1-2 Days)

Staying Current: The Continuous Upgrade Philosophy

Why "Upgrade Frequently" Is Better Than "Upgrade Rarely"

Traditional Approach (Avoid Until Forced):

QUALIA Recommended Approach (Continuous Updates):

The Math:

• Traditional: €30K every 3 years = €10K/year (plus missed opportunities)

• Continuous: €6K/year (plus access to latest features)

• Savings: €4K/year + competitive advantage from new features

Microsoft Support Lifecycle

Cloud: Always supported (automatically updated)

On-Premises: 12-month support window

QUALIA Recommendation: On-premises clients should upgrade annually minimum (every October or April). Cloud clients benefit from automatic updates (no action required).

Cost-Benefit Analysis: Is Upgrading Worth It?

Costs of Upgrading

Cloud (Automatic Updates):

• Software cost: Included in subscription (no additional license fee)

• QUALIA upgrade service: €800 per major upgrade (or included in managed services)

• Internal effort: 1-2 days testing/validation per upgrade

• Total per upgrade: €800-€2,400

On-Premises (Manual Upgrades):

• Software cost: Included in license (no additional fee for CUs)

• QUALIA upgrade service: €4,800 per major version upgrade

• Internal effort: 2-4 days testing, coordination

• Infrastructure: May require server upgrades (OS, SQL Server) every 2-3 years (€5K-€15K)

• Total per upgrade: €6K-€20K

Benefits of Staying Current

Tangible Benefits (Measurable ROI):

1. Productivity Improvements

• Example (BC 23): AI-powered bank reconciliation matching (40% time reduction)

  • Before: 2 hours/day manual matching (€25/hour) = €12,500/year

  • After: 1.2 hours/day (AI suggests matches) = €7,500/year

  • Savings: €5,000/year

• Example (BC 24): Enhanced approval workflows with mobile notifications

  • Before: 2-day approval cycle (emails missed, delays)

  • After: 4-hour approval cycle (mobile push notification, in-app approval)

  • Impact: Faster order processing, fewer lost deals = €15K-€30K/year revenue uplift

2. Reduced Support Costs

• Older versions accumulate bugs (workarounds, manual processes)

• Current version has bugs fixed (efficiency gained)

• Example: Bug causing duplicate customer entries (1 hour/week cleanup = €1,300/year)

  • Fixed in monthly CU (savings ongoing)

3. Security & Compliance

• Older versions vulnerable to security exploits (data breach risk = €50K-€500K)

• Current version patched (risk mitigated)

• Compliance: GDPR, SOX, HIPAA regulations require timely security updates

4. Integration Advantages

• New BC features enable better integrations (Power Automate connectors, API enhancements)

• Example (BC 22): New Shopify connector (real-time inventory sync)

  • Before: Manual export/import 3x/day (2 hours/day = €12,500/year)

  • After: Automated real-time sync (zero manual effort)

  • Savings: €12,500/year

Intangible Benefits (Harder to Quantify):

1. Competitive Advantage

• Adopt AI, automation, and analytics before competitors

• Faster decision-making (real-time dashboards)

• Better customer experience (faster quotes, accurate inventory availability)

2. Employee Satisfaction

• Modern tools attract talent ("We use cutting-edge technology")

• Less frustration (bugs fixed, workflows streamlined)

• Career development (learning new features = skill growth)

3. Future-Proofing

• Avoid technical debt (don't fall behind, require costly catch-up)

• Easier to adopt new technologies (AI, IoT, advanced analytics)

• Microsoft roadmap alignment (new capabilities designed for current version)

ROI Example: Continuous Updates vs. Deferred Updates

Scenario: 50-user organization, moderate customization

Option A: Continuous Updates (Every Wave)

Option B: Deferred Updates (Every 2-3 Years)

Verdict: Continuous updates save €42,266/year compared to deferred approach (€13,600 gain vs. -€28,666 loss).

Common Upgrade Pitfalls & How QUALIA Prevents Them

Pitfall 1: "We're Too Busy to Upgrade"

What It Looks Like:

• Month-end, quarter-end, year-end always coming up ("bad timing")

• Inventory counts, audits, busy season ("can't risk downtime")

• Result: Never upgrade, fall further behind

QUALIA Solution:

• Identify quiet periods in client's calendar (typically February, May, August, November for most businesses)

• Schedule upgrades 3 months in advance (block calendar before "too busy")

• Minimize disruption: Sandbox testing ensures production upgrade smooth (2-hour downtime only)

Pitfall 2: "Upgrades Break Things"

What It Looks Like:

• Fear of compatibility issues (extensions, integrations)

• Past bad experience (legacy system upgrade went poorly)

• Result: Avoid upgrades, accumulate technical debt

QUALIA Solution:

• Comprehensive sandbox testing (catch issues before production)

• Extension compatibility guarantee (QUALIA apps always ready day 1, ISV apps validated before upgrade)

• Rollback plan (can revert within 7 days if critical issue found)

• Insurance: 20+ years experience, 400+ successful upgrades (proven track record)

Pitfall 3: "We Don't Need New Features"

What It Looks Like:

• "BC 21 works fine, no reason to upgrade"

• "We don't use half the features already"

• Result: Miss opportunities (AI, automation) competitors are leveraging

Solution:

• Release plan review (identify 3-5 features relevant to your business with partner)

• ROI analysis (quantify productivity gains from specific features)

• Pilot programs (try new feature in sandbox, measure impact before committing)

• Competitive intelligence (industry trends and peer adoption of new capabilities)

Pitfall 4: "Upgrades Are Too Expensive"

What It Looks Like:

• View upgrades as discretionary cost (cut when budget tight)

• Don't account for cost of NOT upgrading (productivity loss, security risk)

• Result: Defer upgrades, eventually forced to spend more on large catch-up project

Solution:

• Show total cost of ownership (continuous updates cheaper than deferred)

• Highlight included benefits (managed services plans often cover upgrades + support + optimization)

• Payment plans (spread cost across monthly managed services fee vs. large one-time project)

❓ Frequently Asked Questions (FAQ)

1. Do I need to upgrade Business Central every year?

Answer: Yes, for cloud (SaaS) deployments, Microsoft requires upgrades within 6 months of each major release. For on-premises, upgrades are technically optional but strongly recommended for security, performance, and compatibility. Skipping upgrades creates technical debt, security vulnerabilities, and eventual costly catch-up projects.

Cloud (SaaS) Upgrade Requirements:

Microsoft's Policy:

• Cloud environments must update to latest major release within 6 months of GA (general availability)

• Example: Wave 1 released April 1st → Must upgrade by September 30th (before Wave 2 forces update)

• After 6 months: Microsoft automatically schedules update (you can't defer indefinitely)

Why Microsoft Enforces This:

• Security: Ensures all customers on supported, patched versions (reduces attack surface)

• Compliance: Regulatory requirements often mandate current software versions

• Resource Efficiency: Microsoft doesn't have to support 10+ old versions (focuses engineering on current + next release)

• Innovation Access: Customers benefit from continuous improvements (AI, automation, integrations)

Your Control:

• When to upgrade (within 6-month window): Schedule during low-usage period (weekend, off-peak month)

• Sandbox testing first: Test in sandbox environment before production update

• Rollback option: 7-day window to revert if critical issues discovered

What Happens If You Don't Upgrade (Cloud):

• Month 5-6: Microsoft sends reminder notifications ("Your environment will be updated on [date]")

• Month 6: Microsoft auto-schedules update during your configured maintenance window

• No exceptions (even if you're not ready, update happens)

Best Practice: Don't wait until month 6. Upgrade in months 2-3 (gives time to test, train users, resolve issues before Microsoft forces it).

On-Premises Upgrade Requirements:

Microsoft's Policy:

• No forced upgrade timeline (you control when to update)

• However:

  • Mainstream support: 12 months after major release GA (e.g., BC 23.0 released April 2024 → mainstream support until April 2025)

  • Extended support: Additional 12 months (April 2025 → April 2026)

  • After extended support ends: No security patches, no bug fixes, no Microsoft support

Example (BC 23.0 Timeline):

• GA: April 2024

• Mainstream Support Ends: April 2025 (12 months)

• Extended Support Ends: April 2026 (24 months)

• After April 2026: Unsupported (security risk, compliance issues)

Why You Should Upgrade Annually (Even On-Prem):

1. Security Vulnerabilities:

• Running unsupported version = no security patches when vulnerabilities discovered

• Example: Critical SQL injection vulnerability found (impacts BC 21.0)

  • Supported versions (BC 23.0+): Microsoft releases patch within days

  • Unsupported versions (BC 21.0): No patch available (you're vulnerable)

• Compliance risk: Many frameworks (SOC 2, ISO 27001, HIPAA) require vendor-supported software

2. Extension Compatibility:

• AppSource ISV apps: Vendors typically support current + prior 1-2 versions

• Example: Popular WMS (warehouse management) app

  • Supports: BC 23.0, BC 22.0 (current and prior year)

  • Drops support for: BC 21.0 and earlier

• If you stay on BC 21.0, you lose access to app updates (bug fixes, new features)

• Worse: App may break when vendor updates their code (no longer testing against BC 21.0)

3. Microsoft 365 Integration Drift:

• BC integrates deeply with Microsoft 365 (Teams, Excel, Outlook, Power Platform)

• Microsoft 365 evolves continuously (monthly updates)

• Old BC versions: Integration may break as M365 APIs change

• Example: Power BI connector update breaks BC 20.0 integration (Microsoft fixes in BC 23.0, not BC 20.0)

4. Technical Debt Accumulation:

• Skip 1 year: ~100 new features missed, manageable catch-up

• Skip 2 years: ~200 features missed, significant catch-up effort

• Skip 3+ years: Major version jump (BC 20.0 → BC 23.0), potential breaking changes, costly migration-like project

Example:

• Annual Upgrades: BC 21.0 (2023) → BC 22.0 (2024) → BC 23.0 (2025)

  • Each upgrade: 20-40 hours testing, minimal risk, $3,000-$5,000 cost

  • Total 3-year cost: $9,000-$15,000

• Deferred Upgrade: BC 21.0 (2023) → [skip 2024, 2025] → BC 23.0 (2026)

  • Single large upgrade: 80-120 hours (test all accumulated changes), high risk, $12,000-$20,000 cost

  • Plus: Lost productivity from missing 2 years of improvements

5. Talent Acquisition:

• Consultants/developers prefer working with current technology

• Job postings: "BC 23.0 experience" attracts more qualified candidates than "BC 19.0 experience"

• Aging platform makes hiring and retaining talent harder

When On-Premises Annual Upgrades Might Be Skipped:

Acceptable Scenarios (with caution):

1. Sunset/Migration Planning:

• Planning to migrate to cloud or different ERP within 12-24 months

• Cost-benefit: Don't invest in on-prem upgrade if sunsetting soon

• Mitigation: Ensure still within extended support period (not fully unsupported)

2. Major Customization Rebuild Required:

• Heavy custom code incompatible with new version (extensive refactoring needed)

• Budget/time not available this year

• Mitigation:

  • Plan upgrade for following year (don't skip indefinitely)

  • Apply monthly security updates to current version (at minimum)

  • Document technical debt and risk

3. Stability Over Innovation:

• Ultra-risk-averse industry (e.g., regulated pharma, defense)

• "If it's not broken, don't fix it" culture

• Mitigation:

  • Still upgrade every 2 years maximum (not 3+)

  • Rigorous sandbox testing (4-6 weeks minimum)

  • Phased rollout (pilot users first)

Not Acceptable Reasons to Skip:

❌ "We're too busy": Upgrades never convenient; plan during slow period (Q1, summer)

❌ "We don't need new features": Security and compatibility more important than features

❌ "Last upgrade had issues": Improve upgrade process (better testing), don't avoid upgrades

❌ "Too expensive": Deferred upgrades cost more long-term (see 3-year example above)

Recommended Upgrade Frequency:

Annual Upgrade Checklist (On-Premises):

Q1 (January-March) - Planning:

• Review release notes for Wave 2 (October release)

• Identify relevant features and required training

• Budget upgrade for Q2/Q3

Q2 (April-June) - Testing:

• Install major release in sandbox (April GA)

• Regression testing (4-6 weeks)

• Extension compatibility validation

• User acceptance testing

Q3 (July-September) - Execution:

• User training on new features

• Schedule production upgrade (off-peak weekend)

• Execute upgrade

• Post-upgrade validation

Q4 (October-December) - Optimization:

• Adopt new features (Copilot, automation, integrations)

• Measure productivity improvements

• Plan next year's upgrade

Bottom Line:

✅ Cloud: Must upgrade every 6 months (Microsoft enforces). Optimize testing/training to minimize disruption.

✅ On-Premises: Should upgrade every 12 months (annually). Skipping creates security risk, technical debt, and higher long-term costs.

❌ Never: Let environment go unsupported (beyond extended support end date). Security and compliance nightmare.

2. What is the Business Central release schedule and wave system?

Answer: Business Central follows a predictable bi-annual release schedule with two major "Release Waves" per year (April and October), each previewed 2 months in advance. This rhythm enables organizations to plan upgrades, budget resources, and prepare users for new capabilities.

The Release Wave System Explained:

Wave 1 (Spring Release):

Timeline:

• February 1st: Release Plan published (docs.microsoft.com/dynamics365/release-plan)

  • 100+ pages detailing every feature, change, and improvement

  • Includes: Feature descriptions, screenshots, videos, business value, technical details

  • Availability: Generally Available (GA), Preview, Planned

• February-March: Preview Environment available

  • Early adopters can test features before GA

  • Feedback influences final release (minor adjustments possible)

• April 1st: General Availability (GA)

  • Cloud: Rollout begins (all environments updated within 6 months)

  • On-Premises: Installation media available for download

• April-September: Update window

  • Cloud customers schedule update within this 6-month window

  • On-premises customers plan and execute at their pace (recommended by August)

Typical Wave 1 Content:

• New Features: 50-100 (varies by year)

  • Example (2025 Wave 1): Copilot bank reconciliation, sales line suggestions, enhanced mobile app

• Platform Improvements: Performance, UI, developer tools

• Compliance Updates: Tax law changes (effective in new fiscal year), regulatory requirements

• Deprecated Features: 12-month notice ("Feature X will be removed in 2026 Wave 1")

Wave 2 (Fall Release):

Timeline:

• August 1st: Release Plan published

• August-September: Preview Environment

• October 1st: General Availability

• October-March: Update window (6 months)

Typical Wave 2 Content:

• New Features: 50-100

  • Example (2025 Wave 2): AI demand forecasting, advanced approval workflows, e-commerce enhancements

• Platform Improvements: Continued iteration

• Year-End Compliance: Tax tables for upcoming calendar year, statutory reporting changes

Why Two Releases Per Year?

Microsoft's Rationale:

1. Competitive Pace:

• Cloud ERP market moves fast (SAP, Oracle, NetSuite release continuously)

• Bi-annual cadence keeps BC competitive with latest innovations

• Annual releases too slow (miss market opportunities)

• Quarterly releases too frequent (change fatigue, testing burden)

2. Customer Feedback Loop:

• 6-month cycle allows:

  • Wave 1 release → customer feedback → Wave 2 adjustments

  • Iterative improvement based on real-world usage

3. Predictable Planning:

• Customers know when releases occur (April, October)

• Budget and resource planning (allocate upgrade time, training budget)

• Vendor ecosystem alignment (AppSource ISVs release updates in sync)

4. Cloud Infrastructure Efficiency:

• Consolidate infrastructure changes into bi-annual releases

• Avoid constant small updates disrupting operations

• Balance innovation with stability

Monthly Cumulative Updates (CUs):

Between major releases, Microsoft releases monthly updates:

Schedule: First Tuesday of each month (similar to Windows "Patch Tuesday")

Naming Convention:

• BC 23.0 (April 2024 release)

  • CU 1 (May 2024)

  • CU 2 (June 2024)

  • ...

  • CU 6 (October 2024) → Becomes BC 24.0 (October major release)

Content:

• Bug Fixes: Resolve reported issues from GA release

• Security Patches: Address vulnerabilities discovered post-release

• Performance Improvements: Optimize slow queries, fix memory leaks

• Minor Features: Small improvements not requiring extensive testing

Cloud vs. On-Premises:

• Cloud: Cumulative updates applied automatically during maintenance windows (usually minimal downtime, <5 minutes)

• On-Premises: Manual download and installation (recommended monthly, but often skipped until quarterly or semi-annual)

Example CU Contents (BC 23.0 CU 3):

• Fix: Sales Invoice posting error when using specific dimension combinations

• Security: Patch SQL injection vulnerability in custom report parameters

• Performance: Optimize Item Ledger Entry query (20% faster on large datasets)

• Minor Feature: Add new field to Customer Card for GDPR consent tracking

Release Wave vs. Cumulative Update Comparison:

Release Plan: Your Upgrade Roadmap:

How to Use Release Plans:

Step 1: Access Release Plan (2 months before GA):

• URL: docs.microsoft.com/dynamics365/release-plan/2025/wave-1/ (or /wave-2/)

• Filter by product: Business Central

• Download PDF or read online

Step 2: Review with Implementation Partner (6-8 weeks before GA):

• Schedule 1-2 hour review meeting

• Partner highlights features relevant to your industry/use case

• Identify: "Must adopt," "Nice to have," "Not applicable"

Step 3: Prioritize Feature Adoption:

Example (Manufacturing Company, 2025 Wave 1):

Step 4: Plan Training and Communication:

• "Must Adopt" features: Formal training sessions (1-2 hours per feature)

• "Nice to Have" features: Email announcement, self-service training (videos, guides)

• "Not Applicable": No communication needed

Step 5: Budget and Schedule:

• Estimate upgrade cost (partner testing, deployment, training)

• Schedule upgrade during low-usage period (avoid month-end, quarter-end, peak season)

• Allocate internal resources (SMEs for UAT, users for training)

Release Wave Naming Convention:

Version Numbers:

• Major Version: Changes with each Wave (BC 22.0, BC 23.0, BC 24.0)

• Cumulative Update: Increments monthly (BC 23.1 = CU 1, BC 23.2 = CU 2)

Example Timeline:

• April 2024: BC 23.0 (Wave 1 2024)

• May 2024: BC 23.1 (CU 1)

• June 2024: BC 23.2 (CU 2)

• ...

• October 2024: BC 24.0 (Wave 2 2024)

• November 2024: BC 24.1 (CU 1)

Historical Note: Prior to 2020, BC used different naming (NAV-style versions like BC 14.0, BC 15.0). Current system (year + wave) adopted for clarity.

Long-Term Support (LTS) - Not Available:

Unlike some enterprise software (e.g., Ubuntu LTS, Windows Server LTSC), Business Central does not offer Long-Term Support versions.

Why?

• Cloud-first strategy: Microsoft prioritizes continuous innovation over extended support

• Resource efficiency: Supporting many old versions drains engineering resources

• Customer benefit: Microsoft believes continuous updates deliver more value than stability of old versions

Implication: Can't stay on single version for 5-10 years (common with legacy ERP). Must embrace bi-annual upgrade rhythm.

Partner-Managed Upgrade Services:

Most organizations engage Microsoft Solutions Partners for upgrade management:

Typical Services:

• Pre-Upgrade Assessment (4-8 hours): Review release notes, identify relevant features, plan testing approach

• Sandbox Testing (20-40 hours): Deploy update to sandbox, execute test scripts, validate extensions

• User Communication (4-8 hours): Create "What's New" guides, schedule training sessions, send announcements

• Production Deployment (4-8 hours): Schedule maintenance window, execute upgrade, post-upgrade validation

• Post-Upgrade Support (10-20 hours): Hypercare for 1-2 weeks post-upgrade, issue resolution

Cost: $1,000-$3,000 per major release (cloud) or $3,000-$8,000 (on-premises)

Value: Peace of mind, expert execution, minimized disruption, user enablement

3. How do I test Business Central updates before applying to production?

Answer: Test Business Central updates using a sandbox environment that mirrors production, following a structured process: deploy update to sandbox, execute regression testing scripts covering critical business processes, validate custom extensions and integrations, conduct user acceptance testing (UAT), and document results before scheduling production update.

Sandbox Testing Framework:

Step 1: Provision Sandbox Environment

Cloud (SaaS):

Sandbox Types:

• Production Sandbox: Copy of production environment (data, extensions, customizations)

  • Use for: Realistic testing with actual customer/vendor/item data

  • Refresh frequency: Weekly or on-demand (copy latest production data)

• Sandbox: Empty BC environment for experimentation

  • Use for: Testing new features without production data constraints

How to Create Production Sandbox:

1. BC Admin Center (admin.businesscentral.microsoft.com)

2. Environments tab → New → Sandbox

3. Select "Production environment" as source → Name it (e.g., "Production-Sandbox-Wave1-2025")

4. Wait 1-2 hours for copy to complete

Result: Sandbox with production data as of copy time, ready for update testing

On-Premises:

Sandbox Setup:

• Clone production VM or physical server

• Restore production database to sandbox SQL Server

• Update BC service configuration (point to sandbox database)

• Change URLs/ports to avoid conflict with production

• Disable outbound integrations (prevent sandbox from posting to live CRM, e-commerce, etc.)

Infrastructure: Requires separate hardware/VM (can be lower spec than production)

Step 2: Deploy Update to Sandbox

Cloud:

• Automatic: Microsoft auto-updates sandbox environments ~2 weeks before production update window

• Manual: In Admin Center, select sandbox → Update → Schedule Update (choose specific CU or major version)

• Result: Sandbox on new version, production still on old version (side-by-side testing)

On-Premises:

1. Download update installer from Microsoft Download Center

2. Run installer on sandbox server (not production)

3. Execute database upgrade scripts (BC setup wizard)

4. Restart BC services

5. Verify sandbox on new version (Help → About shows version number)

Step 3: Regression Testing

What to Test:

Test critical business processes end-to-end, not just "click around."

Example Test Scenarios (Manufacturing Company):

1. Order-to-Cash (20 test cases):

• Create sales quote → Convert to order → Check inventory availability (ATP)

• Reserve inventory → Create warehouse pick → Register pick

• Post shipment → Post sales invoice

• Apply customer payment → Reconcile bank

• Verify: No errors, expected GL postings, reports show correct data

2. Procure-to-Pay (15 test cases):

• Create purchase order → Post receipt

• Match vendor invoice (3-way match: PO, receipt, invoice)

• Approve invoice (workflow) → Post invoice

• Create payment → Post payment → Reconcile bank

• Verify: AP aging correct, vendor balance accurate

3. Production Planning (10 test cases):

• Create production order from sales forecast

• Explode BOM (bill of materials) → Check component availability

• Post consumption → Post output

• Finish production order → Cost valuation

• Verify: Inventory transactions, WIP accounts, finished goods cost

4. Financial Reporting (10 test cases):

• Generate trial balance (compare to pre-upgrade baseline)

• Run P&L, balance sheet (verify no unexpected changes)

• Period-end close procedures (close income statement, create new fiscal year)

• Verify: Financial statements match expectations, no broken reports

5. Integrations (critical):

• CRM Integration: Create sales order in CRM → Syncs to BC?

• E-Commerce: Place web order → Creates BC sales order?

• EDI: Send PO via EDI → Vendor receives?

• Banking: Import bank statement → Auto-reconciliation works?

• Power BI: Refresh dashboards → Data current?

• Verify: All integrations functional, no API errors

Testing Duration:

• Minimal (Small Org, Vanilla BC): 1 week (40 hours total, 1-2 testers)

• Standard (Mid-Size, Moderate Customizations): 2-3 weeks (80-120 hours, 3-5 testers)

• Comprehensive (Large, Complex): 4-6 weeks (200-400 hours, 10-20 testers)

Step 4: Extension Compatibility Testing

AppSource Apps:

Check Compatibility:

• AppSource app detail page → "Supported Versions"

• Example: "Continia Document Capture" supports BC 22.0 - 24.0

• If new BC version (e.g., BC 25.0) not listed:

  • Contact ISV: "When will your app support BC 25.0?"

  • ISVs typically release updates 1-2 weeks after BC major release GA

  • Delay production upgrade until AppSource apps certified

Test in Sandbox:

• Install updated app version in sandbox

• Test app functionality (document capture, approval routing, whatever app does)

• Verify no errors, no performance degradation

Custom AL Extensions:

Compilation Test:

1. Open AL extension project in VS Code

2. Update dependencies in app.json (change BC version from 23.0 to 24.0)

3. Compile extension (Ctrl+Shift+B)

4. If compilation errors:

   • Deprecated API: Replace with new recommended API (see BC release notes, breaking changes section)

   • Changed object: Adjust extension code to align with BC platform changes

   • Resolve errors before deploying to sandbox

Functional Testing:

• Deploy compiled extension to sandbox

• Test custom functionality (e.g., custom pricing logic, custom reports, workflow extensions)

• Verify business logic still works as expected

Performance Testing:

• Run performance benchmarks (e.g., time to post 1,000 sales invoices with custom extension)

• Compare to pre-upgrade baseline

• If significant degradation (>20% slower), investigate (could be BC platform change affecting your code)

Step 5: User Acceptance Testing (UAT)

Who Tests: End users (not just IT), representing each role (finance, sales, warehouse, purchasing)

What They Test: Real business scenarios they perform daily

Example UAT Script (Sales Representative):

UAT Scenario: Process Customer Order (Standard Daily Workflow)

Steps:
1. Search for customer "Adatum Corporation" (use Tell Me search)
2. Create new sales order
3. Add 5 line items (mix of stock items and special order items)
4. Check inventory availability (ATP feature)
5. Apply customer discount (validate pricing engine)
6. Reserve inventory for order
7. Print sales order confirmation
8. Email order confirmation to customer (via BC)

Expected Results:
- All steps complete without errors
- Search is fast (<3 seconds)
- Pricing correct (discount applied automatically)
- ATP shows accurate availability
- Printed document formatted correctly
- Email sends successfully

Actual Results: [Tester fills in]

UAT Duration: 1-2 weeks (users test during normal work, not full-time)

UAT Sign-Off: Users formally approve ("I'm comfortable with this update in production") before production deployment

Step 6: Document Results

Test Summary Report:

Template:

Step 7: Schedule Production Update

Cloud:

1. BC Admin Center → Production Environment → Update

2. Schedule update: Select date/time within maintenance window

3. Notify users: Send email 1 week before ("BC will be unavailable June 15, 6pm-10pm")

4. Execute: Microsoft applies update at scheduled time

5. Post-Update Validation: Log in, smoke test critical processes (1-2 hours)

On-Premises:

1. Schedule maintenance window (weekend or evening, 4-6 hour buffer)

2. Notify users (email, Teams announcement)

3. Backup production database (full backup before upgrade)

4. Execute upgrade installer (following Microsoft upgrade documentation)

5. Post-upgrade validation

6. Notify users when production available

Step 8: Post-Update Monitoring (First Week)

Monitor:

• User-reported issues (support tickets)

• Performance metrics (page load times, report execution)

• Integration health (error logs, transaction volume)

• User sentiment (quick pulse survey: "How is the update going?")

Hypercare: Partner provides elevated support first 1-2 weeks post-update (faster response times)

Testing Best Practices:

✅ Test early: Don't wait until month 5 of 6-month update window

✅ Test realistically: Use production data (sandbox copy), not fake test data

✅ Test comprehensively: All critical processes, not just "happy path"

✅ Test integrations: Most upgrade issues involve third-party integrations breaking

✅ Involve users: UAT by actual users catches issues IT wouldn't find

✅ Document: Test results provide audit trail and inform future upgrades

Testing Anti-Patterns (Avoid These):

❌ "We'll test in production": Reckless; issues disrupt business

❌ "Just click around": Unstructured testing misses critical issues

❌ "IT will test everything": Users know business processes better; involve them

❌ "One day of testing is enough": Insufficient for complex environments

❌ "Skip testing cumulative updates": Monthly CUs usually safe, but occasionally introduce issues

Automated Testing (Advanced):

For large organizations or frequent testing:

BC Test Toolkit:

• Microsoft's test automation framework (AL-based test codeunits)

• Write test scripts once, run repeatedly (every CU, every wave)

• Example: Automated test suite (200 test cases) runs in 2 hours vs. 40 hours manual testing

• ROI: High upfront effort (write tests), ongoing savings (faster regression testing)

Azure DevOps Integration:

• Continuous integration pipeline

• Automatically deploy updates to sandbox → run test suite → report results

• Ideal for: Complex environments, frequent updates, large dev teams

Conclusion: Continuous Improvement is Continuous Upgrades

Business Central's bi-annual release cadence is designed to keep you competitive—new features, performance improvements, and security enhancements delivered like clockwork.

Organizations that embrace continuous upgrades: ✅ Stay at the cutting edge (AI/Copilot, automation, integrations)
✅ Minimize upgrade risk (small incremental changes vs. large infrequent projects)
✅ Reduce costs (predictable annual spend vs. expensive catch-up projects)
✅ Maximize ROI (immediate access to productivity features)
✅ Future-proof their business (technical debt never accumulates)

Successful upgrade management requires experienced Microsoft Solutions Partners who understand both the technical upgrade process and change management needed to realize value from new capabilities.

Partner-managed upgrade services ensure you stay current without the burden:

• Pre-upgrade assessment: Identify relevant features, validate compatibility

• Sandbox testing: Catch issues before production

• Smooth execution: Minimal downtime, maximum confidence

• Post-upgrade support: User training, issue resolution, optimization

Successful Business Central operations balance stability with innovation—staying current with Microsoft's release cycle while ensuring each upgrade delivers measurable business value.

Key Takeaways:

• Microsoft releases two major updates per year (April and October) plus monthly cumulative updates

• Cloud deployments receive automatic updates within scheduled maintenance windows

• Extension compatibility is the primary upgrade challenge—test AppSource apps and custom extensions in sandbox before production upgrades

• Continuous small upgrades are less risky and less expensive than infrequent large catch-up projects

• Partner-managed upgrade services typically cost $1,000-$8,000 depending on cloud vs. on-premises and complexity

This is Part 11 of an 11-part series on Business Central Implementation. You've completed the series! Review earlier parts for deeper dives into specific implementation phases.

Series Overview:

• Part 1: Foundation, Discovery & Planning

• Part 2: Requirements Gathering & Process Mapping

• Part 3: System Configuration & Setup

• Part 4: Data Migration Strategy & Execution

• Part 5: Customization, Extensions & Integration

• Part 6: AI & Copilot Capabilities

• Part 7: Training, Change Management & User Adoption

• Part 8: Go-Live, Hypercare & Continuous Improvement

• Part 9: Migrating from Legacy ERP to Business Central

• Part 10: Business Central Support and Optimization

• Part 11: Business Central Upgrades—Stay Current (this article)

Published January 2026 as part of the Business Central Implementation Series.