Migrate from Ayna to Microsoft Dynamics 365 Sales

Ayna Contact records map to Microsoft Microsoft Dynamics 365 Sales Contact. The Contact's name, email, phone, and company association fields map directly to the corresponding Dynamics Contact fields. Ayna brand-specific contact properties (such as brand protection status, channel attribution, or custom brand fields) map to custom fields on Contact that we create during schema setup, capturing the field schema from Ayna during discovery. OwnerId is resolved by matching the Ayna owner's email to a Dynamics User.

Ayna Company records represent brands or businesses being protected and map to Microsoft Microsoft Dynamics 365 Sales Account. The Company domain and brand metadata migrate to the Account's Website and custom fields. Account is created before Contact import so that the parent CustomerId (Account) lookup relationship is satisfied at Contact insert time. We use the Ayna Company domain as the dedupe key during Account import to prevent duplicate Account records.

Ayna Channels represent communication and social platforms connected to the brand. Microsoft Dynamics 365 Sales does not have a native Channels equivalent, so we map Channels in two ways: active social channels migrate as Marketing List Membership records linking to the Account, and the channel configuration (URL, platform type, connection status) is documented as a Note on the Account with a custom field for channel type. Archived Channels are flagged separately for the customer to assess before import to prevent importing deprecated channel data.

Ayna Website Domains tied to website synchronization and brand protection migrate as Notes attached to the Account, with a custom domain field (domain_url__c) capturing the registered domain and ownership metadata. Microsoft Dynamics 365 Sales has no native domain tracking object; the custom field approach preserves the domain reference for brand protection audit purposes without forcing it into a non-relevant CRM field.

Ayna custom fields on Contacts and Companies may use Ayna-specific naming conventions for brand protection attributes. We extract the field schema during discovery, map each custom property to a typed Dynamics custom field (Text, Integer, Decimal, Picklist, Boolean) on the appropriate object, and deploy the schema via Dynamics 365 solutions before migration begins. Data type mismatches are resolved during the transform phase before insert.

Ayna User records including email, name, and role assignment are exported. We map source user IDs to Dynamics 365 User records by email match. Any Ayna User without a matching Dynamics User goes to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references on Contact, Account, and any custom objects cannot be inserted until the User mapping is resolved.

Ayna Social Account connections for brand monitoring require re-authentication in Microsoft Dynamics 365 Sales because social account OAuth tokens and session data are platform-specific and cannot be exported. We document the current social account connections during discovery (platform type, account handle or URL, connection status) and provide a re-linkage checklist for the customer's admin to complete after migration. This is not a data migration gap; it is a platform capability difference.

Attachments to brand protection records may include screenshots, legal documents, or brand assets. We export file references and document the attachment list during discovery. If the customer's Microsoft Dynamics 365 Sales environment is integrated with Microsoft SharePoint (a standard Microsoft 365 integration), we migrate file content to the associated SharePoint Document Library and link via Dynamics ContentDocumentLink. If SharePoint is not configured, we deliver the file inventory with locations for manual upload.