Twelve Years of Contacts.
One Drop.

PREP shows you a row-by-row preview before anything writes to your CRM. You see exactly which contacts will land, which will be skipped because they already exist on email or phone, and which need your manual decision (merge or import as new). Nothing happens until you click Import. After that, you can roll the entire batch back with one click — every contact created by that import is soft-deleted and the batch is marked undone. So the worst case is: you import, you don't like the result, you click Undo, and you're back to your pre-import contact list. (One caveat: if you chose Merge for any rows during dedup review, those merges write data onto existing contacts and aren't reversed by Undo — only the contacts created by the import are soft-deleted.)

Names, emails, phones, mailing addresses, and lead source come over. Custom fields that map cleanly come over too. Free-text notes from a Notes column in your export come over. What does NOT come over: per-contact email histories, recorded call logs, and CRM-specific automation states. Those live in the source system. The honest framing is: you're getting a clean rebuild of the contact database, not a forklift of your entire workflow history.

Built to handle multi-thousand-row exports — agents migrating full FUB or kvCORE databases run them through without issue. The bottleneck is your own review of duplicates and field-mapping decisions, not the upload itself. For a clean export of several thousand contacts, expect most of your time to be spent on dedup decisions, with the actual import running in the background while you review.

Drop the file anyway. PREP can't auto-map the columns, so you'll see all your CSV headers in the mapping step and pick the PREP field for each one (First Name, Last Name, Email, Phone, etc.). The mapping is one-time per CRM source — once you've done it, save the mapping as a template and the next file in the same format is auto-mapped. So an unsupported CRM costs you about three extra minutes the first time and zero minutes after.

Match on email first, then on phone (with country-code-agnostic comparison and digit-only normalization, so '+1 (503) 555-0142' matches '5035550142'). If a row matches an existing PREP contact, you're shown both side-by-side and choose: skip the new one, merge the new fields onto the existing, or import as a separate contact (rare — useful when two real people share a phone number, e.g., spouses).

UTF-8 and UTF-16 are both supported. Byte-Order Marks are stripped automatically. Zip codes are imported as strings, not numbers, so leading zeros survive. Phone numbers are stored as-typed, with a digits-only mirror used for dedup matching. The 'Smith, J.' / 'Smith,J.' kind of whitespace-variation also gets normalized for matching. You're not going to find six different versions of the same contact because your old CRM exported with inconsistent capitalization.