Migrate from Ayna to Twenty CRM

Ayna Contact records map to Twenty's Person object, which is the standard CRM contact representation in Twenty's data model. We extract name, email, phone, and company association fields from Ayna, map them to Twenty's name, email, and phone fields, and resolve the company association to a Twenty Company record by domain or explicit company link. Custom properties on Ayna Contacts (brand-specific attributes, source channel tags) migrate to custom fields on the Person object, which we pre-create via Twenty's settings UI or API before import.

Ayna Company records map to Twenty's Company object. Company name, domain, and industry fields migrate directly. Ayna's brand protection metadata (ownership details, monitoring status) maps to custom fields on the Twenty Company record. We use the company domain as the dedupe key during import to prevent duplicate records. Company is created before Person import so that the company lookup is satisfied at Person insert time.

Ayna Channels represent communication and social platforms connected to a brand. Twenty does not have a native Channel object, so we map channels to either a Channel custom object (pre-created via Twenty's /metadata API) or as tags on the associated Company record using Twenty's Topics. The migration strategy is chosen during scoping based on whether the team needs channel-level pipeline tracking or just association metadata. We flag active versus archived channels at cutover to prevent duplicate import of deprecated channels.

Social account connections for brand monitoring require re-authentication in Twenty because OAuth tokens do not transfer across platforms. We extract the social platform name, account handle, and last-sync timestamp from Ayna as fields in a SocialAccount custom object in Twenty. We document the current OAuth connections during discovery so that the customer's admin can re-link social accounts post-migration in Twenty's integration settings or via a third-party social management tool.

Ayna Website Domains tied to website synchronization and brand protection migrate to Twenty Company records via the Website field and a custom domain_verification_status field. Domain ownership metadata (registrar, expiration, ownership proof status) becomes custom fields on the associated Company. Multiple domains per company are supported via the Company custom field set or a Domain custom object created via Twenty's /metadata API.

Ayna custom fields on contacts and companies use Ayna-specific naming conventions that do not have native equivalents in Twenty. We extract the field schema during discovery (field name, data type, picklist values), create matching custom fields in Twenty via the settings UI or API, and map the data values during import. Text fields map to Twenty text fields, picklist fields map to Twenty select fields, and date fields map to Twenty date fields. We flag any unsupported data types (e.g., Ayna-specific brand protection enums with no Twenty equivalent) for manual value mapping.

Ayna User records (email, name, role) map to Twenty WorkspaceMember records. We resolve users by email match. Any Ayna Owner referenced on a Contact, Company, or Channel record that does not have a matching WorkspaceMember in Twenty goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Ayna users are mapped to inactive WorkspaceMembers in Twenty with a flag for admin review.

Attachments to Ayna brand protection records (screenshots, legal documents, brand assets) are exported as file references and metadata. Actual file migration depends on whether Twenty is deployed as self-hosted (where file storage is on the customer's PostgreSQL or S3-compatible storage) or cloud-hosted (Twenty's managed storage). We export file URLs and attach them as external URL fields on the relevant records in Twenty, or migrate files directly if the export includes binary blobs and the destination supports direct file upload.

Ayna activity records (if available via export) map to Twenty Task or Event objects. Task is used for action items, reminders, and call logs; Event is used for scheduled meetings. We preserve the original timestamp as ActivityDate for timeline ordering. If Ayna exports engagement data in a structured format, we map it to Twenty's standard activity objects; if not, we flag activity as requiring manual re-entry or reconstruction from source documents.

Ayna's brand protection and website synchronization workflows are central to the platform but are not exposed via standard export. We document the workflow structure (trigger conditions, monitoring frequency, alert actions, escalation paths) during discovery and deliver a written inventory for manual reconfiguration in Twenty. Twenty's workflow builder or custom code-based automation can recreate the logic, but this is outside data migration scope and requires the customer's admin to rebuild.