Key takeaways
- Cloud migration is not a simple database clone: legacy C/AL modifications must be decoupled and rewritten into clean AL extensions.
- The official Microsoft Cloud Migration Tool synchronises SQL data into the cloud tenant in the background, reducing go-live downtime to a few weekend hours.
- Pre-migration data cleansing saves operational costs: large binary attachments and archived fiscal years should be pruned or offloaded to cold storage.
- Promotions such as Microsoft's 'Bridge to the Cloud' offer up to 40% discounts on cloud subscription licenses for customers with active on-premises maintenance.
The 5 phases of a successful cloud migration
A structured migration follows five distinct phases designed to maintain operational continuity throughout:
- Phase 1: Discovery & Code Audit (C/AL analysis, vetting legacy add-ons, mapping integrations to shop, bank, and logistics).
- Phase 2: Data Cleansing & Archiving (Purging change logs, archiving completed fiscal years, reducing database footprint).
- Phase 3: AL Extension Engineering & AppSource Sourcing (Rewriting custom business logic using modern AL event subscribers).
- Phase 4: Test Replication & User Acceptance Testing (UAT) (Syncing live data to a cloud sandbox environment, key-user verification).
- Phase 5: Cutover Weekend & Go-Live (Final delta sync, switching API endpoints, cutover validation, and hypercare support).
Technical insight: How the Cloud Migration Tool works
For systems running Business Central 14 or higher on-premises, Microsoft provides an automated replication framework: the Cloud Migration Tool. It bridges your on-premises SQL Server database to your Business Central Online tenant via an Azure Self-Hosted Integration Runtime.
Tables are replicated securely in the background while your daily business continues uninterrupted. On cutover day, only the incremental delta is synced, reducing downtime from days to a few hours.
Common pitfalls: What most companies underestimate
The most common mistake is attempting a 1:1 lift-and-shift of 15 years of legacy custom code. Many historical modifications are now natively handled by standard BC features or certified AppSource apps.
Second: integrations. Local file drops (CSV files placed on local file shares) do not exist in SaaS environments. Integrations must transition to modern REST APIs, OData web services, or Azure Blob storage.
Frequently asked questions
- All general ledger, customer, vendor, and item ledger entries can be migrated completely. Alternatively, historical closed years can be archived into a read-only database to preserve storage limits.
- Every Business Central tenant receives a standard 80 GB base database capacity plus 2–3 GB per Essential/Premium license. Additional storage packs can be added dynamically if needed.
- Yes. For versions prior to BC 14, an interim technical upgrade step is executed or data is migrated via automated Configuration Packages. We determine the most cost-effective path in our initial analysis.