Migrate from Splio to HighLevel

Splio contacts map to GoHighLevel contacts. The primary migration risk is Splio's silent exclusion of contacts without list membership from all exports. We run a list-membership audit during scoping, flag orphan contacts, assign them to a catch-all tag (e.g., __orphan_no_list), and include them in the export manifest. Standard contact fields (first name, last name, email, phone, address) map directly. Custom fields on the contacts scope migrate as GoHighLevel contact custom fields.

Splio's stores scope (physical locations and e-commerce sites) maps to GoHighLevel locations, which function as business-unit containers for contacts, pipelines, and custom objects. Physical store address data becomes the GoHighLevel contact address fields for store-manager or retail-worker contacts. E-commerce store identifiers migrate as a custom field on the primary contact record.

Splio products are standalone items referenced by order_items. They map to a GoHighLevel Product Custom Object if the destination account does not have the native Products feature enabled. Product attributes and SKU migrate as custom fields on the Product object. If the customer uses GoHighLevel's built-in product catalog, we map to the native Product2 equivalent with Standard Pricebook entries.

Splio orders link a contact to a set of order_items and carry order metadata (date, status, total). They map to GoHighLevel Opportunities using a custom order-type pipeline so that order history lives in the CRM without contaminating the sales pipeline stages. The Splio order_id becomes a custom field on the Opportunity to prevent duplicate imports. If the customer requires order history as a separate record type, we create an Order Custom Object and link it to the Contact via a lookup.

Splio order_items (individual line items with product reference, quantity, and price) map to line items on the corresponding Order Opportunity in GoHighLevel. The parent order must exist before order_items are inserted, so we sequence order parent records first and resolve the Opportunity ID for each order_item batch. Splio rejects order_items for orders that do not exist; we enforce this dependency in our import sequencing.

Splio loyalty memberships carry card_code, nq_points (non-quantized balance), q_points (quantized balance), and tier. We create a LoyaltyMember Custom Object in GoHighLevel with these fields and link each record to the corresponding Contact via a lookup. Fractional point balances transfer as decimal number fields. Tier names migrate as a picklist or text field. This is the most schema-intensive object in the migration because of the cross-references to contacts.

Splio rewards are defined at the program level; reward attributions track which contacts received which rewards. We create a Reward Custom Object with fields for reward name, type, point cost, and validity period. Attributions are either stored as a multi-select lookup on the LoyaltyMember object or as a separate RewardAttribution Custom Object with Contact and Reward lookups, depending on the customer's attribution reporting requirements.

Splio Interactions are custom API events (loyalty point credits, campaign triggers, loyalty tier changes) stored as event records. We export interaction event logs and create a Custom Object (e.g., LoyaltyActivity) in GoHighLevel with fields for event type, timestamp, point delta, and related LoyaltyMember. These are historical records and do not trigger GoHighLevel workflows; they are migrated for audit and reporting continuity.

Splio list memberships drive segmentation and export eligibility. We preserve list membership as GoHighLevel tags on each contact. A contact assigned to three Splio lists receives three corresponding tags. The tag strategy is documented and agreed with the customer during scoping; bulk tagging is applied post-contact import.

Splio suppression lists migrate to GoHighLevel's global unsubscribe list, which honors unsubscribes across email and SMS campaigns automatically. We export blocklist emails and phone numbers separately and upload via GoHighLevel's bulk contact management to ensure these contacts are suppressed before any campaign sends resume in GoHighLevel.