Migrate from YetiForce CRM to Pipedrive

YetiForce Contact records map directly to Pipedrive Person objects. We map name, email, phone, address, and assigned owner fields to their Pipedrive equivalents. YetiForce's emailoptout and invalid_email flags migrate to Pipedrive's opt_out and banned flags on the Person. Owner assignment resolves by matching YetiForce user email against Pipedrive user email.

YetiForce Organization records map to Pipedrive Organization. Industry, type, website, address, and assigned owner transfer directly. Organization is created before Contact import to satisfy the Person-Organization link. The Organization name serves as the dedupe key to prevent duplicate Organizations during import.

YetiForce Lead records map to Pipedrive Lead. Lead_Source and Lead_Status from YetiForce migrate as custom fields in Pipedrive since Pipedrive's native Lead object does not expose a structured status field at the base level. Lead conversion notes transfer to Pipedrive's activity timeline on the resulting Person and Organization.

YetiForce Potentials map to Pipedrive Deals. We create one Pipedrive pipeline matching the primary YetiForce sales process before importing Deals. Potential stage names map to Pipedrive stage names via a configuration table, and weighted revenue amounts transfer to Deal value. The Potential-related Organization resolves to the Pipedrive Organization ID before Deal insert.

Each YetiForce Potential stage becomes a Pipedrive Deal stage. We configure the pipeline in Pipedrive before migration, preserving stage order and probability percentages. Closed-Won and Closed-Lost stages are mapped with their respective probabilities, and any custom stage labels (e.g., Negotiation, Proposal Sent) are carried forward as stage names.

YetiForce Projects do not have a direct Pipedrive equivalent since Pipedrive lacks a native project management module. During scoping, we determine whether Projects migrate as a Pipedrive custom object (with a schema built in the destination org) or as linked Activities with a custom project identifier field. The choice depends on whether the customer needs to query project records independently or only needs project context attached to Deals or Organizations.

YetiForce Project Tasks map to Pipedrive Tasks linked to the parent Project record. Status and priority picklist values transform via the configuration table. Parent record ID mapping requires the Project custom object to exist in Pipedrive before Task import, so Projects migrate in the phase before Tasks.

YetiForce Tickets require scoping to determine whether Pipedrive's Lead object (with a ticket-like workflow) or a custom object handles the migrated tickets. Ticket status maps to the Pipedrive Lead status or a custom Ticket status picklist depending on the chosen model. Related Contact and Organization references resolve to Pipedrive Person and Organization IDs before import.

YetiForce Products map directly to Pipedrive Products. Unit price, description, and code transfer. The vendor reference resolves by matching YetiForce vendor name to the migrated Vendor record in Pipedrive. Products are created before Deals so that Deal-Product linking (Items) is satisfied at migration time.

YetiForce Services share the same data shape as Products and migrate to Pipedrive Products with a service-type indicator in a custom field. Price per unit, description, and vendor reference transfer identically to the Product migration path.

YetiForce Vendors map to Pipedrive Organization records tagged with a vendor_type custom field to distinguish them from customer Organizations. Vendor name, website, and address transfer directly. Vendor is created before Product import so that the vendor reference on Products resolves correctly.

YetiForce Users resolve to Pipedrive Users by email match. We extract every distinct user email referenced on Contacts, Organizations, Potentials, and Tickets and map them to the destination Pipedrive User. Any YetiForce user without a matching Pipedrive User is placed in a reconciliation queue for admin provisioning before record migration begins.