Migrate from Pawa to Pipedrive

Pawa Contact records (name, phone, email, custom fields) map directly to Pipedrive Person. We resolve the email field as the dedupe key during import to prevent duplicate Persons. Custom fields discovered at scoping are created in Pipedrive as typed fields before import and mapped in the import field mapping step. Inactive Pawa Contacts are flagged and excluded unless the customer requests otherwise.

Pawa Company records (name, address, linked contacts) map to Pipedrive Organization. The Organization is created before any Person import so that the Person-to-Organization link is satisfied at the moment of Person insert. If the Pawa Company has multiple linked Contacts, we resolve the relationship by matching Contact records against the exported Company ID before writing to Pipedrive.

Pawa Deal records (value, stage, linked contacts) map to Pipedrive Deal. The Deal-to-Person relationship is resolved by cross-referencing Pawa contact IDs from the exported record set before writing to Pipedrive. If the Pawa Deal references a Company, we resolve the Organization ID at migration time. Pipedrive's loose Deal model (a Deal can exist without a Person link) is preserved from the source; we note that linking Deals to Persons or Organizations improves Pipedrive reporting depth.

Where Pawa supports pipeline stages on Deals, we map stage names and preserve order. Pipedrive stages carry a probability percentage that we set to match Pawa's stage order if present, or to Pipedrive defaults (won stages at 100%, early stages at 10-20%) if Pawa stage probabilities are not available. If Pawa has multiple pipelines, we configure multiple Pipedrive pipelines or a single pipeline with multiple stage groups.

Pawa custom fields on Contacts and Companies are discovered via API at scoping time. We create equivalent typed custom fields in Pipedrive (text, number, date, dropdown, checkbox, etc.) before migration, then map source field values to destination field values during the import transform. Dropdown fields require value-level mapping if Pawa and Pipedrive use different option labels for the same concept.

Pawa tags stored as flat string arrays on records map to Pipedrive Labels. Labels in Pipedrive are assigned to Persons, Organizations, and Deals and can be searched and filtered in the same way. We note that Pipedrive Labels are not hierarchical (no parent-child inheritance) which matches Pawa's flat tag model. The customer reviews label taxonomy post-migration to remove duplicates.

Pawa User records (name, email, role) are exported and mapped to Pipedrive User records by email match. The migration user's Pipedrive account must be set up before migration begins; all records default to the migration user if Owner resolution fails. Inactive Pawa users are flagged and excluded unless the customer requests otherwise.

Pawa's API does not expose file attachments in any publicly documented endpoint. We do not migrate attachments. We list all attachment-bearing records in the migration plan so the customer can manually download and re-upload them post-migration. Attachments are excluded from the record count used to scope migration timelines and pricing.

Pawa's field records are structured data collected in offline environments. We assess field record schema during scoping. If field records represent structured observations linked to Contacts or Companies, they migrate as Pipedrive Notes or custom Activity fields. If field records represent freeform check-ins, they migrate as Note records attached to the relevant Person or Organization. The customer chooses the representation during scoping.

If Pawa exposes activity records via API (call logs, completed tasks, meeting records), we map them to Pipedrive Activities. Pipedrive Activities include Call, Task, and Meeting subtypes. Activity assignment resolves by matching the owner email to the Pipedrive User table. Activities without a resolvable owner are assigned to the migration user and flagged for manual reassignment.