Migrate from Pawa to Twenty CRM

Pawa Contact records (name, phone, email, custom fields) map directly to Twenty's Person object. Email and phone serve as dedupe keys during import. Custom fields are discovered at scoping time via live API enumeration and mapped to equivalent Twenty field types (text, number, date, picklist) before any records are written. Tags on Pawa Contacts migrate as a label field in Twenty's Person record.

Pawa Company records map to Twenty's Company object. The company name, address, and linked contact relationships are preserved. We resolve the Company-to-Person relationship by exporting Pawa's linked contact IDs alongside Company records, then cross-referencing those IDs to set the primary contact on the Twenty Company record during import.

Pawa Deal records (value, stage, linked contacts) map to Twenty's Opportunity object. Deal value migrates to the Amount field; stage maps to Twenty's Pipeline Stage with a mapping table applied at import. The linked contact association migrates as the Opportunity's PersonId pointing to the resolved Twenty Person record.

Where Pawa supports deal stages, we map the named stages to Twenty Pipeline Stages, preserving stage order. If Pawa's stage set differs from Twenty's default pipeline, we create a custom pipeline in Twenty and configure the stage values to match Pawa's ordering before migration.

Pawa custom fields on Contacts and Companies are discovered via live API at scoping. Each custom field is typed (text, number, date, single-select, multi-select) and mapped to the equivalent Twenty field definition created via Twenty's field management before import. Multi-select fields from Pawa map to Twenty multi-select picklists.

Pawa User records (name, email, role) map to Twenty's WorkspaceMember object. We resolve by email match against the destination Twenty workspace. Inactive Pawa users are flagged and excluded unless the customer requests otherwise. Role mappings are documented for the customer's admin to assign appropriate Twenty permissions post-migration.

Pawa stores tags as flat string arrays on records. Tags migrate as a text label field on the equivalent Twenty record (Person or Company). If tags represent a taxonomy the customer wants to preserve as a structured filter, we discuss creating a custom picklist field in Twenty rather than a free-text label field during scoping.

Pawa's API does not expose file attachments. We flag every record that carries an attachment, listing the record ID and attachment count so the customer can download files manually before migration and re-upload them to the corresponding Twenty record after import. Attachments are excluded from the migration scope and from record-count-based pricing.

Pawa's field-record structure is enumerated during API scoping. If field records represent structured data (site visits, equipment inspections, survey data) that cannot map to standard Person, Company, or Opportunity objects, we create a custom object in Twenty via the /metadata API and define the lookup relationships to Person or Company before import.

Pawa record creation and update timestamps migrate to Twenty's createdAt and updatedAt fields. We preserve the original creation date on migrated records so historical ordering is maintained in Twenty's activity and record timelines.