Historical Data in Business Central: How Much to Migrate

MYTH

“Business Central can only handle two years of history.”

REALITY

Business Central doesn’t have a hard technical limit that restricts you to two years of historical data. Many organizations successfully operate with 5–10+ years of history without noticeable performance issues.

Where performance and complexity tend to show up is not the existence of history—but how the history is migrated and used, especially when very large datasets are loaded into a new system all at once.

Why migrating “everything” isn’t always the best idea

Even if you can migrate a large amount of history, it may not be the most cost-effective or operationally clean approach. Common challenges include:

• Longer migration timelines and higher project cost

• Higher risk during cutover, especially with large bulk loads

• Increased data cleanup and mapping effort, particularly if older data quality is inconsistent

• Slower reporting and user experience if detailed history becomes unnecessarily heavy

• Duplicating historical detail in multiple places (GP + BC + reporting), which can create confusion

Our practical recommendation

For most GP → Business Central migrations, a common best practice is to migrate:

This approach usually strikes the best balance between:

When migrating more than two years makes sense

There are situations where migrating more history into Business Central is the right decision, including:

Regulatory or audit requirements that require full transactional detail inside the ERP

Heavy operational dependence on legacy transactions (returns, warranty, long-cycle projects)

Users need to transact or investigate deeply in-system, not just report from another tool

Limited appetite for maintaining a legacy access method (even read-only)

If you fall into one of these categories, we can plan a migration strategy that scales—while protecting performance and minimizing risk.