No standard tool covers it
Vendor migration tooling assumes you are moving within that vendor's own family. The moment the source is a different ERP, the mapping is bespoke — which is exactly the work Falcon Mapping was built to accelerate.
Solutions · Data Engineering
Cross ERP Data Migration
Migrating data between different ERP vendors — SAP to Dynamics 365, Dynamics AX to D365, Oracle to SAP — where the data models do not agree and no standard tool covers the gap.
Cross ERP Data Migration
When the two systems do not speak the same language
Cross ERP data migration is moving data between two different ERP systems — SAP to Dynamics 365, Dynamics AX to D365, Oracle to SAP — where the source and target use different data models. It differs from a standard migration in one decisive way: no vendor tool covers the gap. The mapping between the two models has to be designed, and many source concepts have no equivalent in the target at all.
That makes it a business design exercise wearing technical clothing. The programmes that go well are the ones that recognise this early and put the right people on the mapping decisions.
Routes we deliver
The combinations we are asked for most
- Dynamics AX 2009 / 2012Dynamics 365 F&O
The most common cross-generation move. Data model changes substantially; custom AX tables rarely have a D365 counterpart.
- SAP ECCSAP S/4HANA
Same vendor, materially different model — the customer and vendor master merge into Business Partner, and finance tables are restructured.
- SAPDynamics 365
A true cross-vendor move. Chart of accounts, partner models and document flows have no one-to-one mapping and must be redesigned, not translated.
- Oracle / JD Edwards / legacySAP or D365
Usually the hardest: sparse documentation, heavy customisation, and original implementers long gone.
What makes it harder
Four things that are true across vendors and not within one
The data models genuinely disagree
This is not a rename. A concept that is one object in the source may be three in the target, or may not exist at all. Those are business design decisions, and pretending they are technical mapping decisions is how programmes stall.
Reconciliation has no common ground
Within one vendor you reconcile like for like. Across vendors the two systems count differently, so the reconciliation basis has to be agreed with finance up front rather than discovered at go-live.
Institutional knowledge has left
Legacy ERPs carry a decade of undocumented customisation. Profiling the data is often the only reliable source of truth about what the system actually does.
Cross ERP migration: common questions
What is cross ERP data migration?
Cross ERP data migration is moving data between two different ERP systems — such as SAP to Dynamics 365, Dynamics AX to D365, or Oracle to SAP — where the source and target use different data models. It differs from a standard migration because no vendor tool covers the gap: the mapping between the two models has to be designed rather than configured, and many source concepts have no direct equivalent in the target.
How is cross ERP migration different from an upgrade?
An upgrade keeps you inside one vendor's data model, so most structures carry across and vendor tooling handles the bulk of the work. A cross-ERP migration changes the model itself, which turns mapping into a business design exercise: someone has to decide what a source concept becomes in the target when there is no equivalent. That decision-making, not the data movement, is where the time goes.
Can you migrate from SAP to Dynamics 365?
Yes. SAP to Dynamics 365 is a genuine cross-vendor migration: the chart of accounts, the partner model, and document flows have no one-to-one mapping and must be redesigned rather than translated. We deliver it with a mapping layer built in Falcon Mapping, transformation code generated by Code Cheetah, and a reconciliation basis agreed with finance before any load runs.
What happens to customisations that do not exist in the target?
Each one gets an explicit decision: replicate it in the target, replace it with standard functionality, or retire it. Nothing should carry across by default. Cross-ERP migrations are the best opportunity most organisations get to shed customisations that were built around a limitation the new system does not have.
How long does a cross ERP migration take?
Typically six to twelve months for a mid-sized enterprise, longer than a same-vendor move of comparable size because the mapping design and reconciliation basis both have to be built from scratch. The variable that moves this most is how quickly the business can make mapping decisions, not how fast the data can be processed.
How do you reconcile data across two different ERPs?
By agreeing the reconciliation basis with finance before the first load, since the two systems count differently and there is no automatic like-for-like comparison. In practice that means agreeing which balances, open item totals and record counts constitute proof, then making that reconciliation reproducible on demand rather than performing it once.