Migrate from Pawa to Salesforce Sales Cloud

Pawa Contact records (name, phone, email, custom fields) map to Salesforce Contact. We map standard fields 1:1 where field names match. Custom fields on Pawa Contacts are discovered via API at scoping time; we create matching custom fields in Salesforce and flag any type mismatches (e.g., Pawa text fields that should become picklists or multi-select fields in Salesforce) for explicit customer review before import. The Pawa Contact-to-Company relationship is preserved as an AccountId lookup on the Contact record.

Pawa Company records map to Salesforce Account. The Company name becomes Account Name, and any address fields map to the standard Account address fields (BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry). We use Company ID as an External ID to enable upsert semantics so that if the same Company appears in multiple Pawa exports, it is merged rather than duplicated in Salesforce.

Pawa stores a Company ID on each Contact record. We resolve the Company ID to the Salesforce Account record created in the Account import phase, then write the resolved AccountId onto each Contact record during Contact import. This is a two-phase operation: Accounts must import first so that Contact import can reference them. Any Pawa Contact with an unresolvable Company ID is flagged to a reconciliation queue for manual review.

Pawa Deal records map to Salesforce Opportunity. The deal value maps to Amount, the linked Contact ID maps to the Contact's Salesforce ID (resolved via the Contact mapping), and the deal stage maps to a Salesforce StageName that we configure as part of the destination schema setup. If Pawa supports multiple deal pipelines, each pipeline maps to a Salesforce Opportunity Record Type with a corresponding Sales Process to keep stage values scoped per line of business.

Pawa pipeline stages are discovered via API and mapped to Salesforce StageName values in a Sales Process that we configure before migration. Each Pawa stage gets a corresponding Salesforce stage with an explicit probability percentage. If Pawa stages include custom attributes (e.g., time-in-stage or weighted value), we create custom fields on Opportunity to carry those values.

Pawa custom fields on Contacts and Companies are discovered via API during the live schema validation phase. We create matching Salesforce custom fields (with the __c suffix per Salesforce naming convention), assign the correct field type (Text, Picklist, Checkbox, Date, Number), and include the custom field in the field map delivered to the customer before import. Any Pawa custom fields that use field types not directly supported by Salesforce (e.g., a Pawa-specific geolocation type) are flagged with a transformation recommendation.

Pawa stores tags as flat string arrays on records. Tags do not have a native Salesforce equivalent; we map them to custom multi-select picklist fields on the relevant object (Contact, Account, or Opportunity). The customer chooses the target field name and which objects receive tags during scoping. If the number of unique tag values exceeds Salesforce's picklist value limit, we recommend using Salesforce Topics or a custom junction object instead.

Pawa User records (name, email, role) map to Salesforce User. We resolve by email match against the destination org's User table. Inactive Pawa users are flagged and excluded from the active user migration unless the customer requests otherwise. Any Pawa User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Pawa user roles are mapped to Salesforce User Roles during schema configuration. We create the Salesforce role hierarchy to mirror the Pawa role structure as closely as possible, or we document the delta for the customer's admin to finalize post-migration. Role hierarchy affects opportunity sharing rules and reporting visibility in Salesforce.

If Pawa exposes task records via API, they map to Salesforce Task with Status, Priority, Subject, and ActivityDate preserved. Task assignment migrates by resolving the Pawa user reference to the Salesforce OwnerId via the User mapping. Tasks are among the last objects imported because they typically reference both Contacts and Accounts.

If Pawa exposes note records via API, they map to Salesforce Note linked via ContentDocumentLink to the parent record (Contact, Account, or Opportunity). Note body migrates as rich text. We validate note content for any Salesforce validation rule violations (e.g., field-length limits) before insert and flag any violations to the customer.

Pawa's API does not expose attachment files. We do not migrate attachments as part of the data migration. We flag all records that have attachments in Pawa and document the record IDs, object types, and attachment file names in the migration plan. The customer downloads these files manually before the migration window and re-uploads them post-migration to Salesforce ContentDocument records. Attachments are excluded from the record count used to scope migration timelines and pricing.