Migrate your RETAINUSER CRM data

Contacts are the primary record type in RETAINUSER. We map standard contact fields (name, email, phone, address) 1:1 in most migrations. Custom properties on contacts require field-level name mapping against the destination schema.

Leads are captured via Facebook Forms, WhatsApp, and manual entry. We preserve lead source, lead status, and assignment owner. Where the destination CRM has no separate Lead object, we merge Leads into Contacts and carry forward the Lead_Status as a custom Contact property.

Company records link to multiple Contacts. We preserve the contact-to-company linkage during migration by exporting the association table and reconstructing it in the destination. If the destination uses a flat contact model, we embed company data as custom fields on the Contact record.

Deals represent pipeline opportunities and carry stage, value, currency, owner, and expected close date. We map pipeline stages to the destination's equivalent stage names and flag any Deals without a linked Contact or Company as orphaned records for manual review.

RETAINUSER supports multiple pipelines with configurable stages. We extract the full pipeline configuration including stage order, stage names, and win/loss criteria, then map them to the destination's pipeline structure. Custom pipeline fields require explicit field-level mapping.

Activities include emails, calls, meetings, and notes logged against a Contact or Deal. We export activity history as chronological entries, preserving timestamps and owner attribution. Note content is migrated as text; call recordings and meeting attachments require separate file-level handling.

Email and SMS templates are stored as reusable assets. We export template bodies, subject lines, and merge field placeholders. Migration maps merge fields to the destination CRM's equivalent syntax (e.g., HubSpot tokens vs. Salesforce merge fields).

SMS and WhatsApp templates are text-based. We export the full template library and map character limits to the destination's messaging constraints. Template-to-contact associations are not preserved; templates land as standalone assets in the new system.

Workflow rules define triggers, conditions, and actions. We document the workflow logic as a JSON artifact for re-implementation in the destination CRM, as workflow engines are not directly portable across platforms. Trigger events are mapped to the destination's equivalent automation constructs.

Custom fields on Contacts, Companies, and Deals require field-level mapping. We extract the full custom field schema including field type, picklist values, and default values. Picklist values are mapped explicitly to avoid silent data loss when the destination uses different value labels.

File attachments stored against Contacts, Companies, or Deals are exported as individual files and re-uploaded to the destination. We handle attachments in a separate file batch after record migration to avoid timeout during the primary data load. File-to-record associations are maintained via a mapping manifest.

User records carry name, email, role, and team assignment. We map user records to the destination's user schema and flag any inactive users who should be archived rather than migrated as active seats.