Migrate from Solitics to Zoho CRM

Solitics User Profiles aggregate attributes, transaction history, and behavioral events from all integrated sources into a unified record. We map standard demographic and firmographic attributes to Zoho CRM Contact fields. Behavioral attributes that do not map to standard Contact fields (trading volume, deposit history, session frequency, custom segmentation properties) migrate into a custom module called Behavioral_Profile__c with lookup to Contact. The custom module uses multi-select picklists for categorical behavioral data and integer/currency fields for quantitative attributes. Schema discovery identifies every active custom property before field mapping begins.

Solitics standard events (registration, deposit, withdrawal, trade, bet, login, session_start, session_end) have no direct Zoho CRM equivalent. We create a custom module Behavioral_Events__c with fields for Event_Type__c (picklist), Event_Timestamp__c (datetime), User_Profile_Lookup__c (lookup to Contact), Event_Properties__c (JSON or multi-line text for property bag), and Source_Channel__c (SMS, email, push, in-app, WhatsApp). Events import in timestamp order with batch chunking to respect Zoho API rate limits. Historical event volume determines whether we use Zoho's REST API or CSV bulk import.

Solitics custom event schemas require a discovery pass before migration. We query the Solitics API to catalog every named custom event type and its property fields, then extend the Behavioral_Events__c custom module with additional custom fields per event type. Property names become field labels with API-safe names. If a custom event has a property that does not match an existing Zoho field type, we use a multi-line text or JSON field to preserve the full property bag. This approach prevents silent data loss on custom event history that would otherwise be missed.

Solitics segments are live, rule-based definitions built from profile attributes and behavioral conditions. Zoho CRM does not have native segment objects; segments are represented as saved Filters on Contact and Deal views. We export every Solitics segment definition as structured rule logic, then rebuild each as a Zoho CRM Filter (for ad-hoc segmentation) and store the original rule definition in a custom module Segment_Definitions__c for documentation and audit. Segments that rely on behavioral event conditions are mapped to criteria on the Behavioral_Profile__c custom module.

Solitics User Journeys define automated workflows triggered by events or segment membership, including entry conditions, branching logic, delay rules, and cross-channel steps. We export journey definitions as structured documentation with trigger events, condition logic, step sequences, and channel assignments. These do not migrate as executable automation. We deliver a written journey inventory that maps each Solitics journey to Zoho Blueprint (for process visualization and enforcement) and Zoho Workflow Rules (for field updates, task assignment, and email notifications). The customer or a Zoho partner rebuilds the logic in Deluge scripting where cross-channel orchestration is required.

Solitics Campaigns are containers for content assets, scheduling, and audience targets. We export campaign metadata, targeting rules, and performance history (open rates, click rates, send volumes). Channel-specific content (WhatsApp templates, SMS bodies, push notification copy) migrates as structured content records in Zoho Campaigns, with a note flagging that WhatsApp and SMS sending infrastructure must be re-registered in Zoho's native channels or a third-party provider post-migration.

Solitics Smart Gamification stores mission definitions, loyalty point balances, badge and achievement rules, widget configurations, and threshold conditions as platform-native objects. No common export format exists for these artifacts. We export all gamification configuration as structured documentation with a full inventory of mission rules, point values, badge names, achievement tiers, and widget types. The actual mechanics must be rebuilt by the destination team using Zoho Blueprint, workflow rules, and custom fields or a third-party loyalty app. We flag this explicitly before migration begins and include the inventory in the scoping deliverable.

Content assets — email templates, SMS message bodies, push notification copy, WhatsApp template content — are exported as structured records. Email templates migrate as Zoho Campaign email templates where supported. SMS and WhatsApp body copy migrates to a custom module Channel_Content__c so that the Zoho admin can reconstruct sending templates in Zoho's SMS and WhatsApp integrations. Localization settings, A/B test variants, and scheduling metadata are preserved in the documentation layer. Channel sending infrastructure (sender IDs, WhatsApp Business account credentials, push certificates) does not transfer and must be set up fresh in Zoho.

Solitics integrations with external systems (trading platforms, sports feeds, bonus engines, BI tools, back-office databases) are configured connections rather than data objects. They do not transfer across platforms. We document every active integration — its name, data flow direction, endpoint or credential reference, and the Solitics module it feeds — as a structured re-integration checklist for the customer's technical team. Zoho Flow and Deluge scripting are the primary tools for re-establishing these connections in the Zoho ecosystem.

Journey owners, campaign managers, and team-level access controls in Solitics export as user references. We resolve each Solitics owner by email against the Zoho destination User table. Owners without a matching Zoho User go to a reconciliation queue for the customer to provision before record import resumes. Role and profile assignments in Zoho are documented separately for the customer's admin to assign post-migration.