Data migration in Business Central is the phase that determines whether the go-live is a success or the beginning of months of costly corrections. The system may be perfectly configured, users trained, and the budget approved — but if the data arrives dirty, incomplete, or poorly mapped, everything else fails. Data errors are not discovered at the moment of loading: they are discovered three weeks later, when finance cannot close the month.
This guide is a concrete playbook for implementation teams and CTOs who need to guarantee data integrity during migration to BC — without extending the timeline or improvising at cutover.
Why data migration is the real bottleneck in BC
Financial data migration remains trapped in a world of exports, spreadsheets, manual cleaning, and endless reconciliation loops — and when something goes wrong, it is never minor. It is not an abstract technical problem: it is a trial balance that does not reconcile, incorrect vendor balances, or lost customer history.
The most common failures in Business Central migrations repeat in a predictable pattern: general ledger reconciliation errors on go-live day, custom code that breaks in the cloud, integrations that stop passing data, and users reverting to spreadsheets. They all have a root cause: some step that was rushed or skipped.
Although it is tempting to view migration as a “lift and shift” operation, successful migrations require rigorous planning, systematic cleaning, and meticulous execution. A poorly executed migration can paralyze an excellent implementation, while a well-executed one lays the foundation for a solid go-live.
Migration from legacy systems common in LATAM: NAV, GP, Sage 100, and local systems
In LATAM, most migrations to Business Central do not start from scratch: they start from Dynamics NAV, Dynamics GP, Sage 100, or local systems such as Aspel, Defontana, or Siigo. Each source has known incompatibilities with BC’s structure that should be anticipated before opening the first mapping spreadsheet.
Migrating from NAV is technically the shortest path — they share a Microsoft lineage — but the difference between the NAV 2016 data model and BC 2025 is greater than it appears: the chart of accounts, dimensions, and manufacturing modules require explicit mapping decisions. GP and Sage 100, on the other hand, have flatter data structures than BC, which creates problems when representing relationships between entities.
| Source system | Common incompatibility | Recommended mapping decision |
|---|---|---|
| Dynamics NAV | Non-standard dimensions, chart of accounts with proprietary segments | Redesign dimensions in BC before migrating; do not import the NAV structure directly |
| Dynamics GP | Account structure with multiple segments; transaction history in proprietary format | Consolidate segments into BC dimensions; migrate history only up to 2 years back |
| Sage 100 | Inventory fields with no direct equivalent in BC (alternate units of measure, lots) | Map to BC base units and configure conversions; validate with warehouse before cutover |
| Aspel / Siigo / Defontana | Local tax structure (CFDI, electronic invoice) with no native equivalent in standard BC | Use certified localization extensions; do not migrate closed tax documents, only balances |
A pattern that the KCP Dynamics team frequently observes in regional projects: the greatest risk is not in the migration tool, but in assuming that the mapping is obvious because the systems share similar terminology (both have “customers,” “invoices,” “general ledger”). The semantics are similar; the underlying structure is not.
Data audit and classification: before touching anything
The first step is not to migrate — it is to understand what you have. Start with a data audit to understand the quality and volume of what exists. Classify data according to what is needed at go-live, what is required for regulatory compliance, and what can be archived.
The main categories are: master data (customers, vendors, products), transactional data (open invoices, purchase orders, stock levels), historical data (transactions from prior periods for reporting), and configuration data (chart of accounts, payment terms, tax codes). Each category has a different risk profile and distinct cleaning requirements.
A successful migration is not about moving all the data. It is about moving the right data, correctly structured, validated, and ready to support the business from day one.
What to migrate and what to archive
Master data — customers, vendors, and items — must always be migrated. Open transactions are necessary for operational continuity. Historical data is typically limited to a defined reporting period. Archived data is retained externally where appropriate. This selective approach reduces complexity, improves performance, and simplifies reporting from day one.
Data migration typically takes between 4 and 8 weeks from initial planning to final cutover, depending on data volume and quality. The majority of that time is spent on cleaning and validation, not on the technical transfer itself.
Data cleaning: the work nobody wants to do and that decides everything
Data cleaning is the most underestimated phase — and the one with the greatest impact on the outcome. Poor data quality — duplicates, missing records, or inconsistencies — can cause migrations to fail. The principle is brutal and simple: garbage in, garbage out.
The four cleaning operations you cannot skip
- Deduplication: use SQL queries or third-party tools to identify and merge duplicates, such as duplicate records for the same customer.
- Completeness verification: check that critical fields — invoice amounts, vendor addresses — contain data.
- Standardization: apply consistent formats across all fields, such as phone numbers, country codes, or date formats.
- Archiving: move obsolete data — transactions older than seven years, for example — to a separate archive to simplify migration complexity.
A CFO or controller who understands what the data should look like needs to be involved in reviewing and approving the clean data before it is loaded. IT can move data, but only the business can confirm what is correct.
Mapping documentation: the step that is always forgotten
Data mapping is the process of defining how fields from the legacy system translate into Business Central. Some of this is straightforward; some requires decisions about how the new system is structured. Common decisions include how the chart of accounts maps to BC’s structure, how products and prices are represented, and how customer and vendor master data is normalized.
Poor mapping documentation is one of the most reliable sources of post-go-live problems, because nobody remembers why a specific decision was made when it surfaces as an issue three months later. Document every mapping decision with its rationale — not just the “what,” but the “why.”
Migration tools in Business Central: which to use, when, and what risks each carries
The choice of tool is not trivial — it depends on data volume, the complexity of the source system, and the available budget. But beyond “when to use each one,” what the technical team needs to know are the concrete risks of each option.
| Tool | Volume | Best for | Main risk |
|---|---|---|---|
| Configuration Packages (RapidStart) | Low (<50K records) | Simple master data, standard migrations | Does not manage relationships between tables: if a parent record fails, child records are loaded without a valid reference. Requires manual referential integrity validation. |
| Azure Data Factory + custom AL | High (>100K records) | Complex legacy systems, advanced transformations | High initial development cost and dependency on certified AL resources. Without pipeline documentation, post-go-live maintenance is costly. |
| Power Automate + Power Apps | Medium | Microsoft 365 ecosystems, validation with business users | BC API throttling limits can cause silent failures in bulk loads. Always monitor execution logs. |
| Talend / Informatica | Enterprise | Regulated environments (finance, manufacturing), strict governance | Significant licensing cost (Informatica can exceed $30,000 USD/year). Justified only in projects with regulated critical data or volumes exceeding 500K records. |
Companies that combine native tools with the Power Platform reduce migration time by up to 25% compared to manual processes. Automation is not a luxury — it is what makes the timeline predictable.
Migration team: profiles and actual dedication
A question that the CTO and CFO always ask before approving the project: how many people do we need and for how long? The honest answer is that a mid-sized Business Central migration requires at least five active profiles, with very different levels of dedication depending on the phase.
- Data architect / BC consultant (high dedication, 60-80% during preparation and validation): defines the data model, oversees mapping, and validates technical integrity. This is the hardest profile to replace if it fails.
- Business functional analyst (medium dedication, 40-60%): translates business requirements into mapping rules. Without this profile, IT makes business decisions that are not its responsibility.
- Controller or CFO (low but critical dedication, 10-20% with peaks during validation): signs off on clean data and GL/AR/AP reconciliation. Their sign-off is the only go/no-go criterion that matters in finance.
- AL developer / integration technician (variable dedication, high at cutover): executes loads, manages technical errors, and maintains the migration pipeline.
- Project manager (PMO) (constant dedication, 30-50%): coordinates timelines, manages dependencies, and escalates blockers. In projects without a dedicated PMO, delays multiply.
In LATAM projects with complex source systems (NAV or GP with customizations), the KCP Dynamics team estimates between 800 and 1,400 total work hours for a complete migration of master data and open transactions in a mid-sized company (50-200 users). 60% of those hours are concentrated in cleaning, mapping, and validation — not in the technical load.
Post-go-live validation: the four-layer protocol
Post-go-live validation is not a superficial review. It is a structured process that must be completed before declaring the go-live successful. The moment data lands in the target system, a new question opens: are they really correct? Not structurally correct — correct in value, in record, in business logic.
After completing the migration, run reconciliation in layers: layer 1 — record count verification across all tables immediately after migration; layer 2 — checksum comparison across all flagged tables; layer 3 — field-level reconciliation in critical business domains; layer 4 — business rule validation across all transactional data.
Financial reconciliation: zero tolerance in GL, AR, and AP
Do not proceed to UAT until every general ledger balance, every accounts receivable aging figure, and every accounts payable total matches the source system. This is the most important go/no-go criterion of the entire migration.
Establish acceptable variance thresholds by data domain — 0% tolerance for financial records without exception. In LATAM, where tax compliance requirements are strict (SAT in Mexico, DIAN in Colombia, SII in Chile), any discrepancy in the general ledger can lead to audit issues that go far beyond the ERP project.
Referential integrity validation
Confirm that foreign key relationships survived the migration. Every order record must have a corresponding customer record. Broken referential integrity does not appear immediately — it appears when a user generates a report that joins tables, or when a transaction references a parent record that did not migrate correctly.
Post-migration validation techniques that omit business rule validation approve data that is structurally correct but operationally incorrect. This is especially critical in manufacturing and distribution modules, where incorrect BOMs or poorly migrated stock levels generate immediate operational problems.
Parallel reconciliation: how to run it without duplicating effort
Parallel reconciliation — running the legacy system and BC simultaneously for a period — is the most robust way to validate that data is correct. A structured validation process involves running parallel reports in the legacy system and in Business Central, comparing key figures such as debtor balances, creditor balances, and stock valuations, and having the finance team sign off that the numbers are correct before making the switch.
A more controlled strategy consists of moving the oldest historical data at the start of the project, validating and reconciling as you progress, and leaving only the most recent open periods for the final cutover. This dramatically reduces the “big bang” risk at go-live.
The most effective implementation teams run three migration cycles: an initial load to identify structural issues, a validated load with full reconciliation, and a dress rehearsal that exactly replicates the go-live.
The cutover: an hour-by-hour protocol to avoid improvising
The cutover is the highest-risk moment. Every hour without a plan is an hour of exposure. The activities of the cutover weekend follow a clear sequence: hours 0-2, system freeze and final extraction; hours 2-6, import of master data, open transactions, and opening balances; hours 6-10, record count verification, key balance validation, and reconciliation with the legacy system; hours 10-12, final smoke tests, user notification, and enabling production access.
The most common question on go-live day is: can we trust these numbers? The answer depends entirely on how thoroughly the previous phases were executed. If the data was cleaned correctly, the mapping decisions were documented, and the validation was completed by the right people, the answer should be yes.
Rollback management: when to activate the fallback plan
A serious Business Central data migration playbook always includes an explicit rollback plan — not as a sign of pessimism, but as a decision criterion that the team must be able to activate without improvising under pressure.
Rollback activation criteria
The rollback must be activated if any of the following conditions are met during the cutover window: record counts differ by more than 1% from the source system without an identified cause; GL reconciliation shows discrepancies that cannot be resolved in less than two hours; critical modules (invoicing, payments) do not pass smoke tests within the planned time; or the legacy system cannot be cleanly frozen and there are in-flight transactions without traceability.
The rollback decision window is narrow: in most projects, there is a window of between 4 and 6 hours from the start of the cutover to decide whether to continue or revert. Past that window, the cost of going back exceeds the cost of moving forward and resolving issues in production.
How to preserve legacy system integrity until go-live is confirmed
For the rollback to be viable, the legacy system must remain in a frozen and operational state throughout the entire cutover window. This means: do not deactivate licenses or access until the finance team has signed off on the reconciliation; retain a full backup of the legacy system with the date and time of the freeze point; and document the exact state of open transactions at the time of the final extraction. If the rollback is activated, the legacy system must be able to resume operations in less than 30 minutes without data loss.
Real case: migration in LATAM with KCP Dynamics
To illustrate how this playbook is applied in practice, the KCP Dynamics team documents here the parameters of a representative regional project: a mid-sized manufacturing company in Mexico, migrating from Dynamics NAV 2016 to Business Central with finance, purchasing, sales, and inventory modules.
- Volume migrated: 87,000 records between master data and open transactions; 24 months of financial history for reporting.
- Actual data migration duration: 6 weeks from initial audit to cutover (within the typical 4-8 week range).
- Discrepancies detected during validation: 312 customer records with incomplete or incorrectly formatted RFC fields; 4 chart of accounts entries with no direct equivalent in BC that required an explicit decision from the CFO.
- GL reconciliation result: difference of MXN 0.00 at the close of the first month post-go-live. The finance team signed off on the go-live without reservations.
- Post-go-live incidents in the first 4 weeks: 7 vendor records with incorrectly mapped payment terms, corrected within the first 48 hours with full traceability in the audit trail.
The key to the outcome was not the tool — a combination of RapidStart for master data and Azure Data Factory for historical transactions was used — but rather the controller’s involvement from the cleaning phase, which made it possible to detect the RFC issues before loading, not after.
Post-go-live errors: how to detect and correct them without halting operations
The work does not end at go-live. Post-migration efforts are essential to optimize Business Central performance, resolve issues, and preserve data integrity. What was not detected during testing will appear in production — the key is to have a response protocol, not to improvise.
Active monitoring in the first four weeks
Log post-migration errors — such as unposted transactions — using Business Central’s audit logs. Correct discrepancies quickly: import missing records or fix incorrect mappings. Every unresolved discrepancy becomes technical debt that grows with each closing cycle.
Correcting the target record without identifying which step in the pipeline produced the error means the same error will appear in the next migration batch. Always trace the root cause before applying the correction — do not just patch the symptom.
Post-go-live data governance in LATAM
In LATAM markets, post-migration data governance has an additional dimension: regulatory compliance. Establish clear data governance policies to maintain quality over time. Use automated tools for continuous data validation and cleaning to ensure sustained accuracy.
Teams like those at KCP Dynamics, with experience in BC implementations across LATAM, apply this governance approach from the design stage: not as an additional layer at the end of the project, but as part of the data model from the outset. Data quality is not a one-time project — it is an ongoing process that determines whether the ERP remains reliable at 12 and 24 months post-go-live.
Business Central data migration checklist
This is the actionable summary of the playbook. Use it as a go/no-go criterion at each phase of the project. Items marked as [Critical] are blockers: do not advance to the next phase without completing them. Items marked as [Recommended] reduce risk but do not block progress.
Preparation phase
- [Critical] Complete audit of data sources (legacy ERP, CRM, spreadsheets, integrations)
- [Critical] Classification: what to migrate, what to archive, what to delete
- [Critical] Assignment of business data owners by data domain
- [Critical] Documentation of all mapping decisions with their rationale
- [Recommended] Identification of specific incompatibilities of the source system (NAV, GP, Sage 100, local system)
Cleaning phase
- [Critical] Deduplication of master records (customers, vendors, items)
- [Critical] Completeness verification of mandatory fields
- [Critical] Format standardization (dates, currencies, country/region codes, tax data)
- [Critical] CFO sign-off on clean data
- [Recommended] Archiving of historical data outside the migration period
Validation and reconciliation phase
- [Critical] Three migration cycles in sandbox before cutover
- [Critical] GL, AR, and AP reconciliation with 0% tolerance on financial records
- [Critical] Referential integrity verification between tables
- [Critical] Documented rollback plan with activation criteria and decision window
- [Critical] Formal sign-off from the finance team before go-live
- [Recommended] UAT with key business users in real-world scenarios
Post-go-live (first 4 weeks)
- [Critical] Daily monitoring of errors in BC audit trail
- [Critical] Correction with root cause traceability (not just patching)
- [Recommended] Cleanup of test data and temporary records
- [Recommended] Activation of continuous data governance policies
Frequently asked questions about data migration in Business Central
How long does data migration to Business Central actually take?
The data migration phase takes between 3 and 8 weeks depending on volume, source data quality, and integration complexity. Most of the time is not spent on the technical load, but on cleaning and validation. Companies with well-maintained data can complete the process at the lower end of the range; those carrying years of inconsistencies need more preparation time.
Is it necessary to migrate all historical data?
No. The recommended practice is to migrate active master data, open transactions, and a defined historical period for reporting. Older data is archived externally. Migrating everything without criteria increases complexity, degrades system performance, and unnecessarily extends the project.
What happens if discrepancies are detected after go-live?
The first step is not to correct the symptom without identifying the root cause in the migration pipeline. Use Business Central’s audit trail to trace the origin of the error, correct the data in production, and document the resolution. If the discrepancy affects financial balances, involve the finance team before any adjustment to maintain audit traceability.
Who is responsible for validating the data: IT or the business?
Both, with different roles. IT ensures technical integrity: that records were loaded correctly, that mappings are accurate, and that there are no structural errors. The business — especially finance — validates that the values are correct from an operational perspective. The go-live sign-off must come from the CFO, not just the technical team.