The Microsoft Dynamics 365 Business Central cloud migration tooling works with SQL-based source systems in general, not only the paths it already supported. It has been generally available since April 1, 2026, as part of 2026 release wave 1. Before this, that tooling covered migrations from Business Central, Dynamics GP, and Dynamics SL. It now adds a system-level migration module and a Generic Custom migration type inside the Cloud Migration wizard, so developers can build data migration engines for other SQL-based systems, package them as extensions, and reuse them across projects through Marketplace.
If you are running a legacy on-premises ERP or a line-of-business system that sits on SQL Server and you have been weighing a move to Business Central, this is the part of the project that has usually been hand-built. It affects the cost and risk shape of that move more than the day-to-day experience of anyone already in Business Central.
What this changes about a legacy migration
Moving off a SQL-based system that Microsoft has no first-party path for has meant custom scripts: someone writes extraction and mapping logic, runs it, finds the gaps, runs it again, and the knowledge lives in that person's head and a folder of files. It works, but every migration starts closer to zero than it should, and the admin experience differs from project to project.
The alternative is building the migration engine once as an extension, then installing and reusing it, with the same wizard and the same admin experience as the supported migration types. Microsoft's stated goals for it are repeatability, fewer custom scripts, and lower risk.
The release plan does not spell out licensing requirements, which specific source systems have published engines, how much developer effort a given engine takes, or how existing custom scripts might be reused. Those details are not stated, so we would not plan around assumptions about them.
What to look at now
Nothing here is urgent on its own. It does change what is worth doing early if a platform move is anywhere on your two-year horizon.
- Get clear on what has to come across: open balances and master data, or transaction history too, and how many years of it. This drives migration scope regardless of the tooling.
- Confirm whether your current system's data really sits in SQL and whether you or your software partner can get read access to it. The tooling is specific about SQL-based sources.
- Note how much of your data lives outside the ERP in spreadsheets and side databases. That work does not get easier because the ERP migration path did.
- Write down the reports and reconciliations you would use to prove a migration landed correctly. Repeatable tooling is worth more when you can test each run quickly.
How we would think about timing
If you have a business reason to move now, this is one fewer unknown in the scoping conversation rather than a reason to wait for anything. The useful question during scoping is whether a Generic Custom engine already exists for your source system, or whether building one is cheaper than the scripts you would otherwise write.
The other thing worth checking is whether engines exist for the systems common in your industry. Reuse only pays off when someone has already built for your source, so that is a question to ask your partner directly rather than assume either way.
If a platform move is on your list
Most of the value in a migration comes from decisions made before anyone touches data: what history you keep, which processes you rebuild rather than reproduce, and who owns the sign-off. Tooling that lowers the cost of the mechanical part makes those decisions more, not less, worth your time.
If you are mapping out a move off a legacy SQL-based system and want a second read on scope and sequence, we're happy to talk it through whenever it's useful.