Migrate from MotionOps to Pipedrive

Jobs and time entries have no Pipedrive native equivalent

MotionOps models service delivery as Jobs with structured work orders and time entries — a two-level entity hierarchy that Pipedrive does not support. Pipedrive Deals hold a single monetary value and optional Notes, but there is no native work order or time-entry entity. FlitStack transcribes work order line items as formatted Notes attached to the corresponding Deal and stores total hours as a custom numeric field. Individual time entries are transcribed as Pipedrive Activities. This preserves the data for reference but requires your team to adopt Pipedrive's activity-based model rather than the structured job model used in MotionOps. Reviewers on G2 have flagged that Pipedrive 'lacks depth for service operations' — this limitation is inherent to Pipedrive's schema and is disclosed honestly before migration.

Multi-location customers collapse to a single Organization address

MotionOps customers can have multiple service locations, each with its own address and property details. Pipedrive Organization holds exactly one address — a fundamental structural constraint of Pipedrive's data model. FlitStack maps the primary service location address to the Organization address field and stores the full location list (name, address, property notes) as a custom text field on the Person record. If your business relies on tracking which work was performed at which specific location within a single customer account, Pipedrive's single-address constraint will require a manual workaround — most commonly a custom field or location-based tagging approach that your Pipedrive admin configures post-migration.

Pipedrive custom fields use hash-based API keys — mapping validation is non-obvious

When FlitStack creates custom fields in Pipedrive via the API, Pipedrive assigns each field a 40-character alphanumeric hash as its API key (the key parameter, not the human-readable name). Subsequent API calls — including the migration load — must reference this hash, not the field label. This is a documented Pipedrive behavior: 'All custom fields are referenced as randomly generated 40-character hashes in our API.' We capture and store each hash at field-creation time and use it in all downstream field-mapping calls. Your team will see the human-readable field name in the Pipedrive UI, but API integrations and any Pipedrive automations referencing those fields must use the hash key.

Pipedrive API rate limits require staged migration pacing

Pipedrive enforces token-based daily limits (10,000 POST/PUT requests per API token per day) and burst limits (20–120 requests per 2-second window depending on plan tier). FlitStack implements request throttling across a staggered schedule — no single token saturates the daily budget. We monitor the x-daily-requests-left response header during migration and pause writes when the daily budget falls below a safe threshold. If your MotionOps dataset exceeds approximately 50,000 records and your Pipedrive plan is Lite or Advanced, the migration will span two calendar days to respect rate limit resets at midnight UTC. This is handled transparently by FlitStack and disclosed in the migration plan before execution begins.

Work order structure flattens into Pipedrive Notes — line-item detail becomes text

MotionOps work orders carry structured line-item detail: service description, quantity, unit price, tax, and line total per item. Pipedrive Notes are plain-text blobs — they preserve the content but lose the structured row-column model. FlitStack transcribes work order line items into a formatted, readable Pipedrive Note attached to the Deal, including all item detail in a table-like text layout. However, Pipedrive cannot perform calculations on this data, and reports cannot slice by line-item fields. If your team relies on structured work order reporting (materials vs. labor split, per-item margins), those reports must be rebuilt in Pipedrive using custom fields or exported to a BI tool. This is a fundamental schema limitation, not a FlitStack handling gap.