Migrate from FieldEdge to Pipedrive

FieldEdge invoices have no Pipedrive equivalent — billing history requires a rebuild strategy

FieldEdge handles invoicing, payment processing, and QuickBooks sync natively. Pipedrive has no billing object — invoices cannot be stored as native records. We preserve invoice ID, total, and payment status as custom fields on the linked Deal, and attach the invoice PDF as a Deal file. Any payment reconciliation, aging reports, or outstanding-balance workflows require a third-party integration (Stripe, QuickBooks, or a dedicated billing tool) rebuilt post-migration. These integrations restore invoice tracking and ensure financial reporting continuity.

FieldEdge dispatch and scheduling data cannot map to Pipedrive's activity model

FieldEdge's core value is dispatch board, technician routing, GPS tracking, and job scheduling with time windows. Pipedrive has Activities (tasks, calls, meetings) and a calendar integration but no native dispatch, routing, or multi-technician scheduling. Dispatch schedules and route data are not migratable — we export them as Activity notes with original timestamps and technician assignment for historical reference. Any live dispatch workflows must be rebuilt using Pipedrive's Calendar app, Calendly integration, or a dedicated field-service tool.

Pipedrive API v2 token-based rate limits require batched migration

Pipedrive introduced token-based API rate limits effective December 2024. Each API token has a requests-per-minute ceiling that scales with the Pipedrive plan tier. High-volume migrations (100k+ records) require throttling and batched inserts with retry logic. We monitor rate-limit headers (X-RateLimit-Remaining, Retry-After) and implement exponential backoff to avoid 429 errors. This adds processing time but ensures no records are dropped during the bulk load phase. Our pipeline also includes automatic retry queues that requeue failed batches after the rate-limit window resets, maintaining a steady throughput.

Custom field key generation in Pipedrive is non-deterministic — mapping requires pre-creation

Pipedrive generates a 40-character hash key for each custom field at creation time. The key is not predictable from the field label. Before migrating, we create all required custom fields in Pipedrive (matching the label and field type from FieldEdge) so we can capture the generated keys and use them in the bulk API load. Skipping this step causes field-to-field links to break because the migration tool cannot resolve the destination field by label alone during the insert phase.

FieldEdge service agreements become orphaned reference data without renewal workflow

FieldEdge service agreements have plan type, coverage scope, auto-renewal flags, and renewal billing cycles. Pipedrive has no service-agreement object. We migrate agreement metadata as custom fields on the Organization record, but the renewal-trigger logic (automatically creating a renewal Deal 60 days before expiry) does not exist in Pipedrive natively. We create a renewal Deal template linked to the Organization and document the rebuild steps for Pipedrive Automation rules or a Zapier/Make scenario to handle ongoing renewals.