Migrate from Leadtrekker Lead Management to Pipedrive

Leadtrekker Lead records map directly to Pipedrive Lead records as the primary migration object. Standard fields (first_name, last_name, email, phone, status, lead_source, owner) map 1:1. The original Leadtrekker status value is preserved in a custom Pipedrive field (e.g., lt_original_status__c) so the customer's admin can re-qualify leads by status after import. Pipedrive Leads reside in the Leads Inbox until manually or automatically converted to Person, Organization, and Deal records — the conversion decision is made by the sales team post-migration, not automatically during import.

Leadtrekker stores lead source as a native property on the Lead record. This maps to a Pipedrive custom field of type dropdown or text. If the customer has defined a small fixed set of source labels (website form, campaign, referral), we create a Pipedrive dropdown custom field with those values preserved. If source labels are open-text, we create a text custom field to avoid picklist inflation in Pipedrive.

Leadtrekker stores activities as timestamped events tied to a Lead. We migrate call logs, email events, meeting records, and freeform notes to their Pipedrive equivalents. Call activities map to Pipedrive Activity with type=call and the original timestamp preserved. Email events map to Pipedrive Activity with type=email. Meeting records map to Activity with type=meeting. Notes map to Pipedrive Note records linked to the parent Lead. All activity timestamps are preserved to maintain the original engagement timeline at the destination.

Leadtrekker follow-up reminders carry a due date, owner, and description. We convert these to Pipedrive Activities of type follow_up_task with the due date, assignee (resolved via owner email mapping), and notes preserved. Reminders that have already fired or lapsed are migrated as completed activities with a completed timestamp rather than open follow-ups.

Leadtrekker user accounts are exported and mapped to Pipedrive User records by email match. We resolve every distinct owner referenced on Lead and activity records before migration. Any Leadtrekker user without a matching Pipedrive User account goes to a reconciliation queue — the customer's admin provisions the Pipedrive account before record import resumes. Passwords and session tokens do not transfer and require manual re-authentication in Pipedrive.

Leadtrekker assigns lead-level view and edit permissions to user groups. Pipedrive uses a team-based permission model where team membership controls access to Pipedrive's inbox and shared pipelines. We extract the full group membership roster, map each group to a Pipedrive Team, and populate team membership based on the Leadtrekker group assignments. Individual user permissions (admin, regular) are reconfigured manually in Pipedrive's access settings post-migration.

Leadtrekker does not publish a stable field taxonomy for custom fields in its public documentation, so every custom field requires explicit field-level discovery and mapping. We probe the Leadtrekker API for the actual custom field keys present in the customer's account, map each to a Pipedrive custom field of equivalent type (text, number, date, dropdown, checkbox), create the destination custom fields in Pipedrive before migration, then import values during the Lead import phase. Type mismatches (e.g., Leadtrekker stores a value as text that should map to a Pipedrive dropdown) are resolved during the discovery phase.

Leadtrekker stores SMS and email notification settings as platform runtime preferences, not as data records. Auto-response rules, alert thresholds, and notification-trigger conditions are platform features, not exportable data. We do not migrate notification settings. During extraction we document all notification-trigger events (e.g., when a lead is assigned, when a reminder fires) so the customer's admin has a complete list of the notification behaviors to rebuild in Pipedrive's automation rules.

Leadtrekker's round-robin and source-based lead assignment logic is a platform rule, not stored as a data record with a documented API endpoint. We extract the assignment history (which user was assigned to each lead at import time) and preserve that as the owner_id on the migrated Lead record. The routing logic itself — round-robin patterns, source-based rules, weighted distribution — cannot be migrated as code. We deliver a written inventory of the assignment rules in operation so the customer's Pipedrive admin can rebuild them using Pipedrive's Lead Assignment Rules or a third-party assignment management app.

Leadtrekker uses a status field on the Lead record (e.g., New, Contacted, Qualified, Lost) that has no enforced schema. Pipedrive Lead Status is a configurable dropdown per company account. We map Leadtrekker status values to corresponding Pipedrive Lead Status options during import, creating new Pipedrive status labels if the Leadtrekker values do not map to any standard Pipedrive option. The original Leadtrekker status is additionally preserved in the custom field lt_original_status__c for reference.

Leadtrekker is a lead-centric system and does not natively maintain a separate Company or Organization object — company information may live as address or notes fields within the Lead record. Where Leadtrekker Leads contain a company name field, we create a Pipedrive Organization record and link the Lead to it via the organization_id field. This creates a clean foundation for the customer to build Person-Organization-Deal relationships in Pipedrive after the Lead is converted.