Migrate from Symplify Communication to HubSpot

Symplify contacts map 1:1 to HubSpot contacts. Email is the primary key for deduplication. HubSpot's lifecycle_stage property does not exist in Symplify — it is added as a custom property (Lifecycle_Stage__c) and set to a default value (e.g., 'Contact') for all migrated records unless a behavioral signal in Symplify justifies a different stage.

Email serves as the canonical identifier across both systems, ensuring accurate record matching during migration. HubSpot's Contacts API uses email for deduplication on import — when a contact with a matching email address already exists in HubSpot, the system updates the existing record rather than creating a duplicate, maintaining data integrity and preventing contact proliferation in the CRM.

Symplify unsubscribe records, exported as OPTOUTS via the statistics API, map directly to HubSpot's email opt-out property. To preserve a complete audit trail, each contact's unsubscribe timestamp is stored as a custom datetime field (Symplify_Unsubscribe_Date__c) on the HubSpot contact record, enabling your team to demonstrate consent history during compliance reviews or data governance audits.

Symplify segments are audience lists with filter logic on contact properties and behavioral events. They map to HubSpot static lists (manually maintained) or active lists (dynamically updated by property changes). The filter logic itself cannot migrate — FlitStack exports the segment membership list (contact IDs) and your HubSpot admin rebuilds the active list filter criteria.

Symplify campaigns become HubSpot campaigns as the parent marketing object for organizing outreach efforts. Campaign-level statistics including total sends, opens, clicks, and bounces are mapped to HubSpot contact engagement properties on each recipient's contact record and can optionally be associated with HubSpot campaign records, enabling your team to leverage HubSpot's built-in campaign reporting dashboards for performance visibility.

Symplify's per-campaign engagement data (OPENS, CLICKS, BOUNCES export values) maps to HubSpot contact properties: last email open date, last email click date, bounce status, and custom engagement count fields. The association between campaign and contact is preserved so HubSpot reporting can reconstruct per-campaign contact history.

Symplify DataDocs are JSON documents stored under a document type (e.g., 'Purchase_History', 'Booking_Data') linked to a contact by originalId. Each unique document type in Symplify becomes a HubSpot custom object. The DataDoc JSON is stored as a custom long-text field (JSON_Data__c) and the Symplify originalId is stored as an external ID (Symplify_Original_ID__c) on the custom object for relationship traceability back to the HubSpot contact.

originalId is the Symplify contact identifier linking a DataDoc to the contact record. We store it as an external ID on the HubSpot custom object record and also stamp it on the HubSpot contact as Symplify_Contact_ID__c so that the many-to-one relationship between DataDocs and contacts is queryable in HubSpot reporting.

Symplify does not have a per-contact owner model. HubSpot requires an owner (user) on every contact. We assign all migrated contacts to a designated HubSpot admin user as a fallback owner, and your team assigns individual owners post-migration. Owner assignment by email match is available if Symplify stores a user email on the contact.

HubSpot automatically sets the CreatedDate field to the migration timestamp when records are created via API. To preserve the original audience history, the Symplify contact creation timestamp is stored as a custom datetime field (Original_Create_Date__c) on each contact. This maintains audit continuity and ensures your team can report on contact tenure and historical acquisition patterns using the original creation dates.

Symplify's internal contact ID is preserved as a custom text field (Source_System_ID__c) on the HubSpot contact record. This identifier enables delta-run deduplication by allowing FlitStack AI to skip contacts that have already been migrated when re-running the migration against an existing HubSpot dataset, and provides a traceable link back to the original Symplify record for reconciliation and audit purposes.

The timestamp of the most recent campaign send to each contact is captured and stored as a custom datetime property (Symplify_Last_Campaign_Send__c) on the HubSpot contact record. This field integrates with HubSpot's active list filter logic for segmentation based on recency and supports workflow enrollment triggers that depend on campaign engagement timing to automate follow-up sequences.

Symplify stores channel-level subscription preferences including email, SMS, push, and voice opt-in status on contact records. Each channel's preference maps to the corresponding contact property in HubSpot — SMS opt-in maps to sms_subscribed, push opt-in requires a custom boolean field since HubSpot has no native equivalent. Values are mapped on a one-to-one basis, and any unspecified status defaults to not opted in unless the source data explicitly indicates subscription activity.

Symplify campaigns are tagged by channel (email, SMS, push, voice, etc.). The channel type is stored as a custom property on the HubSpot campaign record and also surfaced on the contact's engagement properties so that HubSpot reporting can filter by channel.

Symplify journey flows define multi-step, event-triggered automation across channels. HubSpot workflows provide equivalent trigger-and-action logic, but the flows do not migrate automatically. FlitStack AI exports your Symplify journey definitions as a structured document (JSON export of flow logic) that your HubSpot admin can use as a rebuild reference.

Symplify's built-in A/B testing for campaigns and content does not export as reusable test configurations. HubSpot's email tool includes A/B testing for subject lines, send times, and content — but the Symplify test history and winning variants are not transferable. We preserve A/B test results as campaign notes for your team to reference during rebuild.