Microsoft Dynamics 365 · Financials · Master data

    Microsoft Dynamics 365 Customer Data Migration

    Migrate customers into Dynamics 365 Finance, covering the customer record, the underlying global address book party, addresses, payment and credit setup, and the data entity load path.

    Discuss Your MigrationAll Migration Objects

    Object overview

    Dynamics 365 Finance separates the party from the customer. The global address book holds the party — the organisation or person — and the customer record is that party's role in a specific legal entity. A group trading with one organisation across three legal entities has one party and three customer records.

    Loading happens through data entities rather than tables, staged through data projects. That gives a structured contract, but it also means a row can pass into staging and still fail promotion into the target tables — so both stages are reconciled, not just the file load.

    What data is typically migrated

    Scope is agreed in discovery; this is the shape of the object.

    Data areaTypical information
    PartyGlobal address book party record, name, party type
    CustomerCustomer account number, group, legal entity, currency, status
    AddressesPostal addresses with purposes — invoice, delivery, business
    ContactsContact persons and their electronic addresses
    PaymentTerms of payment, method of payment, payment schedule
    CreditCredit limit, credit rating, hold status
    TaxSales tax group, tax exempt number, registration IDs

    Object relationships

    Dependency drives load sequence: a child cannot exist before its parent.

    Global address book party
    └─ Customer (legal entity role)
    └─ Postal address + purpose
    └─ Contact person
    └─ Payment setup
    └─ Credit setup
    └─ Tax registration

    Object migration flow

    Source Customers→DataMove→Map & transform→Validate→Microsoft Dynamics 365 Customers→DataVault reconciliation→Sign-off

    Before you migrate this object

    Confirm each of these before the first migration cycle.

    □Legal entities are configured
    □Customer groups and posting profiles exist
    □Terms of payment, payment methods and sales tax groups are configured
    □Number sequences are set up for the chosen account-number strategy
    □Address purposes are defined
    □Party de-duplication rules are agreed
    □The staging-to-target reconciliation method is agreed

    Common source systems

    Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.

    Oracle EBS SupportedSAP ECC SupportedSalesforce SupportedLegacy ERP Custom mapping

    Source-to-target mapping examples

    Object-level equivalence. Field-level mapping is produced per engagement.

    Source systemSource entityTarget object
    Oracle EBSCustomer + Account + Site UsesD365 Party + Customer + Addresses
    SAP ECCCustomer master (KNA1/KNB1)D365 Party + Customer per legal entity
    SalesforceAccountD365 Party + Customer

    Migration methods for this object

    Data Management Framework — customer data entities staged through a data project

    Composite entities where party and customer load together

    Number sequences configured before load if legacy account numbers are not retained

    Extraction considerations

    Party versus legal entity roleA customer trading across several legal entities is one party with several customer records. Extracting the legal entity dimension is what makes that expansion correct.
    Address purposesInvoice, delivery and business addresses carry different meaning. Extracting them without purpose produces addresses the system cannot use for the right transaction.
    Customers with open receivablesMust migrate regardless of activity policy, because the open transactions depend on them.
    Number sequence strategyWhether legacy customer account numbers are retained determines how number sequences are configured, and it has to be decided before extraction.

    Transformation rules

    Customer group and posting profileThese drive account determination in Dynamics, so the mapping determines accounting behaviour rather than just classification.
    Terms of payment crosswalkSource terms mapped to configured Dynamics terms.
    Address purpose mappingSource address types mapped onto Dynamics address purposes.
    Sales tax group assignmentMapped to configured tax groups; incorrect assignment produces wrong tax on every transaction.
    Party de-duplicationWhere the same organisation exists in several sources, matched and merged into one party carrying several customer records.

    Data quality and validation

    Legal entity exists

    Every customer record references a configured legal entity.

    Customer group and posting profile exist

    Account determination fails otherwise.

    Terms of payment exist

    Every crosswalked term resolves.

    Address has a purpose

    And a valid country and region.

    Sales tax group valid

    For the customer's country and legal entity.

    Duplicate account number

    Within the legal entity.

    Load sequence and dependencies

    What has to exist before this object can load.

    1. 1Legal entities and number sequences
    2. 2Customer groups and posting profiles
    3. 3Terms of payment and payment methods
    4. 4Sales tax groups
    5. 5Global address book parties
    6. 6Customers per legal entity
    7. 7Addresses with purposes
    8. 8Contacts
    9. 9Credit setup

    Common migration errors

    What actually fails on this object, and why.

    Staging succeeded, promotion failedThe row is structurally valid but rejected by a business rule when moved into the target tables — the failure mode unique to the DMF two-stage load.
    Customer group not foundThe mapped group does not exist in the target legal entity.
    Invalid terms of paymentNo configured equivalent for the crosswalked value.
    Address without a purposeThe address loads but cannot be selected for invoicing or delivery.
    Number sequence exhausted or misconfiguredAccount numbers cannot be assigned.
    Duplicate partyThe same organisation created twice because match rules were not applied.

    Reconciliation

    Counts alone rarely prove this object migrated correctly.

    Party count versus customer count — customers should exceed parties where entities share customers

    Customer count per legal entity against the expected matrix

    Customers with open AR reconciled at 100%

    Address coverage: every customer that will be invoiced has an invoice address

    Staging versus target counts, reconciled separately — the DMF-specific check

    Key field comparison on a sample: group, terms, credit limit, tax group

    How Syntra ETL supports this object

    DataMove

    Extraction, mapping, transformation, validation preparation and target load generation.

    Explore DataMove →

    DataVault

    Preserves source, prepared and target states for reconciliation, lineage and audit evidence.

    Explore DataVault →

    DataLens

    Migration progress, data quality, exceptions and readiness across cycles.

    Explore DataLens →

    Relevant migration routes

    Source-specific guidance for moving this object.

    Oracle EBS→Microsoft Dynamics 365

    Oracle EBS to Microsoft Dynamics 365 data migration

    Explore migration route →    SAP ECC→Microsoft Dynamics 365

    SAP ECC to Microsoft Dynamics 365 data migration

    Explore migration route →    Salesforce→Microsoft Dynamics 365

    Salesforce to Microsoft Dynamics 365 data migration

    Explore migration route →

    Successfully delivered projects involving this object

    Published case studies whose scope included customers.

    SAP ECC→Oracle Fusion CloudLarge UK EnterpriseEnterprise · UK
    • SAP ECC Legacy source platform
    • Oracle Fusion Target cloud platform
    • Multi-cycle Rehearsals before cutover
    Successful SAP ECC to Oracle Fusion migration with comprehensive source-to-target reconciliation across cycles.MIGRATION COMPLETEView Project →    SAP R/3→Oracle Fusion CloudLarge German EnterpriseEnterprise · Europe
    • SAP R/3 Legacy source platform
    • Oracle Fusion Target cloud platform
    • Multi-cycle Controlled migration cycles
    Successful migration to Oracle Fusion Cloud with reduced manual conversion and comprehensive reconciliation and auditability.MIGRATION COMPLETEView Project →

    Frequently asked questions

    Why does Dynamics separate the party from the customer?
    Because the global address book holds the organisation once, and the customer record represents that organisation's role within a specific legal entity. A company trading across three legal entities is one party and three customers.
    What is the difference between staging and target in a DMF load?
    Data entities load into staging tables first, then promote into the target tables. A row can pass staging and still fail promotion on a business rule, which is why both stages are reconciled rather than just the file load.
    Should legacy customer account numbers be retained?
    It depends on whether they carry business meaning. Retaining them requires number sequences configured for manual or external numbering; generating new ones requires a cross-reference so open transactions can still resolve.
    Why does customer group mapping matter?
    Because the customer group and posting profile drive account determination. A wrong group posts receivables to the wrong ledger account, and the error only becomes visible once transactions start flowing.

    Planning a similar data migration?

    Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.

    Discuss Your MigrationExplore Migration Routes