Most Business Central teams assume moving to the cloud means flipping a switch. The ones who've done it will tell you the switch part takes a weekend. The three months before that is where the real work happens.
When you shift to BC SaaS, Microsoft takes over your hosting, your updates, and your disaster recovery. What they don't take over is your integrations, your extensions, or your update readiness. Those land back on you, and they need to be planned before you schedule a go-live date.
What Changes When You Move Business Central to the Cloud
Cloud migration reshapes how your entire system operates.
The shift to Business Central SaaS covers four areas licensing, infrastructure, extensions, and updates. Each one requires a detailed review before making a migration decision.
On-premises BC uses a perpetual license model. You pay upfront for licenses and an annual BREP (Business Ready Enhancement Plan) fee to stay current on versions. With BC SaaS, you move to a per-user monthly subscription. Essential users cost less than Premium users, and you can mix license types across your team.
The financial impact depends on your user count and current maintenance costs. For many SMBs and mid-market companies, the shift to subscription reduces total three-year cost, primarily because it eliminates hardware, SQL Server licenses, and internal IT overhead. For others, it costs more, check the cost comparison section below for more information.
On-premises BC runs on your own Windows Server and SQL Server instances, hosted in your data center or a private hosting environment. You manage backups, patches, security updates, and performance tuning.
With BC SaaS, Microsoft runs your environment on Azure. No hardware refresh cycles. No SQL Server licensing. No in-house DBA time spent on BC maintenance. Microsoft provides a 99.9% uptime SLA with geo-redundant storage and automated daily backups.
The trade-off: you lose direct SQL access to your BC database. If any of your reporting, integrations, or data extracts query BC SQL tables directly, those connections break at migration. They need to be replaced with BC's API layer.
Business Central on-premises supports two types of code: C/AL older customizations running directly on the NAV/BC platform and AL extensions modern, cloud-ready code isolated from the core system.
BC SaaS only supports AL extensions. C/SIDE add-ons, legacy C/AL modifications embedded in the base application, and ISV solutions not available on Microsoft AppSource do not run in the cloud. Every add-on and customization in your on-prem environment needs to be assessed before you set a go-live date.
| Customization Type |
Cloud Status |
| AL extension, AppSource-listed |
Carries over cleanly |
| AL extension, not AppSource-listed |
Deploy as per-tenant extension |
| C/SIDE or C/AL modification |
Must be rewritten in AL before migration |
| Third-party ISV not on AppSource |
Contact vendor, find alternative, or rebuild |
The scope of this assessment and the remediation work it requires is the single biggest variable in your migration timeline and budget.
On-premises BC lets you apply updates on your own timeline. Many companies run 12 to 18 months behind either because of update risk concerns or because customizations haven't been tested against new versions.
BC SaaS runs on Microsoft's release schedule. Two major updates per year, Wave 1 in April, Wave 2 in October. Minor updates monthly. You can defer major updates by up to 90 days. You cannot skip them permanently.
Your extensions, integrations, and business processes need to absorb updates twice a year. AL extensions you deploy need to stay compatible with each release. This changes how your development and testing cycle works post-migration and it's a conversation to have with your partner before you go live, not after.
What Stays The Same When You Migrate Business Central To Cloud
Migration keeps the foundation while modernizing the environment.
For most end users, the day after go-live looks almost identical. The migration complexity is on the infrastructure and technical side not on the process or finance side.
| Category |
Notes |
| Core BC functionality |
Finance, Supply Chain, Projects, Manufacturing — all same features |
| Business logic and processes |
Workflows stay the same |
| User interface |
Modern Web Client is identical in on-prem and SaaS |
| Master data |
Customers, vendors, items, GL accounts migrate as-is |
| Role Center experience |
No meaningful difference for end users |
| Reporting structure |
RDLC and Word layouts carry over; Power BI integration unchanged |
| Multi-company setup |
Fully supported in SaaS |
| Dimensions and analysis |
No change |
How Integrations Change After Moving to Business Central SaaS
Most migration risks begin where systems connect.
On-premises BC integrations often connect directly to the SQL Server database. Web services, legacy middleware tools, ODBC connections, and report writers frequently query BC tables directly. When you remove the on-prem SQL Server, every one of those connections stops working. The data is still there. The access method changes entirely. In BC SaaS, all external connections must go through BC's API layer either via OData v4 APIs, published REST APIs, or custom APIs built as AL extensions.
| Integration Type |
On-Prem Approach |
SaaS Replacement Needed? |
| Direct SQL query |
SQL SELECT to BC tables |
Yes — rebuild via OData or BC API |
| ODBC connection |
SQL Server ODBC driver |
Yes — API-based connector required |
| Web services (SOAP/OData) |
BC published web services |
Mostly carries over; OData v4 preferred |
| Power Automate / Power Apps |
Supported |
No change — carries over |
| Third-party middleware (Scribe) |
SQL or REST connector |
Update connector to use API |
| Azure Data Factory |
SQL pull |
Update to BC API connector |
| EDI / XML |
Depends on middleware |
Review case-by-case |
Before you go live, every integration needs to be inventoried, assessed, and tested in a sandbox environment. Integrations that look simple often have edge cases error handling logic, retry mechanisms, and date format differences that only surface under load.
On-Prem vs SaaS: Licensing and Cost Comparison
We reveal the hidden fees that most leave out of their quotes.
There is no single answer to whether SaaS costs more or less than on-premises. The honest comparison depends on your user count, current infrastructure spend, and how much internal IT time BC currently consumes.
| Cost Category |
On-Premises |
SaaS |
| License model |
Perpetual + annual BREP |
Monthly subscription per user |
| Infrastructure |
Windows Server + SQL Server (CapEx) |
Included in subscription |
| Hardware refresh |
Every 3–5 years |
None |
| IT management overhead |
SQL patching, backup, uptime monitoring |
Eliminated — Microsoft manages |
| Disaster recovery and backup |
DIY or third-party cost |
Included in SaaS |
| Security patching |
Manual / internally managed |
Automatic |
| Update management |
Your schedule |
Microsoft Wave schedule (deferrable 90 days) |
For companies with 20 to 100 users, the shift to SaaS typically breaks even or comes out ahead over three years when you factor in eliminated infrastructure costs. For smaller companies already running lean on infrastructure, the licensing cost increase may not be offset quickly.
Cutover Planning and Downtime While Migrating to Business Central Online
Successful migrations are won during cutover planning.
Business Central SaaS migrations can be done with a planned cutover window typically a weekend. The migration itself uses Microsoft's cloud migration tool, which replicates your on-prem database to BC Online in a sandbox environment first. You test, validate, and then execute the final cutover.
Realistic downtime for a standard migration ranges from 8 to 24 hours for the final cutover, depending on data volume and integration switch-over complexity. Parallel running keeping on-prem live while SaaS is in testing is possible and recommended during the UAT phase.
The risks most companies underestimate at cutover:
-
Integration go-live dependencies
—
all integrations need to switch simultaneously; a partial switch creates data consistency problems
-
Open transactions
—
open orders, journals, and workflows need to be resolved or cleanly migrated before cutover
-
User access changes
—
moving from Windows authentication to Microsoft Entra ID (Azure AD) requires user provisioning in advance, not the morning of go-live
-
VPN removal
—
users who access on-prem BC through a corporate VPN need to understand SaaS is browser-based; no VPN required
Comparing Disaster Recovery in On-Premises and Cloud
You trade direct control for resilience and scalability.
On-premises BC disaster recovery requires your own backup strategy manual SQL backups, Azure Backup, or a third-party tool. Recovery time depends on how well that strategy was designed and tested.
Business Central SaaS provides:
- Daily automated backups with a 30-day retention window
- Point-in-time restore capability (Microsoft-managed)
- Geo-redundant storage with data replicated across Azure regions
- 99.9% uptime SLA from Microsoft
You give up direct control over backup schedules. You gain enterprise-grade reliability that most SMBs and mid-market companies couldn't build or afford independently. SaaS backup restore is a Microsoft-supported process if you need a restore, you open a support ticket. Most clients find this trade-off acceptable as the reliability improvement more than offsets the control loss.
If your business requires RTO under four hours, raise this with your partner before you migrate.
Our Business Central On-Premises to Cloud Migration Process
Every migration stage is planned before execution begins.
A well-run Business Central cloud migration follows five stages. Each stage produces a defined output. Nothing moves forward until that output is verified. Here is how we run it and what you should hold any migration partner accountable to.
1
Stage 1 -Assessment and Discovery
We audit your current environment: AL vs C/AL extensions, integration inventory, SQL dependency map, user count and license structure, and update history. Every item gets classified by migration complexity and risk level. Timeline: 2–3 weeks.
Deliverable: Risk-classified migration scope document.
2
Stage 2 -Extension and Integration Remediation
Any C/SIDE customizations get rewritten in AL. SQL-dependent integrations get rebuilt against BC APIs. We validate each piece in a sandbox environment before moving forward. Nothing proceeds to environment setup until this layer is clean. Timeline: 4–12 weeks, varies by scope.
Deliverable: Validated extension package and integration test results.
3
Stage 3 - Cloud Environment Setup and Data Load
We configure your BC Online tenant, set up Microsoft Entra ID for user provisioning, configure your production and sandbox environments, and execute an initial data load for UAT. Data is reconciled against your on-prem source before UAT begins.
Deliverable: Configured cloud environment with reconciled data load.
4
Stage 4 - UAT and Integration Testing
Your team tests end-to-end business processes in the cloud environment. We run integration tests, regression tests, and performance validation under realistic data loads. All critical business scenarios need sign-off before a cutover date is set. Timeline: 2–4 weeks.
Deliverable: Signed UAT completion report.
5
Stage 5 - Cutover and Post-Go-Live Support
We execute the final cutover, switch all integrations simultaneously, confirm all users are live on the new environment, and provide dedicated post-go-live support while your team stabilizes. Hypercare coverage includes functional and technical support with defined SLAs. Timeline: 1–4 weeks post go-live.
Deliverable: Go-live confirmation and support plan.
Frequently Asked Questions
What is Business Central on-premises to cloud migration?
It's the process of moving your BC environment from a self-hosted Windows Server / SQL Server setup to Microsoft's cloud-hosted SaaS platform (Business Central Online), which runs on Azure.
Do my existing BC customizations work in the cloud?
Only AL extensions that are either AppSource-listed or deployed as per-tenant extensions will run in BC SaaS. C/SIDE modifications and direct base-code changes do not work in the cloud. They need to be converted to AL extensions before migration. The scope of that conversion work is discovered during the assessment stage.
How long does the migration take?
Timeline depends primarily on extension remediation scope and integration complexity. A standard migration with limited customizations takes 8 to 16 weeks from assessment to go-live. Heavily customized environments with complex integrations can take 20 to 30 weeks. The assessment stage in Week 1 gives you a reliable range before any work begins.
Can I test in the cloud before going live?
Yes. BC SaaS includes a sandbox environment. We load your data and run the full UAT phase in the sandbox before any cutover decision is made. No go-live date is set until UAT is signed off.
What happens to my existing integrations?
Integrations that use direct SQL connections to your BC database will break and need to be rebuilt using BC's OData or REST APIs. Web service-based integrations may carry over with minimal changes. Every integration should be inventoried and tested before go-live. See the integration table earlier in this page for a full breakdown by integration type.
Will Microsoft update my system automatically?
Yes. Microsoft releases Wave 1 updates in April and Wave 2 in October each year, plus minor monthly updates. You can defer major updates by up to 90 days. You cannot opt out of updates permanently. Your extensions and integrations need to be built to survive updates.
What is the cost difference between on-premises and SaaS?
It depends on your user count and current infrastructure spend. SaaS eliminates hardware, SQL Server licensing, IT management overhead, and backup infrastructure costs. For most companies with 20 to 100 users, the three-year total cost of ownership is comparable or lower on SaaS. For smaller companies running lean infrastructure, it may cost more. We can model your specific numbers see the cost comparison section above.
Do I need downtime for the migration?
Yes, but it is planned. Most migrations use a weekend cutover window of 8 to 24 hours for the final go-live. Data is pre-loaded and tested before the cutover window. The window is used primarily for integration switching and final validation.
Is BC SaaS more secure than on-premises?
For most SMBs and mid-market companies, yes. Microsoft provides enterprise-grade security controls, automated security patching, Azure infrastructure security, and compliance certifications including SOC 2, ISO 27001, and GDPR coverage. On-premises security is only as strong as what your organization invests in it. For most SMBs, that investment does not match what Microsoft applies to Azure.
Can we run on-prem and cloud in parallel?
Yes, during the migration phase. Many clients run both environments in parallel during UAT and the pre-cutover period. You should not run both in production long-term as it creates data synchronization complexity and effectively doubles your infrastructure costs. Parallel running should have a defined end date agreed before the migration begins.