Migrate from Pipedrive to Relm

Why move a Pipedrive account to Relm

Pipedrive is a genuinely good sales CRM. Its pipeline view is one of the clearest in the industry, activities keep reps honest about follow-ups, and if humans are the ones working your deals there is little reason to leave. This guide is not about Pipedrive being bad - it is about the operator changing.

The friction starts when the operator is an LLM instead of a rep. Pipedrive's interface is built for a person: numeric IDs like 1042 that reveal nothing about what they point to, custom fields that surface in the API as 40-character hash keys, stages you address by stage_id after a separate lookup. An agent can work with all of that, but it works against the grain. Relm inverts the priority: the REST API and the native MCP server are the product, with prefixed IDs (con_, cmp_, deal_, act_), a live GET /v1/schema the agent reads before writing, and errors that tell the model how to fix its own call. The full argument is in What is a CRM for LLMs?

The practical upshot for migration day: because Relm is built to be driven by an agent, the migration itself is a job you can hand to one. You do not map columns in a wizard. You give Claude - or any MCP client or function-calling agent - the export and a key, and it does the read-map-write loop end to end.

Step 1 - get your data out of Pipedrive

Two clean paths, both agent-friendly:

• CSV export. Pipedrive lets you export each object's list view - deals, persons (contacts), organizations, activities, notes - to CSV or Excel. Export all five and you have the whole account as flat files the agent can read directly.
• The Pipedrive API. If you would rather skip files, the agent can pull records straight from Pipedrive's REST API with your API token, paging through persons, organizations, deals, activities and notes. Pipedrive's pipelines and stages endpoints return your exact pipeline structure, and the dealFields / personFields / organizationFields endpoints translate custom-field hash keys into human names.

Either way, grab the custom-field definitions too - the hash-to-name mapping is what lets the agent give your fields readable keys on the Relm side.

Step 2 - the field mapping

Pipedrive's object model maps onto Relm's almost one to one. This is the table your agent will effectively derive on its own from GET /v1/schema, written out so you can sanity-check it:

Pipedrive	Relm	Notes
Organization (name, address)	company (name, domain)	Pipedrive orgs have no required domain; derive it from members' email domains or leave name-only. Address goes to a custom field.
Person (name, email[], phone[], org_id)	contact (first_name, last_name, email, phone, company_id)	Pipedrive stores emails and phones as labeled arrays; take the primary value. Contacts without an email are valid in Relm, so nobody gets dropped.
Deal (title, value, currency, pipeline_id, stage_id, status)	deal (title, value_cents, currency, pipeline, stage)	Pipedrive values are major units - multiply by 100 for value_cents. Status won/lost maps to won/lost stages; expected_close_date maps to close_date.
Pipelines + stages	POST /v1/pipelines with ordered stages	1:1. Each Pipedrive pipeline becomes a Relm pipeline with the same stage names in the same order.
Activity (type, subject, note, done time)	activity (type, body, occurred_at)	Relm ships note, email, call, meeting, task types by default; the agent can register extras (deadline, lunch) at runtime.
Note (content, add_time)	activity with type: "note"	Set occurred_at to the original add_time so history keeps its dates.
Leads (Leads Inbox)	contact with type: "lead"	Optionally also a deal in an early stage if the lead carries a value.
Custom fields (hash keys)	POST /v1/fields once, then custom_fields	Register each field with a readable key and a type - text, number, date, boolean. Typed fields reject bad values at import time.

One habit worth keeping: store each record's original Pipedrive ID in a pipedrive_id custom field. It makes verification trivial and gives you a permanent back-reference.

Step 3 - one agent run

Start with a relm_test_ key from the dashboard. Test mode writes to an isolated dataset that is free, unmetered and invisible to live data, so the rehearsal costs nothing and can be thrown away. The setup calls are tiny and safe to re-run - re-creating an existing pipeline returns a 409 instead of a duplicate, and registering a field key that already exists is a no-op. Pipelines first, then the custom-field registry. Pipedrive's default pipeline, recreated stage for stage:

curl -X POST https://api.relmcrm.com/v1/pipelines \
  -H "Authorization: Bearer relm_test_..." \
  -H "Content-Type: application/json" \
  -d '{ "name": "Sales", "stages": ["qualified", "contact_made",
        "demo_scheduled", "proposal_made", "negotiations_started",
        "won", "lost"] }'

curl -X POST https://api.relmcrm.com/v1/fields \
  -H "Authorization: Bearer relm_test_..." \
  -H "Content-Type: application/json" \
  -d '{ "object": "deal", "key": "pipedrive_id", "data_type": "number" }'

Then the load itself: POST /v1/batch takes up to 100 operations per call and returns a per-op result array, so one bad row never fails the batch. Records get server-assigned IDs, which means the agent loads in dependency order across batches - companies, then contacts referencing company IDs, then deals referencing contact IDs, then activities. A deals batch with Pipedrive-shaped data looks like this:

curl -X POST https://api.relmcrm.com/v1/batch \
  -H "Authorization: Bearer relm_test_..." \
  -H "Content-Type: application/json" \
  -d '{ "operations": [
    { "object": "deal", "data": {
        "title": "Baltic Freight - annual licence",
        "value_cents": 1200000, "currency": "EUR",
        "pipeline": "sales", "stage": "proposal_made",
        "primary_contact_id": "con_x8f3k2m9q2",
        "close_date": "2026-09-30",
        "custom_fields": { "pipedrive_id": 1042 } } },
    { "object": "deal", "data": {
        "title": "Nordkette GmbH - onboarding package",
        "value_cents": 450000, "currency": "EUR",
        "pipeline": "sales", "stage": "won",
        "custom_fields": { "pipedrive_id": 977 } } }
  ]}'

Each operation is metered individually against your quota - batching saves round-trips, not requests. If the agent sends a stage or field Relm does not know, the 422 comes back with valid_options and, where it helps, the exact call to create the missing piece, so the agent self-corrects instead of stalling. That contract is documented in the API docs and machine-readable via the agent hub.

Over MCP the whole thing collapses into a prompt. Point your client at https://api.relmcrm.com/mcp with the same bearer key and say:

Here is my Pipedrive export: organizations.csv, persons.csv,
deals.csv, activities.csv, notes.csv, plus the dealFields and
personFields mappings.

Migrate everything into Relm:
1. Call relm_describe_schema first.
2. Recreate both Pipedrive pipelines with the same stage order,
   plus won and lost stages.
3. Register every Pipedrive custom field via relm_create_field
   with a readable key, and add pipedrive_id to each object.
4. Load with relm_batch, 100 ops per call, in dependency order:
   companies, contacts, deals, activities.
5. Deal values are major units - multiply by 100 for value_cents.
   Map notes to note activities with occurred_at = add_time.
6. Skip nothing - contacts without an email are fine.
7. When done, report counts per object and every per-op error.

The agent discovers the rest of the contract on its own. For the general pattern of wiring an agent to Relm - keys, MCP config, first calls - see How to give your AI agent a CRM.

Step 4 - verify before you cut over

Never trust a migration you have not counted. Three checks, all cheap:

• Counts. Page through GET /v1/contacts, /v1/companies, /v1/deals and /v1/activities and compare totals against your Pipedrive export line counts. The list envelope's has_more / next_cursor makes this a short loop, and the agent will do it as part of its final report if you ask.
• Spot-checks with q. Every list endpoint takes a q substring filter - contacts match on email, first and last name, phone and LinkedIn URL; companies on name and domain; deals on title. Pick ten records you know well and check them: GET /v1/contacts?q=vaher, GET /v1/deals?q=baltic. Confirm stages, values and custom fields survived intact.
• Re-run safety. Duplicate contact emails return a 409 conflict that includes the existing record, so contact re-runs converge. Deals, companies and activities have no unique key - do not replay a whole load blindly. The batch response's per-op result array tells you exactly which operations failed, so re-send only those, and the pipedrive_id back-reference lets the agent confirm what already landed before re-creating anything.
• Rehearse first. Do the entire run against the test key before touching live. When the test-mode report is clean, take a fresh Pipedrive export and repeat with the live key.

A few hundred records land in under a minute. A 5,000-record account is roughly 5,000 requests - comfortably inside the Pro plan's 100,000 monthly requests at $29/mo, while the Free plan's 1,000 requests (no card) cover small accounts and Scale ($249/mo) covers 2,000,000 for heavy agent traffic afterwards. Full plan detail is on the pricing section.

FAQ

Do I need to write code to migrate from Pipedrive to Relm?

No. Export your data to CSV or let the agent pull it from the Pipedrive API, give an MCP client a Relm key, and describe the job. The agent reads the schema, registers fields, and batch-loads everything. Code is optional, not required.

How do Pipedrive custom fields come across?

Pipedrive exposes custom fields as 40-character hash keys, with the dealFields / personFields / organizationFields endpoints mapping each hash to its name. The agent registers each field once in Relm via POST /v1/fields with a readable key and a type, then sends values under custom_fields. Typed fields reject bad values at import time rather than later.

What happens to won and lost deals?

They arrive as deals in won and lost stages of the recreated pipeline, values and close dates intact. Their notes and activities keep original timestamps via occurred_at, so your history reads correctly in Relm.

Will re-running the import create duplicates?

Contacts converge - a duplicate email returns a 409 with the existing record. Deals, companies and activities have no unique key, so instead of replaying the whole load, re-send only the operations the per-op result array flagged as failed and use the pipedrive_id custom field to confirm what already landed.

How many API requests does a Pipedrive migration use?

One per record - each batch operation is metered individually. Estimate your export's total row count: under 1,000 rows fits the Free plan, and almost any real account fits Pro's 100,000. Test-mode rehearsals never count.

Can I keep using Pipedrive while I migrate?

Yes. Rehearse in test mode, cut over on a fresh export once counts verify, and keep the Pipedrive account until you are confident. Nothing in the process touches your Pipedrive data - both export paths are read-only.