Migrate from Splio to Freshsales

Splio Contacts map to Freshsales Lead for unqualified prospects and Contact for qualified buyers or existing customers. We resolve the split using Splio's loyalty tier (if set) and order history presence as proxies: contacts with prior orders or loyalty memberships become Contacts attached to an Account; contacts without either become Leads. The original Splio contact_id is preserved in a custom field splio_contact_id__c on both objects. Pre-migration, we audit list membership and assign orphan contacts (those with no list) to a catch-all segment before export to avoid the silent exclusion gap.

Splio Orders map to Freshsales Deal records. The Splio order_id becomes a custom field splio_order_id__c on the Deal for audit traceability. Order date becomes Deal Created Date; order total maps to Deal Amount; order status (pending, completed, cancelled) maps to a custom picklist field order_status__c. Splio supports order replacement on re-import with the same order_id; Freshsales Deals are unique by external_id__c so we use splio_order_id__c as the external_id to prevent duplication.

Order items (line items within a Splio Order) do not have a direct Freshsales equivalent. For migrations where line-item detail is critical for reporting, we create a Task per order item with a custom order_item_detail__c field carrying the product name, quantity, and price as a formatted string, or we map products to Freshsales Product2 records and link them via a Deal Product association if the customer is on a Freshsales plan that supports Products. The mapping strategy is confirmed during scoping.

Splio Products map to Freshsales Product2 records. Product code, name, and price migrate directly. Products must exist in Freshsales before any order item that references them, so we sequence Product migration before Order migration. Custom fields on Splio products (products scope) migrate as custom fields on Product2.

Loyalty membership data (card_code, nq_points, q_points, tier, membership_start_date) has no native Freshsales equivalent and migrates as custom Contact fields: loyalty_card_code__c, loyalty_nq_points__c, loyalty_q_points__c, loyalty_tier__c, loyalty_start_date__c. If the customer requires a queryable loyalty history (reward attributions over time), we create a Loyalty_Activity__c custom object with a lookup to Contact and fields for activity_type, points_delta, and timestamp. We do not migrate loyalty program rules or tier logic as code; these are documented for admin rebuild in Freshsales Workflows.

Reward definitions at the program level are documented as a configuration inventory. Individual reward attributions (which contact received which reward and when) migrate as records in the Loyalty_Activity__c custom object with activity_type = 'Reward', points_delta (if points-based), reward_name__c, and attribution_date__c. The reward attribution history is preserved for reporting but does not trigger any automation in Freshsales without explicit workflow rebuild.

Splio Store records (physical retail locations and e-commerce sites) map to Freshsales Location records if the destination account has the Locations feature enabled, or to a custom Account record with a store_type__c picklist set to 'Physical Store' or 'E-commerce'. Store attributes (address, location, custom fields in the stores scope) migrate as typed fields on the destination record.

Splio Interactions are custom events sent via API for loyalty credits, purchase triggers, and behavioral tracking. Each Interaction type maps to either Task (if it represents a discrete action with an outcome, such as a loyalty point credit) or Event (if it represents a meeting or appointment-like occurrence). The original Splio interaction_id is preserved in a custom field splio_interaction_id__c. High-volume interaction event logs may exceed CSV import limits; for accounts with more than 100,000 interaction records, we use the Freshsales REST API with pagination and exponential backoff rather than the CSV import path.