Migrate from Pawa to HighLevel

Pawa Contact records (name, phone, email, and custom fields) map to GoHighLevel Contact. Standard fields (first_name, last_name, email, phone, address) migrate directly. Custom fields on Pawa Contacts require pre-creation of GoHighLevel custom fields during the schema phase. We discover all Pawa Contact field names and types via API at scoping time, build a field map, and apply it before the first record is written. GoHighLevel's Contact object does not have a dedicated Phone2 or Mobile field; we use the default phone field and note any secondary phone placement in the field map.

Pawa Company records (name, address, and linked contacts) map to GoHighLevel Contact records with Contact Type set to Company. The Company-to-Contact relationship from Pawa is preserved by linking each child Contact record to the parent Company Contact using GoHighLevel's address fields and company association. We resolve the parent record by company name before writing child contact records to satisfy the lookup.

Pawa Deal records (value, stage, and linked contacts) map to GoHighLevel Opportunity. Deal value maps to Opportunity Value; stage name maps to the corresponding GoHighLevel Pipeline Stage. GoHighLevel uses a Pipeline and Stage model that is more customizable than Pawa's basic stage structure. We create the target Pipeline in GoHighLevel before migration, define Stage entries matching Pawa's stage names, and apply the mapping at import time.

Pawa pipeline stages map to GoHighLevel Pipeline Stage entries. We configure GoHighLevel Pipelines and Stages during the schema design phase, preserving stage order and naming conventions from Pawa. GoHighLevel allows probability percentages per stage; we set these to defaults and flag for customer review if specific probability values are business-critical.

Pawa custom fields on Contacts and Companies are discovered via API at scoping time. Each custom field is evaluated by type (text, number, date, picklist, checkbox) and mapped to the equivalent GoHighLevel custom field type. We pre-create GoHighLevel custom fields (under Settings > Custom Fields) before any records are imported. Pawa field-record structured data that does not fit a flat custom field on Contact or Opportunity is flagged as requiring a GoHighLevel custom object or a note field, and the customer decides the approach during scoping.

Pawa Tags stored as flat string arrays on Contact and Company records map to GoHighLevel Tags. We extract all unique tag values from the source, create them in GoHighLevel (if they do not already exist), and associate them with the target Contact or Opportunity records during import. Note that GoHighLevel tags are labels that do not carry inheritance or hierarchy logic; if Pawa tags use a hierarchical or nested structure, we flatten them to a flat label list and document the flattening rule.

Pawa User records (name, email, role) are exported and mapped to GoHighLevel User records. We resolve Pawa Owner references on Contact, Company, and Deal records to GoHighLevel User records by email match. Any Pawa User without a matching GoHighLevel User is placed in a reconciliation queue for the customer's admin to provision. Inactive Pawa users are flagged and excluded unless the customer requests otherwise.

Pawa's API does not expose file attachments in a documented endpoint. We do not migrate attachments. Before migration, we enumerate all attachment-bearing records in the source account and provide a list so the customer can manually download and re-upload files post-migration to GoHighLevel's native file attachment model. Attachment-bearing records are excluded from the record count used to scope migration timelines and pricing.