The best upgrade options for Business Central 2025

2025 is not a year for half measures. Since v26 (2025 Wave 1), there is a clear, step-by-step path for many scenarios: For cloud migration, your on-prem solution must be upgraded to at least v25; in addition, v26 is a stepping-stone release, i.e. direct jumps across several major versions are restricted. This has a noticeable impact on budget, downtime and tool selection.

You have these options when upgrading.

1) Greenfield / “Green meadow”

Only important master data (debtors, creditors, articles, open balances if applicable) plus new processes/customizing in Business Central.

Advantages: Lean, fast, less legacy.

Disadvantages: History remains in the old system/archive; additional effort for reporting across old and new systems.

2) Complete data transfer

Full history (master data and transaction data) moves to Business Central.

Advantages: One system, complete information capability.

Disadvantages: Technically more complex, higher data volume and therefore typically longer switching windows, more tests.

The options at a glance

Note: Why “one-way street” for the standard path? During the Microsoft data upgrade, all clients are disconnected; after a successful data upgrade, replication from the old version is not permitted (risk of data corruption). This is for technical reasons and applies regardless of which service provider performs the upgrade.

Strengths & weaknesses in detail

Configuration packages (formerly “RapidStart”)

Pro:

• On board, cost-effective, fast for master data (customers, suppliers, articles, G/L basic configuration).
• Since 2024/25: BLOB/multi-line text can be processed via package (Base64).

Contra:

• Not intended for existing productive companies; large imports may block use – for bulk imports XMLports.
• No live sync, no history conversion (import only), testing/troubleshooting often manual.
• No item transfer or posted / unposted documents (e.g. invoices) possible
• Very slow with large amounts of data
• Configuration packages must be imported in the correct order, otherwise there will be validation errors (for links between tables)

Conclusion: Ideal for “greenfield sites”. Unsuitable or time-consuming and slow for complete data transfer (incl. posted items and receipts).

DataMigrate Pro(IO Integrated)

Pro:

• Direct migration from very old Navision/NAV versions without “jump versions”
• Bidirectional live synchronization (NAV↔BC), delta loads, parallel operation – resulting in minimal / no downtime and predictable cutover.
• Cloud or on-prem target; suitable for greenfield (subset) and complete takeover.

Contra:

• Extensive features that mainly work via a command line tool. May require brief instruction in use.

Conclusion: Technically attractive if downtime is to be minimized and the entire legacy history is to be transferred.

Service provider on Microsoft standard path

Pro:

• Use of the standard upgrade path

Contra:

• Cutover downtime is inherent in the system: all connections are disconnected when data is upgraded; replication is no longer permitted afterwards – a one-way street.
• For BC Online / SaaS, the OnPrem system must have at least v25 -> additional intermediate steps may be required.
• Most expensive solution (usually between EUR 50,000 and 150,000)

Conclusion: If a long downtime and high costs are not a problem, then this is an acceptable solution.

Specifics that you should not ignore

• Cloud migration only from v25 – An update to v25 is required before moving to the cloud; v26 acts as a stepping-stone release.
• Data upgrade = maintenance window – regardless of the service provider, clients are disconnected until the step is completed; no provision is made for jumps back with renewed replication. A classic one-way street. This is no longer up to date!
• Configuration packages are not mass ETL – For productive mass imports, Microsoft advises against packages (performance risk) and instead refers to XML ports.

Decision matrix (short and sweet)

Risks & pitfalls that hurt

• Downtime underestimated: With the standard upgrade, the data upgrade step is hard; if you have to plan to the minute, you need clean pre-tests or choose Livesync.
• Data quality: Duplicates, incorrect number ranges, incorrect dimensions explode in the new system. Plan data cleansing at an early stage.
• Add-ons/customizing: C/AL adaptations must be transferred cleanly to AL/extensions; the effort involved depends on the legacy scope.
• Configuration packages overrated: Good for master data – not as history-capable ETL or for ongoing production.

Checklist: How to make the right decision (in 30 minutes)

• Does BC have to be online? If yes and you are < v25, calculate intermediate step v25 (the older the source version, the more intermediate steps are necessary) or check direct migration/live sync.
• How much history do you need in BC? Master data only -> RapidStart; full history -> DataMigrate Pro or standard upgrade with go-live window and long downtimes.
• Downtime tolerance: zero / hardly any tolerance -> live sync; weekend cutover and high costs ok -> standard upgrade.
• NAV version very old? Direct migration without jump versions saves time/complexity.
• Budget/responsibility model: technically driven & migration-focused -> DataMigrate Pro.

See also the official documentation from Microsoft.

Conclusion

• Greenfield: Setting up new configuration packages for master data and processes. Fast, cost-effective – but not for mass imports in live operation.
• Complete data transfer: If downtime is critical and costs need to be kept low or the source version is very old: DataMigrate Pro (parallel operation, live sync).
• Classic cutover window acceptable and fixed price/standard important: Business Central Partner (like IO Integrated) – accept that data upgrade is a one-way street and costs can escalate.