Most people assume that moving from on-premises ERP to the cloud is just a technical upgrade. In reality, Business Central on-premises to online migration is a much bigger shift. It changes how your ERP is operated, how data moves, how upgrades happen, how security is managed, and how the system evolves over time. It is not simply about moving servers. It is about changing the operating model of your core business system.
What Business Central Cloud Migration Really Is (and Isn’t)
If you are coming from a Business Central on-premise environment, you are probably thinking about cloud migration in a very specific way.
It is natural to assume that moving to Business Central online means your existing system is simply being hosted in Microsoft’s cloud.
That is not how Business Central cloud migration works.
Business Central online migration is not application migration. It is database-level data replication followed by platform alignment.
Your on-premise SQL database becomes a source of business data, not a running application. Business Central online connects directly to that database and copies company data table by table into its own Azure SQL database. No Business Central Server is involved. No application logic runs during migration. Users, roles, and permissions inside Business Central are not considered. Only SQL access matters.
Meanwhile, your on-premise environment continues to operate independently and remains the system of record until you explicitly switch over.
Business Central online is a managed SaaS platform. It is continuously updated. It is event-driven. It is designed around configuration, extensions, and supported integration points. It is not designed to carry forward deep database customizations, tightly coupled logic, or on-prem-style behavior.
Approaching the migration as “moving the system” leads to the most common failures. You end up paying for SaaS while still carrying on-prem complexity.
The correct way to think about this migration is that you are moving business data into a new operating model, validating it, upgrading it to match the cloud platform, and then adapting processes to how Business Central online is meant to work.
Core Architecture Behind the Migration
Understanding how the migration is technically executed is essential. Most migration issues happen when teams assume Business Central logic or servers are involved in the data move. They are not.
Business Central on-premises to online migration is a direct database-to-database transfer. Data moves from your source SQL database into the Business Central online Azure SQL database using Azure Data Factory. No Business Central Server is used at any stage of this process.
If you understand that single fact, many common mistakes are avoided.
Key Components Explained
On-premises database
This is your source database. It can be a SQL Server database running on-premises or an Azure SQL database. It contains company data from the base application and any supported extension tables. During migration, this database is treated only as a data source. Business Central application logic does not run here.
Azure Data Factory (ADF)
Azure Data Factory is the service that moves the data. It reads data directly from SQL tables and writes it into the Azure SQL database used by Business Central online. ADF does not understand Business Central. It does not evaluate users, roles, permissions, or business rules. It only requires SQL access.
Pipelines
Pipelines are configurations inside Azure Data Factory that define:
Which tables are copied
The order in which tables are processed
How large tables are grouped
How failures are logged
Data is copied table by table. If a table fails because it is missing or the schema does not match, the failure is recorded and the migration continues with the next table.
Integration Runtime
The Integration Runtime is the secure connection between your source database and Azure Data Factory.
If your source is SQL Server on-premises, you install a Self-Hosted Integration Runtime inside your network.
If your source is Azure SQL, an Azure-managed Integration Runtime is used.
The runtime handles encrypted communication. You do not need to expose your database to the internet or open inbound firewall ports.
Online database
This is the Azure SQL database behind your Business Central online environment. All replicated data is written here first. If required, a data upgrade is run afterward to align the data with the SaaS application version.
What Data Is Migrated (and What Is Not)
One of the most common questions we hear is, “What exactly moves to the cloud and what doesn’t?” The short answer is this: Business Central migrates your business data, not your system setup.
The on-premises to online migration uses Azure Data Factory (ADF) to copy data directly at the database level. It works table by table, which is important, because it means each piece of data is moved independently, tracked individually, and doesn’t block the rest of the migration if something goes wrong.
What Actually Gets Migrated?
The focus of the migration is on the data that keeps your business running day to day.
This includes all company-specific tables from the base application. So your customers, vendors, items, chart of accounts, open transactions, and historical financial data all move to the online environment.
If you’re using custom extensions or ISV solutions, their data can also be migrated, as long as the table structures in your on-prem database match what Business Central online expects. When schemas line up, the data moves cleanly. When they don’t, those tables are skipped and logged.
You can also migrate multiple companies, as long as you explicitly select them during setup. Behind the scenes, every table for every company is migrated independently, with success or failure logged so you can review and fix issues without restarting everything.
What Does Not Move to SaaS
Some things are intentionally left behind, and this is by design, not a limitation.
Most system tables don’t migrate because Business Central online manages global and tenant-level settings differently than on-premises.
Users, roles, and permissions also don’t move. In SaaS, identity and access are handled through Microsoft Entra ID, so these are expected to be recreated in the cloud rather than copied from the old environment.
You’ll also notice that record links and some attachments may be missing after migration. These are often tied to user IDs or older schemas that don’t exist in the SaaS tenant. Similarly, extension data may not migrate if versions or table definitions don’t align.
What This Means After Migration
This is where expectations matter.
After the data migration, you should assume that business data is in place, but environment setup is not. You’ll need to recreate users and permissions, run the required data upgrade if you’re moving across versions, and validate that key financial and operational data looks right.
A bit of cleanup before migration goes a long way here. Cleaning up old data and making sure extensions are aligned significantly reduces skipped tables and post-migration surprises.
If you go in expecting SaaS to be a fresh, clean environment with your business data brought forward, the process makes a lot more sense and runs much smoother.
