Leaving CiviCRM? We planned for that.

The scariest part of switching CRMs isn’t the new tool — it’s the day you flip the switch and pray the numbers match. Chonk’s migration path is built to take that fear off the table.

Idempotent by design

The importer pulls directly from your CiviCRM MySQL database (and optional file attachments). Every migrated row carries its legacy_civi_id and source table — so you can re-run the import as many times as you like without creating duplicates. Dry-run it, fix a mapping, run it again. Nothing drifts.

A parity gate blocks a bad cutover

When the import finishes, Chonk prints a parity gate: a row-by-row reconciliation of what came out of CiviCRM versus what landed in Chonk. If anything doesn’t match, the process exits non-zero and a red parity blocks cutover. You don’t go live on mismatched data — the tooling won’t let you.

Recurring donors never skip a beat

This is the one most migrations get wrong. Chonk adopts Stripe subscriptions rather than recreating them — recurring donations keep their processor_subscription_id and processor_customer_id, so live subscriptions keep charging uninterrupted through the switch. No re-enrollment emails. No lapsed monthly gifts.

The shape of a cutover

1. Connect your CiviCRM database (read-only) and point the importer at it.
2. Dry-run the import into a staging Chonk and read the parity gate.
3. Resolve any mismatches — the gate tells you exactly where.
4. Re-run until parity is green (it’s idempotent, so this is safe).
5. Cut over — adopt live subscriptions, flip DNS/embeds, done.

Migrating a multi-chapter CiviCRM? The Alliance plan includes a white-glove migration. Talk to us →