Migrate from Splio to Microsoft Dynamics 365 Sales

Splio Contacts map to Dynamics 365 Contact records, each linked to an Account. We perform a list-membership audit before export: any Splio Contact without at least one list assignment is flagged as an orphan, assigned to a catch-all segment, and verified against the total contact count to prevent silent data loss. The Splio contact ID is preserved in a custom field splio_contact_id__c for audit traceability. Email, phone, address, and custom fields migrate to typed Dynamics fields.

Splio Store records (physical retail locations and e-commerce sites) map to Dynamics 365 Account records. The store name becomes Account Name, store address maps to Address composite fields, and store-level custom fields migrate to Account custom fields. Store scope from Splio is distinct from the Contact scope, so Accounts are created first to satisfy Contact lookups.

Splio Orders link to a Contact and carry order_items referencing Products. Dynamics 365 Sales does not have a native Order object at the CRM layer; orders are typically represented as Opportunities with custom order fields (order number, order date, fulfillment status) or handled via Dynamics 365 Business Central if the customer licenses the ERP. We determine the order representation strategy during scoping based on whether Business Central is in the destination stack.

Splio order_items (line items referencing a product) require the parent Order to exist before the item can be linked. We sequence order_item migration after the parent Order-Opportunity record is created in Dynamics. Product2 reference resolution and Pricebook2 assignment happen at this stage. If the order is represented as a custom entity rather than Opportunity, line items migrate to a custom Order Line Item entity with a lookup to the parent Order.

Splio Products (standalone catalog items referenced by order_items) map to Dynamics 365 Product2 records. ProductCode from Splio maps to Product2 Product Code; product name maps to Name. Product-level custom fields (from the products scope) become Product2 custom fields. Standard Pricebook entries are created during import.

Splio Loyalty Membership records carry card_code, q_points (quantized), nq_points (non-quantized), and tier. Dynamics 365 Sales has no native loyalty entity, so we create Contact-level custom fields: splio_loyalty_card_code__c (text), splio_loyalty_q_points__c (number), splio_loyalty_nq_points__c (number), splio_loyalty_tier__c (picklist). Point balance values migrate as-is; fractional values are preserved in decimal fields. Tier values are mapped to a picklist.

Splio Rewards (defined at the program level) and Reward Attributions (which contacts received which rewards) require a custom entity in Dynamics. We design a splio_reward_attribution__c custom entity with lookups to Contact (the recipient), a splio_reward_name__c text field, splio_reward_type__c, splio_reward_date__c, and splio_reward_status__c. The custom entity is created in the destination Dynamics org before migration begins.

Splio Interactions are custom events sent via API (e.g., loyalty point credits, purchase triggers). These map to a custom splio_interaction__c entity with fields for interaction type, timestamp, source contact reference, and payload data. We export interaction event logs and create records in the custom entity with a Contact lookup resolved at migration time.

Splio Lists drive segmentation and export eligibility. We preserve list memberships as tags or as a multi-select picklist field splio_lists__c on Contact. Blocklists map to a splio_blocklist__c flag and a suppression exclusion set in Dynamics. The customer chooses the target representation during scoping.