Why SAP ECC → Business Central Migrations Die on Data
Takeaways from ERP reDefined 2026 with IT.integro: migrations fail on data, not systems. Each step as a gate — profiling, validation at source, field and value mapping, load simulation — cuts five or six test migrations to one or two. Plus what FieldMap catches, and how to switch ECC off without losing its history.
· Andrzej Bartosiewicz · updated 3 November 2026
Event recap · ERP reDefined 2026, organised by IT.integro · SAP ECC → Microsoft Dynamics 365 Business Central
Mainstream support for SAP ECC is ending — and the real risk isn’t the system. It’s the data.
With SAP ECC mainstream maintenance winding down, the question for many organisations is no longer whether to move but when and how. At ERP reDefined 2026 we shared the stage with IT.integro, a Microsoft Dynamics 365 Business Central implementation partner, to talk about moving from ECC to Business Central safely. Our message was one sentence, and the room seemed to agree: an ERP migration doesn’t die on the systems. It dies on the data.
The hard part isn’t creating the mappings — it’s discovering the mistakes too late
In most projects a spreadsheet is the single source of truth for field mappings. It has no validation, no dependency checks and no visibility into hidden issues. Hundreds of ECC → BC mappings are built by hand, and the errors stay invisible until migration testing starts — inside the window, under cut-over pressure, when every fix costs days instead of minutes.
A classic mapping workshop brings three groups together, and misalignment between them becomes mapping errors nobody sees until testing:
- Business users know the source system and what the data actually means.
- The IT team owns the technical side: extraction and source structures.
- Target-system consultants know how Business Central expects data to be structured.
Every step is a gate that filters out errors
We run the migration as a sequence of gates rather than one big transfer at the end. Each gate removes a different class of error. This pipeline is the data-migration layer; it does not replace the Business Central implementation: SAP ECC → Visehub data-migration track → BC implementation partner → Business Central.
| Gate | Stage | Purpose |
|---|---|---|
| 01 | Extraction & profiling | See what the source data actually contains |
| 02 | Validation at source | Catch errors before load, while fixes are cheap |
| 03 | Field & value mapping | Decide what each field means in the new system |
| 04 | Load simulation | Dry-run the load with no consequences |
Step 01 — Extraction & profiling
Value-distribution analysis reveals gaps, inconsistent formats and values that will not fit the target — before any mapping starts, when problems are cheapest to address.
Step 02 — Validation at the source
Errors are caught here, not at load time. Rules built at this gate are reused later, which is where the post-go-live story below begins.
Step 03 — Field & value mapping
Mapping is a business decision, not just a technical task: what does each source field mean in the new Business Central setup? Business users and consultants confirm the meaning together.
Step 04 — Load simulation
A dry run with no effect on live data, before anything touches production.
“1–2 instead of 5–6”
The number of test migration cycles drops from five or six to one or two. Test cycles are where most migration time and budget go; that reduction is the main return on catching errors at the source.
AI in field mapping — and in writing the rules
vise FieldMap assists the mapping transparently: every suggestion shows a confidence score and a plain-language rationale based on semantic fit, type compatibility, length and value distribution. Suggestions sort into three groups — approved cleanly, with problems to review, declined — and the user keeps the final decision. Validation rules and transformations can also be written from a plain-language description, which turns days of coding into minutes and lets business users define rules themselves.
Three cases from the live demo:
| Case | Issue caught | Outcome |
|---|---|---|
| SAP ADRNR reference | An internal address reference mapped to a Business Central document-number field — labels and data looked plausible | Flagged as a semantic mismatch, correct field suggested |
| City field | Source length 35 mapped to target length 30 | Flagged for possible truncation of longer city names |
| Codes such as 00123 | Leading zeros dropped when stored in a numeric field | Identified as a risk of codes no longer matching |
The migration ends. The tool stays.
The validation rules built for the migration are not discarded at cut-over. They are re-pointed from validating source data to validating the new Business Central system.
- During migration: rules validate source data and catch errors before they load.
- After go-live: the same rules validate Business Central at the point of data entry, every day — data quality as a daily practice, not a one-time project.
Switching ECC off — without losing its history
Going live on Business Central is only half the decision. Historical ECC data is still needed for audits, tax, legal retention and reporting, and keeping the old system running read-only is expensive: licences, infrastructure, maintenance, every year. The same extraction and validation discipline can carve out and archive what must be kept.
- Retain — carve out what matters. Extract and validate only the records that must be kept: financial documents, master data, the audit trail. Not the entire legacy database. The result is a profiled, validated, structured archive.
- Report — keep reporting online. The retained data stays queryable, so finance and business teams pull historical reports on demand without logging into the old system.
- Decommission — switch ECC off with confidence. With history preserved and accessible, the legacy system can go, and its licence, infrastructure and maintenance costs with it.
Materials from ERP reDefined 2026
Thank you to IT.integro for the invitation and the organisation, and to everyone who stayed for the conversations about migration, data quality and practical AI. FieldMap was one of several tools we showed, next to vise DMW, vise LoV-MAP and vise Data Run. The bigger story is how the data side of an ECC → BC migration now runs with fewer people and fewer test cycles, with errors caught at source, alongside the BC partner.
Planning a SAP ECC → Business Central migration?
Read how we run the data track between SAP and Business Central in either direction, or start with a free 30-minute data-readiness assessment and a 30-day proof of concept on one object.