Migrate from Xtremepush to Zoho CRM

Xtremepush user profiles map to Zoho CRM Contacts. If the Xtremepush account includes unconverted prospect records, those map to Zoho CRM Leads. We store Xtremepush profile ID in a custom field xp_profile_id__c on Contact for audit and reconciliation. Standard profile fields (email, phone, name, device OS) map to Contact standard fields; Xtremepush custom attributes map to Zoho CRM custom fields that we pre-create in the destination before migration.

Xtremepush device tokens (APNS and Firebase GCM) have no native destination in Zoho CRM because Zoho does not include push notification infrastructure. We export tokens to a custom Device Tokens module with fields for token string, OS type (iOS/Android), token type (APNS/FCM), last_active_date, and associated Contact lookup. The customer uses this registry to re-register tokens with their chosen push provider (OneSignal, Firebase, Airship) post-migration. We document the export schema in the handoff checklist.

Xtremepush key-value attributes migrate to Zoho CRM custom fields on Contact. We match attribute data types to Zoho field types: text attributes to single-line or multi-line text, numeric attributes to number or currency fields, date attributes to date fields. Tags migrate to multi-select picklist fields on Contact (for behavioral tags) or to a custom Tags module (for segment classification tags). Tags with more than 100 distinct values require admin approval of picklist range in Zoho CRM paid editions.

Xtremepush consent records (preference type, status, last-updated timestamp, consent source) migrate to custom fields on Contact: xp_consent_marketing__c (checkbox), xp_consent_date__c (date), xp_consent_source__c (picklist: manual/SDK/import), and xp_legitimate_interest__c (checkbox). We flag records where consent source is 'import' as potentially requiring re-collection in high-compliance industries (iGaming, financial services, healthcare-adjacent) per the consent audit recommendation.

Xtremepush campaign metadata (name, channel, schedule, trigger conditions, content) migrates to a custom Campaign History module linked to Contact. Each campaign record includes campaign_name__c, channel__c (push/SMS/email/web), status__c, scheduled_date__c, and content_body__c. Automated journey definitions (trigger logic, delay steps, branching rules) do not migrate; we export them as a JSON specification and deliver a written journey inventory for the customer's admin to evaluate for rebuild in Zoho Workflow Rules or a dedicated journey tool.

Xtremepush audience segments (defined by attribute, event, and tag rules) migrate to a custom Segment Registry module with fields for segment_name__c, definition_rule__c (text description of the Xtremepush rule syntax), member_count__c (snapshot at migration time), and associated_contact_lookup__c. We translate the Xtremepush rule-building syntax into human-readable descriptions because Zoho does not have an equivalent segment builder; the customer's admin uses these descriptions to recreate segments in Zoho filters and custom views.

Xtremepush in-app and cross-channel behavioral events (event type, timestamp, associated user/device) migrate to a custom Event History module linked to Contact. Each event record includes event_type__c, event_timestamp__c, device_id__c, and any event property fields stored as custom attributes. Volume-based event exports require chunking (we process in batches of 10,000 records); we map event type names directly and preserve timestamps for timeline ordering. Event history migration is optional and scoped based on the customer's reporting requirements; skipping event history reduces migration scope significantly.

Xtremepush loyalty mechanics (points balance, tier assignment, earned badges, gamification achievements) are stored as profile attributes and migrate as part of the profile. We also create a dedicated Loyalty State Snapshot module with fields for points_balance__c, current_tier__c, tier_earned_date__c, and badge_count__c for each Contact. The gamification rule engine (triggers, rewards thresholds, achievement logic) is not exposed via export and is documented separately in the handoff inventory; the customer's admin rebuilds gamification mechanics in Zoho or a dedicated loyalty platform.

Xtremepush geofence and iBeacon location metadata (coordinates, radius, venue UUID, beacon major/minor values) migrates to a custom Location Registry module. Each location record includes location_name__c, location_type__c (geofence/iBeacon), latitude__c, longitude__c, radius_meters__c, beacon_uuid__c, and associated_venue__c. Live location permission state does not migrate because it is device-level; users must re-opt into location tracking post-migration. We document location re-activation as a post-migration step in the customer handoff checklist.

Xtremepush SFTP and email-based automated export schedules are documented in the handoff package as a registry of schedule_name__c, frequency__c (hourly/daily/weekly/monthly), credential_path__c, and exported_schema__c. We do not re-create export schedules in Zoho because Zoho does not have an equivalent outbound SFTP export feature; instead, we document the Xtremepush export configuration so the customer can configure Zoho's Zoho Analytics or third-party ETL tools to consume the same schema if the data pipeline continues.