Pipedrive to HubSpot Migration: Data Mapping, APIs & Rate Limits

Migrating from Pipedrive to HubSpot is a data-model translation problem, not a CSV upload. The core challenge is moving years of deals, contacts, activities, notes, and file attachments while preserving the multi-object associations that give your CRM data its meaning. A CSV export gets the records across; it does not get the relationships across.

This guide breaks down the object-mapping decisions that define your HubSpot architecture, the exact API constraints on both sides, the extraction architecture required for large datasets, and the failure modes that catch teams off guard — so your engineering team can choose the right approach before writing a single line of migration code.

For a broader look at why teams are moving to HubSpot, see Why Top-Performing Teams are Migrating to HubSpot. If you are evaluating whether to separate the migration from HubSpot implementation work, read Why Data Migration Isn't Implementation.

The Architectural Shift: Pipedrive vs. HubSpot Data Models

Pipedrive and HubSpot both track contacts, companies, and deals. The structural differences are what make the migration hard.

Pipedrive's model is sales-pipeline-centric. The core entities are Organizations, Persons, Deals, Leads, Activities, and Products. Deals sit at the center of the data model — every activity, note, and file fans out from a deal or its linked contact. Leads live in a separate inbox and are converted to deals when qualified. There are no custom objects; Pipedrive supports custom fields across its standard entities but not custom entity types.

HubSpot's model is a relational CRM. Standard objects are Companies, Contacts, Deals, Tickets, and Products, connected by an explicit Associations API. HubSpot supports Custom Objects, but only on Enterprise-tier subscriptions, with a default limit of 10 custom object definitions per account. HubSpot also has a separate Leads object, available in Sales Hub Professional and Enterprise, where each lead must be associated with an existing contact.

The critical difference for migration: Pipedrive activities (calls, meetings, tasks) are first-class records linked to deals, persons, and organizations. After the March 25, 2024 API change, a Pipedrive activity can link to only one of deal, lead, or project at a time. In HubSpot, the equivalent concept is Engagements — notes, emails, calls, meetings, and tasks — each managed through its own API endpoint and associable with multiple contacts, companies, and deals simultaneously via typed association IDs. Your transformation layer may need to expand relationships, not just copy them.

Data Model & Object Mapping: Pipedrive → HubSpot

Every migration starts with this mapping. Get it wrong and everything downstream breaks.

For Pipedrive Leads, most teams choose one of two patterns: map them into HubSpot Leads only if they actively want the HubSpot prospecting workflow, or convert them into Contacts plus early-stage Deals if the business already qualifies inside the deal pipeline.

Field-Level Mapping Gotchas

Custom field keys. Pipedrive represents every custom field as a randomly generated 40-character hash — for example, dcf558aac1ae4e8c4f849ba5e668430d8df9be12. These hashes differ across every Pipedrive account, even for identically named fields. Your extraction script must call the *Fields endpoints (e.g., /api/v2/dealFields) first, build a hash-to-label lookup table, then use that table to map values to the corresponding HubSpot property internal names.

Multi-value fields. Pipedrive stores phone numbers and emails as arrays of objects with labels (e.g., work, home). HubSpot stores a single primary email as the contact's dedup key and additional emails in a separate hs_additional_emails property. Your transform layer needs to flatten these arrays and pick the correct primary value.

Picklist / option fields. Pipedrive option-set fields store the selected value as a numeric ID internally. When you export via API, the response includes both the ID and the label. HubSpot properties use string-based internal values for dropdown options. You must create matching dropdown options in HubSpot before import and map Pipedrive's numeric IDs to HubSpot's string keys.

Monetary fields. Pipedrive deals carry both a value and a currency field. HubSpot deals use amount and deal_currency_code. The field names change, but the data type (decimal + ISO currency code) maps cleanly.

Date and time range fields. Pipedrive supports 16 custom field types, including date range and time range. HubSpot has no native range field — split these into separate start and end properties.

Person / organization reference fields. If a Pipedrive custom field references another person or organization, create an association in HubSpot rather than storing a flat text value.

Formula fields. Pipedrive formula fields must be either precomputed during migration or recreated as HubSpot calculation properties, if the logic fits HubSpot's formula model.

Sample Field Mapping Table

Evaluating Migration Approaches

There are five realistic paths. Each has hard constraints that should drive your decision.

1. Native CSV Export → HubSpot Import

How it works: Export Contacts, Companies, and Deals from Pipedrive as CSV files. Import them into HubSpot using the built-in import wizard, which supports mapping columns to HubSpot properties and creating associations between two object types per import file.

When to use it: Small datasets (< 5,000 records), simple structures, no activities or files to migrate.

Hard limits:

• HubSpot's CSV import can associate only two object types per file (e.g., Contacts + Companies, or Contacts + Deals). You cannot import a three-way association in one pass.
• Activities cannot be imported via CSV. Notes, calls, meetings, and tasks have no CSV import path — they require the API.
• File attachments are not supported.
• Original timestamps (created date, last modified) can only be set via API, not via CSV import.
• Duplicate creation risk is high if unique identifiers are not managed carefully.

Complexity: Low. Risk: High for anything beyond flat record imports. Relationships break silently.

For a deeper analysis of CSV-based migration trade-offs, see Using CSVs for SaaS Data Migrations: Pros and Cons.

2. API-Based Migration (Custom ETL Pipeline)

How it works: Write extraction scripts against the Pipedrive REST API (v2 preferred), transform the data in a staging layer, then load records into HubSpot via the CRM v3 API with explicit batch creates and association calls.

When to use it: Mid-to-large datasets, complex associations, activity history, attachments, or any scenario where data fidelity matters.

Strengths:

• Full control over field mapping, transformation logic, and association rebuilding.
• Supports activities, notes, emails, files — everything the API exposes.
• Deterministic: you can audit exactly what was migrated.
• Supports delta sync for zero-downtime cutovers.

Hard limits:

• Requires engineering time to build, test, and maintain.
• Must handle rate limits on both sides (see next section).
• Error handling, retries, and idempotency are your responsibility.

Complexity: Medium–High. Risk: Medium — if built correctly with proper validation.

A full custom ETL pipeline goes beyond a few migration scripts: it means a staging database, source-to-target ID maps, resumable jobs, audit tables, and a formal cutover plan. That level of infrastructure is warranted for enterprise migrations with compliance or audit requirements but is overkill for most mid-market moves.

3. SaaS Migration Tools

Tools like Skyvia or Coefficient offer UI-based field mapping, UPSERT support, and basic relationship preservation.

When to use it: Standard CRM objects, limited customization, tight budget, no desire to own ETL code.

Strengths:

• Faster setup than custom scripts.
• UI-based mapping and scheduling.

Hard limits:

• Activity, attachment, and custom object support varies significantly by tool.
• Black-box transforms make it harder to audit why a field changed or disappeared.
• Often struggle with bulk historical data transfers and complex multi-object relationships.

Complexity: Low–Medium. Risk: Medium — needs real testing before enterprise use.

For a comparison of migration providers, see ClonePartner vs. Import2.

4. Middleware / iPaaS (Zapier, Make)

How it works: Use trigger-action workflows to move records between Pipedrive and HubSpot on a per-record basis.

When to use it: Ongoing sync of new records between two live systems. Post-cutover automation. Not for bulk historical migration.

Hard limits:

• Process records one at a time (or in small batches), making bulk backfills slow and expensive on task-based pricing.
• No native support for rebuilding multi-object associations or migrating file attachments.
• Ordering, idempotency, and retry control are weak compared with ETL.
• Pipedrive's V1 API endpoints used by many iPaaS connectors are being deprecated, with the full V1 shutdown scheduled for July 31, 2026. Connectors must move to V2.

Complexity: Low for simple sync. Risk: High for one-time historical migration.

5. Managed Migration Service

How it works: A dedicated migration team builds a custom ETL pipeline, handles rate-limit management, association rebuilding, validation, and cutover.

When to use it: When your engineering team's time is better spent on product work than on building throwaway migration scripts.

Strengths:

• Handles API throttling, custom field resolution, and multi-object associations as a known pattern.
• Pre-built tooling for Pipedrive's token-based rate limits and HubSpot's burst windows.
• Validation and rollback are part of the process, not an afterthought.

Complexity: Low for your team. Risk: Low — assuming you vet the provider's CRM migration experience.

Migration Approach Comparison

API Rate Limits & Extraction Architecture

Both Pipedrive and HubSpot enforce strict rate limits. A migration script that ignores them will stall, corrupt data, or get blocked entirely.

Pipedrive: Token-Based Rate Limits (TBRL)

Pipedrive transitioned to a token-based rate limiting system starting December 2, 2024, rolling out to all existing customers by May 31, 2025. (developers.pipedrive.com)

Daily budget formula:

30,000 base tokens × plan multiplier × number of seats (+ purchased top-ups)

Each API endpoint has a token cost based on its computational complexity. A lightweight GET for a single record is cheap; a search or complex update costs more. Your extraction script's budget is shared across all users and integrations on the account — so if sales reps are working in Pipedrive while you're migrating, their API-driven integrations compete for the same token pool.

Burst limits also apply on a rolling 2-second window per API token. Even if daily tokens remain, rapid-fire requests trigger 429 Too Many Requests. Persistent abuse escalates to 403 from Cloudflare.

v2 endpoints consume approximately 50% fewer tokens than their v1 equivalents. Use v2 wherever available. Note that Leads remain V1-only as of early 2026. Selected v1 endpoints were deprecated effective January 1, 2026, with the full V1 API shutdown scheduled for July 31, 2026.

HubSpot: Burst Limits & Daily Quotas

HubSpot enforces two layers of rate limiting:

Batch endpoints accept up to 100 records per call for creates, updates, and reads. A single batch call counts as one request against the burst limit — this is your primary throughput multiplier.

The CRM Search API has a separate, stricter limit: 5 requests per second shared across all object types, with a maximum of 10,000 results per query. (developers.hubspot.com) If you're using search for deduplication checks during import, this becomes the bottleneck — not the burst limit.

The Associations API has its own tighter ceiling: 150 requests per 10 seconds, with batch limits of 2,000 creates and 1,000 reads per call. (developers.hubspot.com) If you design your loader around the general 190 limit and forget associations have a lower ceiling, relationship rebuilds become the new bottleneck.

Practical throughput math: With 190 requests per 10 seconds and 100 records per batch call, you can theoretically create ~1,900 records every 10 seconds, or ~11,400 records per minute. In practice, association calls, error handling, and search-based dedup checks cut that significantly. Budget for ~2,000–4,000 records per minute for a migration with association rebuilding.

Designing for Rate Limits

import time
import requests
from collections import deque
 
class RateLimitedClient:
    """Simple token-bucket client for HubSpot burst limits."""
    
    def __init__(self, max_requests=180, window_seconds=10):
        self.max_requests = max_requests  # Stay below 190 as safety margin
        self.window = window_seconds
        self.timestamps = deque()
    
    def wait_if_needed(self):
        now = time.time()
        while self.timestamps and self.timestamps[0] < now - self.window:
            self.timestamps.popleft()
        if len(self.timestamps) >= self.max_requests:
            sleep_time = self.timestamps[0] - (now - self.window) + 0.1
            time.sleep(sleep_time)
        self.timestamps.append(time.time())
    
    def post(self, url, json_data, headers):
        self.wait_if_needed()
        response = requests.post(url, json=json_data, headers=headers)
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", 10))
            time.sleep(retry_after)
            return self.post(url, json_data, headers)
        return response

Step-by-Step API Migration Process

The migration follows a strict dependency order. Violating this order means broken associations.

Phase 1: Extract from Pipedrive

1. Fetch field schemas — Call /api/v2/personFields, /api/v2/organizationFields, /api/v2/dealFields, and /api/v1/activityFields to build the custom field hash → label map.
2. Extract Organizations — Paginate through /api/v2/organizations using cursor-based pagination. Store all records with their Pipedrive IDs.
3. Extract Persons — Paginate through /api/v2/persons. Capture the org_id foreign key for each person.
4. Extract Deals — Paginate through /api/v2/deals. Capture person_id, org_id, stage_id, pipeline_id.
5. Extract Activities — Paginate through /api/v2/activities. Capture deal_id, person_id, org_id linkages.
6. Extract Notes — Paginate through /api/v1/notes (or v2 when available). Capture deal_id, person_id, org_id.
7. Extract Files — For each deal/person/org, call the /files sub-endpoint. Download the file binary and store locally or in cloud staging. Note: file endpoint page size was reduced to 100 on January 15, 2025.

Phase 2: Transform

1. Resolve custom field hashes — Replace 40-character hash keys with human-readable names using the field schema map.
2. Flatten multi-value fields — Extract primary email, primary phone. Store additional values for hs_additional_emails.
3. Map picklist values — Convert Pipedrive numeric option IDs to HubSpot string-based dropdown values.
4. Split person names — Pipedrive stores a single name field; HubSpot requires firstname and lastname.
5. Map pipeline stages — Build a pipedrive_stage_id → hubspot_dealstage lookup. Pre-create all pipelines and stages in HubSpot before import.
6. Standardize timestamps — Convert date formats to ISO 8601 or Unix milliseconds as required by HubSpot endpoints.
7. Build an ID crosswalk — Create a mapping table: {pipedrive_type}_{pipedrive_id} → hubspot_id. This is the foundation for rebuilding associations in the next phase.

Phase 3: Load into HubSpot

Load in dependency order:

1. Companies — Batch create via POST /crm/v3/objects/companies/batch/create (100 per call). Store returned hs_object_id in the crosswalk.
2. Contacts — Batch create via POST /crm/v3/objects/contacts/batch/create. Include email as the dedup key. Store returned IDs.
3. Associations: Contact → Company — Use POST /crm/v4/associations/contacts/companies/batch/create to link contacts to their companies using the crosswalk.
4. Deals — Batch create via POST /crm/v3/objects/deals/batch/create. Store returned IDs.
5. Associations: Deal → Contact, Deal → Company — Two separate batch association calls.
6. Engagements (Notes, Calls, Meetings, Tasks) — Create via the engagement-specific endpoints (e.g., POST /crm/v3/objects/notes). Include the associations array in the create request to link each engagement to its contact, company, and/or deal in a single call.
7. Files — Upload binary via POST /files/v3/files, then create a Note engagement containing the file ID via hs_attachment_ids, associated with the correct record.

# Batch create contacts with association to company
def migrate_contacts(contacts_batch, crosswalk, hs_client):
    payload = {
        "inputs": [
            {
                "properties": {
                    "email": c["email"],
                    "firstname": c["firstname"],
                    "lastname": c["lastname"],
                    "phone": c["phone"],
                    "pipedrive_person_id": str(c["pipedrive_id"])
                },
                "associations": [
                    {
                        "to": {"id": crosswalk[f"org_{c['org_id']}"]},
                        "types": [{"associationCategory": "HUBSPOT_DEFINED",
                                    "associationTypeId": 279}]
                    }
                ] if c.get("org_id") else []
            }
            for c in contacts_batch
        ]
    }
    response = hs_client.post(
        "https://api.hubspot.com/crm/v3/objects/contacts/batch/create",
        json_data=payload,
        headers={"Authorization": f"Bearer {HS_TOKEN}"}
    )
    # Store returned IDs in crosswalk
    for result in response.json()["results"]:
        pipedrive_id = contacts_batch[result["rowIndex"]]["pipedrive_id"]
        crosswalk[f"person_{pipedrive_id}"] = result["id"]

For file migrations, the flow is download → upload → attach:

file_id = hubspot.upload_file(binary_data, folder='migrations/pipedrive')
hubspot.create_note(
    properties={
        'hs_timestamp': source_note['created_at'],
        'hs_note_body': sanitize_html(source_note['body']),
        'hs_attachment_ids': str(file_id)
    },
    associations=note_links
)

Phase 4: Delta Sync & Cutover

Keep sales working in Pipedrive during the baseline load. Use Pipedrive's updated_since filter on v2 endpoints to capture changes made since your baseline extraction. Webhooks v2 (the default for new webhooks since March 17, 2025) can supplement this for near-real-time change capture. Run a final delta sweep, freeze edits briefly, validate, and switch users to HubSpot.

Phase 5: Validate

• Record counts — Compare total Organizations/Persons/Deals in Pipedrive vs. Companies/Contacts/Deals in HubSpot.
• Association integrity — Sample 5–10% of records and verify that Deal → Contact → Company chains are intact.
• Field-level spot checks — Compare a random sample of 50–100 records field by field.
• Activity counts — Per-deal activity count in Pipedrive should match per-deal engagement count in HubSpot.
• File verification — Confirm attachments are accessible and linked to the correct records.
• Timeline tests — Check a sample of high-value deals to verify historical activity appears in the correct order.

Edge Cases & Common Failure Modes

Duplicate Records

HubSpot deduplicates contacts on email. If two Pipedrive persons share an email address, the second create will fail with a conflict error. Your migration script must handle this — either by merging records pre-migration or by catching the error and updating the existing contact instead.

Companies have no automatic dedup. Two organizations with the same name create two separate companies unless you explicitly check. Do not dedupe companies by name alone — use domain where available or source ID properties.

Multi-Level Association Chains

Pipedrive links an Activity → Deal → Person → Organization in a connected graph. HubSpot requires you to set each association explicitly. If you create a note and associate it only with a deal, it will not automatically appear on the contact's timeline — you must also associate the note with the contact directly.

Custom Objects: The Enterprise Gate

If your Pipedrive instance uses creative custom-field structures to simulate distinct entity types (e.g., "Subscription" data stored as custom fields on deals), migrating those to HubSpot Custom Objects requires an Enterprise-tier subscription. The default limit is 10 custom object definitions with up to 500,000 records each. This is a licensing decision that must be made before the migration begins. If you do not have Enterprise, you must collapse that structure into standard objects plus properties — which is sometimes acceptable and sometimes a reporting disaster.

File Attachments

Pipedrive files must be downloaded individually using the Files API, then re-uploaded to HubSpot's File Manager, then associated with the correct record via a Note engagement with hs_attachment_ids. There is no shortcut. For large file volumes, this becomes the single longest phase of the migration. Pipedrive's global data export does not include Google Drive files, and files linked to deals and contacts must be exported separately.

Deal Participants

Pipedrive supports Deal Participants — multiple persons linked to a single deal with role labels. HubSpot supports multiple contact associations per deal natively via the Associations API. However, Pipedrive's participant role labels (e.g., "Decision Maker", "End User") must be mapped to HubSpot's custom association labels if you want to preserve that context — and defining custom association labels requires HubSpot Professional or Enterprise.

Historical Timestamps

HubSpot allows setting hs_timestamp on engagements and createdate on CRM records via API. If you do not explicitly set these, every imported record will show the migration date as its creation date — destroying your historical timeline. This is one of the most common and most damaging mistakes in CSV-based migrations.

Archived Deals and Leads

Since July 15, 2025, archived deals and leads are not returned by Pipedrive's standard endpoints. They require dedicated archived endpoints. If leadership expects "everything" to move, confirm whether that includes archived records. Missing this in the audit is a common source of post-launch complaints.

Activity Type Mapping

Custom Pipedrive activity types do not automatically have a first-class HubSpot equivalent. Create a written mapping rule — for example: call → call, meeting → meeting, todo → task, everything else → note — and validate it with users before running the full migration.

Note Body Limits

Pipedrive notes can reach ~100KB. HubSpot note bodies are limited to 65,536 characters. Truncation or splitting may be needed for very long notes.

Pre-Migration Planning Checklist

Before writing code or hiring a migration partner, work through this list:

• Data audit: Export record counts for Organizations, Persons, Deals, Leads, Activities, Notes, and Files from Pipedrive. Include archived records if they are in scope.
• Scope definition: Identify what not to migrate. Lost deals older than 3 years? Inactive contacts? Redundant custom fields? Pruning before migration saves time and cost.
• HubSpot architecture: Create all pipelines, deal stages, contact properties, company properties, custom properties, and source ID fields in HubSpot before importing data.
• Custom Objects decision: If needed, confirm HubSpot Enterprise licensing is in place.
• Leads strategy: Decide whether Pipedrive Leads become HubSpot Leads (requires Sales Hub Pro/Ent) or Contacts with a lifecycle stage / lead status property.
• Dedup strategy: Run dedup in Pipedrive before extraction. It is cheaper to merge duplicates in the source than to untangle them post-migration.
• Migration strategy: Choose between big-bang (all at once over a weekend), phased (objects migrated in stages), or incremental with final delta sync. Big-bang is simpler; phased is safer for large datasets; incremental with delta sync allows zero-downtime cutover.
• Rollback plan: Decide in advance: if validation fails, can you delete all imported records and re-run? HubSpot supports bulk archive via API, but associations must be re-created from scratch.
• Backup: Export a full data backup from Pipedrive via Settings → Export data before starting.

Limitations & Structural Compromises

Some data will not transfer perfectly. Knowing this upfront prevents mid-migration surprises.

• Pipedrive Leads Inbox metadata — Lead labels and source tracking fields have no direct HubSpot equivalent. Map them to contact properties.
• Email threading — Pipedrive's mail sync stores full email threads linked to deals. Migrating these as HubSpot email engagements preserves the content but loses the native thread grouping.
• Pipedrive Insights / Reports — Dashboards and saved filters are configuration, not data. They must be rebuilt manually in HubSpot.
• Workflow automations — Pipedrive automations do not transfer. Rebuild them as HubSpot workflows post-migration.
• HubSpot private app logs do not store request bodies, URL parameters, or successful response payloads. (developers.hubspot.com) If you need full auditability, keep your own external request log and reconciliation tables.

Validation, Testing & Rollback

A migration is ready when the data can survive hostile questions from sales, RevOps, and finance.

Validation checklist:

• Record counts by object type
• Count of orphan deals (deals without a contact or company)
• Count of contacts without companies, if that is unexpected
• Spot checks of stage, owner, amount, close date, and last activity
• Attachment open tests
• Timeline tests on a sample of high-value deals
• UAT with real users before cutover

Sampling strategy:

• 10–20 random records per object
• Every executive-owned deal
• Every pipeline
• Every custom field group
• Edge cases: merged contacts, archived records, attachments, long notes

Rollback planning:

• Keep the source system active (read-only) for at least 30 days post-migration as a reference
• Version every mapping file
• Preserve source-to-target ID maps
• Make the migration idempotent so reruns are a repair tool, not a panic move

Post-Migration Tasks

After data lands in HubSpot, the work is not done.

1. Rebuild automations — Re-create Pipedrive automations as HubSpot workflows. Test each one against migrated data.
2. Reconfigure integrations — Any third-party tool connected to Pipedrive (email sync, calling tools, marketing automation) needs to be reconnected to HubSpot.
3. User training — HubSpot's interface and navigation differ from Pipedrive. Budget 1–2 days for team training, especially if Pipedrive Leads became a different structure in HubSpot.
4. Monitor for 2–4 weeks — Run daily spot checks on record counts, association integrity, and activity timelines. Issues surface when users start working with the data.
5. Decommission Pipedrive — Keep the account active (read-only) for at least 30 days as a fallback.

Best Practices That Save Real Time

• Back up everything before starting. Pipedrive's built-in export captures the data; your API extraction captures the relationships.
• Run a test migration with a realistic subset first. Validate record counts, field values, and associations before the full load.
• Use HubSpot batch endpoints — 100 records per call dramatically reduces API consumption.
• Prefer Pipedrive API v2 endpoints where available for lower token costs and cursor-based pagination.
• Build the ID crosswalk as you go. Without it, you cannot rebuild associations.
• Set historical timestamps explicitly on every record and engagement.
• Validate incrementally — don't wait until the end to check data quality.
• Freeze schema changes during the final migration window.
• Separate migration from implementation — they are different workstreams with different owners.

When to Use a Managed Migration Service

Building a one-time migration pipeline is engineering work with a short shelf life. The script runs once, gets debugged a dozen times, then gets deleted. The total cost is rarely just "developer hours" — it includes:

• Learning two APIs from scratch (Pipedrive TBRL + HubSpot v3 batch semantics)
• Building rate-limit management for both sides
• Debugging custom field hash resolution across 16 field types
• Handling partial failures, retries, and idempotency
• Validation scripts and UAT support
• Opportunity cost of pulling engineers off product work

For teams with 10,000+ records, complex deal structures, activity history, and file attachments, the build-vs-buy math tilts toward a managed service.

Why ClonePartner

ClonePartner is an engineer-led service that has completed 1,200+ data migrations, including complex CRM-to-CRM moves with multi-object association preservation, custom field mapping, and zero-downtime cutovers. Our migration engine handles Pipedrive's token-based rate limits and HubSpot's burst windows automatically — no manual throttling scripts required.

We guarantee association integrity: if a Pipedrive activity was linked to a deal, a person, and an organization, it arrives in HubSpot linked to the correct deal, contact, and company. We separate extraction/loading work from implementation work so timelines stay honest. And with delta sync, your sales team can keep working in Pipedrive until the final cutover window.

That is not a pitch for outsourcing every migration. If your scope is small, use CSV and keep it simple. If the scope includes history, files, custom logic, and no room for failure, managed execution is usually cheaper than pulling senior engineers into a one-off data program.