Microsoft Dynamics 365 · SCM · Master data

    Microsoft Dynamics 365 Product Data Migration

    Migrate products into Dynamics 365 Finance and Supply Chain, covering the shared product master, released products per legal entity, product dimensions, units of measure and inventory setup.

    Discuss Your MigrationAll Migration Objects

    Object overview

    Dynamics separates the shared product from the released product. The product master is defined once across the organisation; releasing it to a legal entity creates the record that entity can actually transact. One product released to four legal entities is one product master and four released products.

    Product dimensions add a second multiplier. A product with size and colour dimensions generates a variant per combination, and each variant can carry its own inventory and costing. Variant explosion is the most common reason product volumes come in far above the source count.

    What data is typically migrated

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

    Data areaTypical information
    Product masterProduct number, name, type, subtype, product dimension group
    Released productPer legal entity: item group, item model group, storage and tracking dimension groups
    DimensionsSize, colour, style, configuration and the variants they generate
    Units of measureInventory, purchase and sales UOM with conversions
    CostingItem model group, cost price, costing method
    Trade agreementsPurchase and sales prices where in scope
    Default order settingsSite, warehouse, order quantities per legal entity

    Object relationships

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

    Shared product master
    └─ Product dimensions → variants
    └─ Released product (legal entity)
    └─ Item group / item model group
    └─ Default order settings → site / warehouse
    └─ UOM conversions
    └─ Trade agreements

    Object migration flow

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

    Before you migrate this object

    Confirm each of these before the first migration cycle.

    □Legal entities, sites and warehouses are configured
    □Dimension groups, item groups and item model groups exist
    □Units of measure and conversions are loaded
    □The product numbering strategy is agreed
    □Dimension usage is profiled and the expected variant count is known
    □Batch and serial control decisions are final
    □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 SupportedLegacy ERP Custom mapping

    Source-to-target mapping examples

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

    Source systemSource entityTarget object
    SAP ECCMaterial master (MARA + MARC)D365 Product master + Released products
    Oracle EBSMTL System ItemsD365 Product master + Released products

    Migration methods for this object

    Data Management Framework — product and released product data entities

    Composite entities where product and released product load together

    Variants generated from dimension combinations rather than loaded row by row

    Extraction considerations

    Legal entity dimensionExtracting only the product definition produces products nobody can transact. Released-product rows per legal entity are what make them usable.
    Product dimension groupsWhether a product is dimension-controlled changes its record count dramatically. Profiling dimension usage before extraction prevents a surprise at load.
    Tracking dimensionsBatch and serial control determine inventory behaviour and cannot be changed once transactions exist, so they are established before load.
    Products with stock or open ordersMust migrate regardless of status, because inventory and order objects depend on them.

    Transformation rules

    Item group and item model groupThese drive ledger posting and costing method. The mapping determines accounting behaviour, not just classification.
    Dimension group assignmentProduct, storage and tracking dimension groups mapped from source characteristics; these cannot be changed after transactions exist.
    UOM crosswalkInventory, purchase and sales UOM mapped with conversions preserved.
    Product number strategyRetain the legacy number or generate via number sequence with the legacy value as a cross-reference.
    Variant generationDimension combinations expanded into variants rather than loaded as individual product rows.

    Data quality and validation

    Dimension groups exist

    Product, storage and tracking groups all configured.

    Item group and model group exist

    Ledger posting fails otherwise.

    UOM and conversions defined

    For every UOM referenced.

    Released to every required legal entity

    A product transacted in an entity must be released to it.

    Duplicate product number

    Across the shared product master.

    Cost present for standard-costed model groups

    Movements cannot be valued without it.

    Load sequence and dependencies

    What has to exist before this object can load.

    1. 1Legal entities, sites and warehouses
    2. 2Units of measure and conversions
    3. 3Dimension groups, item groups and item model groups
    4. 4Shared product master
    5. 5Product dimensions and variants
    6. 6Released products per legal entity
    7. 7Default order settings
    8. 8Trade agreements
    9. 9Inventory on hand

    Common migration errors

    What actually fails on this object, and why.

    Released product without a product masterThe shared product failed or was out of scope.
    Dimension group not foundThe mapped product, storage or tracking group is not configured.
    Item model group missing costing setupStandard-costed products load without a cost.
    Staging passed, promotion failedThe DMF two-stage failure mode — structurally valid, rejected on a business rule.
    Variant explosion beyond expectationDimension combinations produced far more variants than planned, usually because dimension usage was not profiled.
    UOM conversion missingA purchase or sales UOM has no conversion to the inventory UOM.

    Reconciliation

    Counts alone rarely prove this object migrated correctly.

    Shared product count: source distinct products vs loaded

    Released product count against the expected product-to-legal-entity matrix

    Variant count against expected dimension combinations — the figure most likely to surprise

    Products with on-hand stock reconciled at 100% before the inventory load

    Staging versus target counts reconciled separately

    Cost coverage for standard-costed item model groups

    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 →

    Related enterprise migration experience

    We have not published a case study whose scope specifically covered this object. Explore delivered projects across ERP, HCM, payroll and CRM data.

    See Delivered Projects

    Frequently asked questions

    What is the difference between a product and a released product?
    The shared product master defines the product once across the organisation. Releasing it to a legal entity creates the record that entity can transact. A product used by four legal entities is one master and four released products.
    Why do product counts expand so much during migration?
    Two multipliers: release per legal entity, and variant generation from product dimensions. A dimension-controlled product produces a variant per combination, which is why dimension usage is profiled before extraction.
    Can tracking dimensions be changed after migration?
    Not once transactions exist. Batch and serial control decisions are effectively permanent, so they are settled before the first load rather than adjusted afterwards.
    Why does item model group mapping matter?
    It drives the costing method and ledger posting. A wrong item model group values inventory incorrectly and posts to the wrong accounts, and the error only surfaces once transactions flow.

    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