Migrate from Ayna to Salesforce Sales Cloud

Ayna Contacts with brand qualification status (active brand relationship) map to Salesforce Contact attached to an Account. Contacts representing prospects without a brand association map to Salesforce Lead. We compute the split at migration time using Ayna's contact_status and brand_association properties, preserving the original Ayna contact status in a custom field ayna_contact_status__c on both Lead and Contact for audit. Owner assignment migrates by resolving ayna_owner_id to Salesforce OwnerId.

Ayna Company records representing brands or businesses being protected map directly to Salesforce Account. The Company domain becomes the Account Website field, and Company Industry maps to Account Industry. We use Company name as the dedupe key during import. Account is created before any Contact import so that the AccountId Lookup relationship is satisfied at Contact insert.

Ayna Channels representing communication and social platform connections migrate to a Salesforce custom object Channel__c with fields for platform_name, account_handle, connection_status, and active_flag. We flag active versus archived channels at cutover to prevent duplicate import of archived connections. Social account re-authentication requirements are documented for manual re-linkage post-migration.

Ayna Social Account connections for brand monitoring migrate to a custom object SocialAccount__c linked to Channel__c and Account. We preserve the original social platform handle, connection URL, and last_verified_date. Re-authentication with OAuth tokens does not transfer; we document which accounts require re-linkage in the destination platform.

Ayna Website Domain records tied to website synchronization and brand protection migrate to a custom object Domain__c linked to Account. Domain ownership metadata (registrar, registration_date, expiration_date) transfers to custom fields on Domain__c. We map domain_status (active, expired, at_risk) to a Domain__c status picklist.

Ayna custom fields on contacts may use Ayna-specific naming conventions that require schema discovery during the planning phase. We extract the field schema (field name, data type, required/optional) from the Ayna export, map each to a Salesforce custom field on Contact with a matching data type, and preserve the original Ayna field name as a help text or custom label for admin reference.

Ayna custom fields on Company records (brand-specific attributes like brand_tier, protection_status, renewal_date) migrate to Salesforce custom fields on Account. We handle picklist mapping for Ayna enumerated values to Salesforce picklist fields and flag any date or currency format differences that require transformation before import.

Ayna User records including email, name, and role assignment export directly. We resolve users by email match against the Salesforce destination org's User table. Any Ayna User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Role assignment maps to UserRoleId if the destination org has roles configured.

Attachments to brand protection records (screenshots, legal documents, brand assets) are exported as file references from Ayna. We transfer the file metadata (filename, file_type, created_date, associated record) and document which ContentDocument records require the actual file blob to be uploaded separately via Salesforce ContentVersion. The customer uploads binary files post-migration or uses a file migration tool for bulk attachment transfer.

Ayna's brand protection records (infringement reports, monitoring alerts, takedown requests) have no direct Salesforce equivalent. We map these to a custom object BrandProtection__c with fields for report_type, status, platform_affected, and created_date, linked to Account for the affected brand. The customer chooses this mapping during scoping based on whether Service Cloud is in scope.

Ayna's association between Contacts and Companies (brands) maps to the Salesforce Contact's AccountId field when the relationship is 1:1. For multi-brand contact associations, we create ContactAccountRelation records or custom junction object BrandContactAssociation__c to preserve the full relationship graph from Ayna.

If Ayna exposes engagement history through its export (call logs, communication records, website monitoring events), we map these to Salesforce Task and Event objects. Calls map to Task with TaskSubtype=Call; monitoring events map to Task with a custom TaskType picklist. We preserve the original timestamp in ActivityDate for timeline ordering. If Ayna does not expose activity history via export, we document the gap in the handoff report.