SAP ECC → Business Central migration: the data track
In an SAP ECC → Dynamics 365 Business Central migration the system implementation is done by a BC partner; the data track — extracting, profiling, validating, mapping and simulating the data before the partner loads it — is a separate job that decides whether the programme lands. Run as four gates, it typically cuts test migrations from five or six to one or two, and the validation rules built for it keep working in Business Central after go-live.
Updated · Visehub
Two tracks, two owners
A migration to Business Central has a system track and a data track. The BC implementation partner configures and launches the target and loads the final files. The data track — everything between the ECC tables and clean, mapped, simulated files on the partner’s dates — is a separate job. When nobody owns it explicitly, the client’s own team ends up owning it in spreadsheets, and that is where ECC → BC migrations die.
Four gates
Run as a sequence of gates, each removing one class of error:
| Gate | Stage | What it removes |
|---|---|---|
| 01 | Extraction & profiling | Surprises: gaps, inconsistent formats, values that will not fit the target |
| 02 | Validation at source | Errors that would otherwise appear at load time, while fixes are still cheap |
| 03 | Field & value mapping | Wrong meanings: what each ECC field becomes in BC is a business decision confirmed by business users and BC consultants together |
| 04 | Load simulation | Load-time failures, found in a dry run with no consequences |
The payoff is measured in test migrations: five or six cycles become one or two, and test cycles are where most migration time and budget go.
Where it gets specific
- Customer roles. SAP payer and ship-to parties map to BC structures depending on values in specific fields; the rule has to be written down and tested, not remembered.
- Duplicates. Customer records spread across several systems and duplicated within one, differing by a space or a comma — golden records come from documented matching, not manual review.
- Bills of materials. Production BOM structures transformed to the BC model with a preview before the load.
- Reuse across entities. Rules built for the first legal entity become the template for the next — at Karlsberg, the German parent’s configuration was reused for the French unit.
vise FieldMap now drafts the field pairs with a confidence score and a reason — catching, for instance, an internal SAP address reference (ADRNR) mapped to a BC document-number field, a 35-character city mapped to a 30-character target, or codes like 00123 losing their leading zeros in a numeric field.
After go-live, and after ECC
The validation rules built for the migration are re-pointed at Business Central and keep stopping bad data at the point of entry. And the same extraction and validation discipline carves out the ECC history that must be kept — financial documents, master data, the audit trail — into a profiled, queryable archive, so the old system can be decommissioned instead of kept alive read-only.
Read the cases
The full event write-up from ERP reDefined 2026 with IT.integro is here; the Karlsberg project — SAP to Navision, customer and BOM data, one specialist instead of five — is here. The service runs in either direction: SAP ↔ Business Central.
Frequently asked
- Why move from SAP ECC to Business Central at all?
- Cost, usually: ECC mainstream maintenance is ending, and for mid-sized companies a simpler ERP cuts licence and maintenance cost. The trade-off is that SAP structures — customer roles, BOMs, sales areas — have to be transformed to a different model, not copied.
- What is the hardest part?
- Not creating the mappings but discovering the mistakes too late. Hundreds of ECC → BC field mappings built in a spreadsheet have no validation or dependency checks; errors surface in the migration window, when each fix costs days.
- Which objects cause the most trouble?
- Customer master (scattered, duplicated, with roles that map to different BC structures depending on field values) and bills of materials. At Karlsberg those two objects were handled by one Visehub specialist instead of the five people the work was estimated at.
- Can we switch ECC off afterwards?
- Yes, if the history needed for audit, tax, retention and reporting is carved out, validated and kept queryable. Keeping ECC alive read-only costs licences, infrastructure and maintenance every year.