Migrate to Business Central Cloud from Any SQL Database: What the New Tooling Actually Changes

For years, the Business Central cloud migration tool has quietly handled three specific sources: Business Central on-premises, Dynamics GP, and Dynamics SL. If you ran anything else — a legacy SQL-based ERP, a home-grown system, an industry package nobody’s heard of — the “official” tooling didn’t reach you. You paid a partner to write scripts, or you did a re-implementation from scratch.

That changed in 2026 release wave 1. Microsoft shipped a feature called “Migrate to the cloud from any SQL database” (public preview March 2026, general availability April 2026). It extends the cloud migration platform so partners can build their own migration engines for any SQL-based source system — packaged as AL extensions, installed through AppSource, and reused across customers.

This article is the honest breakdown: what the feature actually does, what it doesn’t do, how it compares to the classic migration path, and what it means for your budget and timeline.

What Actually Shipped (And What It Means)

Let’s be precise, because the marketing name over-promises slightly. “Any SQL database” does not mean you point the wizard at any random SQL Server and Business Central auto-maps everything for you. What it means is narrower, and more useful.

The New Building Blocks

Microsoft added three things to the existing cloud migration platform:

1. A generic, system-level migration module that plugs into the Cloud Migration wizard as a new “Generic Custom” migration type.
2. A standardised AL interface that defines how data is mapped, replicated, and transformed from an external SQL source into Business Central.
3. Shared helper methods — mapping helpers, replication and transformation orchestration, and a generic UI for tracking migration progress and errors.

The migration engines themselves are AL extensions. A developer implements the interface, packages the result, and ships it through AppSource. Once installed, a custom engine behaves exactly like Microsoft’s built-in engines: it runs through the same wizard, surfaces status and failures in the same generic UI, and gets the same admin experience.

The Key Insight

The real headline isn’t “migrate from anything.” It’s “partners can now build a migration product once and sell it many times.”

Before this feature, every legacy-SQL-to-BC migration was a custom engagement: bespoke scripts, one-off mapping code, ad-hoc tooling, and a lot of risk that couldn’t be amortised. Now an ISV can build a migration engine for, say, a specific legacy Romanian ERP or an industry vertical package, validate it once, and deploy it across dozens of customers.

That’s why Microsoft frames the benefit the way it does: “building migration solutions once and deploying them across multiple customers, eliminating custom scripts, reducing risks, and ensuring a consistent admin experience.”

Classic Cloud Migration vs. The New Generic Tooling

If you’re already on Business Central on-prem, GP, or SL, you don’t need this feature — the classic path already covers you. Here’s how the two compare.

The classic path is still the right answer for the vast majority of on-premises-to-cloud moves, because the built-in engines are mature and free of per-customer engineering. The new tooling is for the long tail: the bespoke system, the discontinued vertical package, the in-house SQL database that’s been running your business for 15 years.

What Still Applies (The Shared Foundation)

Both paths run on the same underlying machinery, and the prerequisites don’t change. Understanding these will save you a nasty surprise later.

Source Database Requirements

The source database must be on SQL Server 2016 SP1 or later (or Azure SQL), with:

• Compatibility level 130 or higher
• TCP/IP enabled
• SQL Server authentication configured (the login needs sysadmin at server level and db_owner on the database)
• Change tracking enabled at the database level (retention 2+ days for incremental replication)

For on-premises SQL, you’ll also install a self-hosted integration runtime (SHIR) — a local agent that pipes data to Azure Data Factory without opening inbound firewall ports.

The Five-Phase Flow

Whether you’re on the classic or generic path, the migration follows the same shape:

1. Preparation — plan, verify prerequisites, clean and align your data.
2. Cloud migration setup — establish the connection and pipeline (no data moves yet).
3. Data replication — copy data from source to online tenant (re-runnable, incremental).
4. Data upgrade — upgrade platform data if the source version predates the target.
5. Completion — reconfigure integrations, validate, and cut over.

The generic tooling slots into this same flow; it changes how the mapping is built, not the operational mechanics underneath.

Who This Is Really For

The feature is technically “enabled for admins, makers, marketers, or analysts, automatically” — but let’s be honest about who benefits.

The end customer (you, the business moving off a legacy SQL system) benefits indirectly: you get a productised migration instead of a bespoke one, which is typically cheaper, faster, and lower-risk.

The partner/ISV benefits directly: they can build a reusable engine and sell it through AppSource, turning every migration from a custom project into a repeatable product.

The developer benefits because the standardised AL interface plus shared helpers means less raw plumbing code — no reinventing replication orchestration, mapping, or progress tracking for every engagement.

If you’re a business and Microsoft already supports your source system natively, you won’t think about this feature at all. If you’re on something Microsoft doesn’t support, the question becomes: has a partner built an engine for your specific legacy system yet? In 2026 the answer for niche systems is often “not yet” — which is why the feature is best understood as unlocking a market rather than shipping every engine at once.

Honest Pricing: What a Migration Like This Costs

Pricing for a SQL-to-BC migration breaks into three buckets, and the new tooling mostly moves costs between them rather than eliminating them.

The honest way to read this table: the new tooling doesn’t make the first migration of a given legacy system dramatically cheaper — building a good engine still takes real engineering. What it does is make the second, third, and twentieth migration dramatically cheaper, because the engine is already built and validated.

That’s the asymmetry to understand when a partner quotes you. If you’re the first customer for a given legacy system, you’re partly funding the engine build. If you’re the tenth, you’re paying for configuration and data work, and the price should reflect that.

Licensing note: the migration platform itself requires no additional Business Central license. You pay for the partner’s work and, if an ISV engine is involved, the AppSource extension’s subscription fee (typically a few hundred to a few thousand euros depending on the vendor).

Team & Roles

A migration that moves money-relevant data needs named owners, not a committee.

The single biggest success factor is the source-system expert. The legacy SQL database you’re leaving has two decades of undocumented quirks — a “Customer” table that actually holds prospects, a “status” field where 3 means four different things depending on another field. If the person who knows those quirks has left the company, budget extra discovery time. This is where migration projects quietly double in scope.

Phase by Phase: What the Project Actually Looks Like

Phase 1 — Assessment & Data Audit (Weeks 1–2)

• Inventory the source schema: tables, relationships, and data volumes.
• Profile data quality: duplicates, orphans, invalid codes, date ranges.
• Decide scope: full history vs. open transactions + summary balances.
• Deliverable: a mapping document and a go/no-go on the approach.

Your role: provide schema access and the source-system expert. What we handle: the technical audit and the mapping plan.

Phase 2 — Engine Selection or Build (Weeks 2–6, in parallel)

• If an AppSource engine exists for your system: install, configure, and validate it.
• If not: build a custom AL migration engine using the new generic tooling.
• Deliverable: a working, tested migration engine or configured engine.

Your role: confirm business rules and field mappings. What we handle: all AL development and the shared-helper plumbing.

Phase 3 — Replication & Reconciliation (Weeks 3–8)

• Run initial full replication into a sandbox.
• Reconcile counts and totals against the source, table by table.
• Run incremental replications and fix mapping gaps.
• Deliverable: a sandbox that balances against your source data.

Your role: validate the numbers. What we handle: the replication runs and reconciliation tooling.

Phase 4 — Data Upgrade & Completion (Weeks 6–10)

• Upgrade platform data if the source version predates the target.
• Reconnect integrations (APIs, Power Platform, EDI, reporting).
• Train users, run UAT, and plan the cutover weekend.
• Deliverable: a production-ready environment.

Phase 5 — Cutover & Stabilise (Final 1–2 weeks)

• Freeze the legacy system, final incremental replication, go live.
• Monitor telemetry closely for the first two weeks.
• Deliverable: decommissioned legacy system, stable new environment.

What Nobody Tells You

Four things the release notes don’t mention.

1. “Any SQL database” still means “a SQL database someone understands.” The tooling removes the plumbing problem, not the knowledge problem. If nobody in your organisation can explain what the legacy tables actually mean, the migration stalls regardless of how good the engine is. Protect the source-system expert’s time like it’s the scarcest resource in the project — because it is.

2. The first migration funds the engine. If you’re early in the adoption curve for your specific legacy system, part of your fee is building the reusable engine your partner will use for their next ten clients. That’s not unfair — but you should understand it, and negotiate accordingly (some partners offer first-customer discounts in exchange for being a reference).

3. Data quality is discovered, not assumed. Every migration we run finds the same class of surprises: duplicated customers, orphaned order lines, negative inventory balances, and “status” codes that mean different things by context. Budget 15–20% of the total timeline for cleaning what you find. The tooling moves data faithfully; it does not fix data that was broken to begin with.

4. Replication is the easy part; reconciliation is the work. Copying rows is fast and reliable. Making sure the totals balance — that your GL matches, that open AR/AP reconcile, that inventory valuation ties out — is where the real hours go. Anyone who quotes you a migration timeline based on “how long replication takes” is quoting the wrong number.

Is It Better Than a Re-Implementation?

A separate 2026 feature — “Run reimplementation projects using cloud migration tool” (GA May 2026) — lets you migrate only essential master and transactional data from older Business Central versions, deliberately leaving obsolete customisations behind. It’s the “fresh start” option.

So you have three doors when leaving a legacy SQL system:

1. Full migration — bring most of your data and history forward. Best when you want continuity.
2. Re-implementation — bring only core masters, opening balances, and selected transactions. Best when your legacy customisations are a liability you want to shed.
3. Clean-slate implementation — start over entirely. Best when the old system’s data is beyond saving and processes need redesign anyway.

The new generic SQL tooling makes door 1 realistic for far more systems than before. But it doesn’t make door 1 always the right choice. If your legacy system’s data model is a mess and its processes are obsolete, migrating that mess faithfully is just preserving the problem in a newer home.

Checklist

Copy this. Work it top to bottom.

• Confirm your source database is on SQL Server 2016 SP1+ (compat level 130+) or Azure SQL
• Verify TCP/IP is enabled and SQL Server authentication is configured
• Enable change tracking at the database level (retention 2+ days)
• Identify your source-system expert and protect their time
• Decide scope: full history vs. open transactions + summary balances
• Check whether an AppSource migration engine already exists for your system
• If not, scope a custom AL migration engine via the new generic tooling
• Profile data quality: duplicates, orphans, invalid codes, negative balances
• Budget 15–20% extra timeline for data cleanup
• Map every source table to its Business Central target
• Run initial replication into a sandbox
• Reconcile counts and totals against the source, table by table
• Reconnect integrations: APIs, Power Platform, EDI, reporting
• Run UAT with real users on real scenarios
• Plan the cutover weekend (freeze source, final incremental, go live)
• Monitor telemetry closely for the first two weeks post-go-live
• Decommission the legacy system only after stabilisation

FAQ

What does “migrate to the cloud from any SQL database” actually mean?

It means Microsoft extended the Business Central cloud migration platform so partners and ISVs can build their own migration engines for any SQL-based source system — not just Business Central on-prem, Dynamics GP, and SL. These engines are written as AL extensions, packaged and installed through AppSource, and run through the same Cloud Migration wizard and generic UI as Microsoft’s built-in engines. It does not mean the wizard auto-maps any arbitrary database with zero effort.

When did this feature ship?

It entered public preview in March 2026 and reached general availability in April 2026, as part of Business Central 2026 release wave 1 (version 28). It’s enabled automatically for admins, makers, marketers, and analysts.

Do I need this if I’m already on Business Central on-premises?

No. If you’re on Business Central on-premises (version 25 or later), Dynamics GP 2015+, or Dynamics SL 2015+, the classic built-in migration engines already cover you — and they’re mature and free of per-customer engineering. The new generic tooling is for legacy or industry SQL systems that Microsoft doesn’t natively support.

What are the source database prerequisites?

The source must be on SQL Server 2016 SP1 or later (or Azure SQL), with compatibility level 130 or higher, TCP/IP enabled, and SQL Server authentication configured — the login needs sysadmin at server level and db_owner on the database. Change tracking must be enabled at the database level for incremental replication, and on-premises sources need a self-hosted integration runtime.

Is this cheaper than the classic migration path?

Not for the first customer of a given legacy system — building a good custom engine still takes real engineering (roughly €20,000–€50,000). The savings come on the second, third, and subsequent migrations, because the engine is already built and validated. If an AppSource engine already exists for your system, expect €10,000–€22,000 for a standard migration.

How does this compare to a re-implementation?

A full migration brings most of your data and history forward for continuity. A re-implementation (GA May 2026) migrates only essential master and transactional data, deliberately leaving obsolete customisations behind — the “fresh start” option. A clean-slate implementation starts over entirely. The right choice depends on whether your legacy data and processes are worth preserving.

Can we migrate our custom fields and extensions?

Yes, with conditions. Any customisation must be packaged as an extension and installed on both the source (where applicable) and the online tenant. Custom fields require explicit table mappings to move. The new generic tooling lets partners define those mappings in the AL engine, but someone still has to specify them — it’s not automatic.

How long does a SQL-to-Business Central migration take?

A standard migration using an existing engine typically runs 6–10 weeks. If a custom engine must be built for your legacy system, plan for 2–4 months. The biggest variables are data quality (budget 15–20% extra for cleanup) and the availability of someone who understands the legacy data model.

Leaving a legacy SQL system for Business Central online? Book a scoping call → We’ll audit your source data, tell you honestly whether a migration or re-implementation is the right path, and build or configure the engine to get you there — without the ad-hoc scripts. Or explore our data migration and custom development services.