Migrate Custom Fields Between CRMs: Types, Options, Checks

Custom fields move in three parts: the field, its options, its values. Match types, reconcile dropdown options, test 50 records, read the report.

Last updated: 3 November 2026

To migrate custom fields between CRMs, move three parts: the field definition, its dropdown options, and its values. The new CRM needs the field and its options before values can land, so either create them first or use a tool that creates them. Then test on a small sample and count blanks per field. This guide covers two causes of lost values: field types that differ, and an option label in the data that does not match an option in the new CRM.

This guide gives the steps in the order to do them, a table of the type mismatches that lose data, and a checklist for the day of the full run.

What moves when you migrate custom fields between CRMs: the field, its options, its values

A custom field is three things, and each can fail separately.

  • The definition: name, type, and the object it belongs to (people, companies, deals).
  • The options: the allowed choices of a dropdown or multi-select.
  • The values: what each record holds in that field.

HubSpot's file import expects the definition and options to exist already: column headers must match an existing property, so custom properties are created before the import.

Some tools create the structure for you. MigrateMyCRM's HubSpot listing says it can automatically create and map custom fields through its mapping interface. Attio's built-in migration, run by Import2, creates custom objects and attributes during the migration. Which of these you use decides what you clean up afterward.

Step 1: List every custom field and cut the ones you do not need

Export the full field list from the old CRM: name, type, object, and the number of records where it has a value. Rework's field mapping guide gives the same starting point: export every custom field, then skip the ones nobody reports on, segments by or automates from.

A field with no values on any record does not need to move. Ask the owner of each remaining field one question: which report, view or automation reads it? If the answer is none, the field stays behind in an archive export.

Map by field name, not by key. Pipedrive custom field keys are 40-character hashes, and a key cannot be renamed, although the visible name can. Names are what you can read and check, so write the mapping against names.

Step 2: Match field types before you match values

A type mismatch can leave a field empty or wrong. Pipedrive alone has 16 custom field types, including monetary, phone, date range, time range and address.

The table lists the rules published by the vendors, for the field types where data most often goes wrong.

Field type Source behavior Destination rule
Monetary Pipedrive stores the amount and the currency as two values Attio's currency attribute supports one currency and no symbols; HubSpot needs a HubSpot-accepted currency code
Number Pipedrive double: up to 16 decimal places Attio stores up to 4 decimal places
Address Pipedrive keeps city, state, zip and country in one field Attio takes one column mapped to Primary location and splits out city, state and country
Date range, time range Own field types, each holding a start and an end (Pipedrive) Check whether the destination has an equivalent. If not, plan two fields: start and end
Multi-select Pipedrive set field HubSpot: semicolon-separated, options must exist. Attio: comma-separated
Date Source format varies Attio needs the format picked on the Review values step
Checkbox True/false HubSpot: True/Yes or False/No. Attio: accepts several true/false spellings, listed in its CSV formatting guide
User Pipedrive user field Attio matches workspace members by membership ID, email, full name, then first name, and fails validation if no member matches, and you set the value on the Review values step
Phone Source format varies HubSpot: +[country code][number]. Attio: E.164

The table shows destinations that publish their rules. For Clarify and Odoo, read the field types in the destination's own settings before you map.

The type mismatches that lose data

Check these five cases first.

  1. Multi-select separators. HubSpot reads semicolons between values and Attio reads commas. Check which separator your file uses.
  2. Monetary in mixed currencies. If your Pipedrive deals hold EUR, USD and GBP values and the destination field takes one currency, as Attio's does, only one of the three currencies fits the field. Convert the others first or keep the original in a separate field.
  3. Address into separate fields, or the reverse. Splitting one address into city, state, zip and country, or joining them, changes the field count. Map it deliberately.
  4. Date range with no equivalent. The start and end need two fields. Create both and map each.
  5. User fields. The person named in the old CRM must exist in the new one, as a workspace member Attio can match by email or name.

HubSpot adds one more rule: a value that breaks a property's validation rules is not imported, and blank cells are ignored and do not clear existing values.

Step 3: Reconcile dropdown options before you move values

A dropdown value must match an option that already exists in the destination. HubSpot expects dropdown values to match either the option's label or its internal value. Attio matches select values by option label, case-insensitive, or option ID.

So "Closed - Won" in the old CRM and "Closed Won" in the new one are two different labels, and neither HubSpot nor Attio treats them as the same option. A renamed option breaks the match the same way.

To find these before the full run:

  1. Export the distinct values of each dropdown field from the source, with a count.
  2. Export the option list of the destination field.
  3. Compare the two. Every source value without a match may fail to import; decide to add the option, rename it, or map it to another one.

Attio adds a rule for existing records: imported multi-select values are added to the current values, not replacing them. If you re-run an import onto records that already have values, the field grows.

Step 4: Create the fields first, or let the tool create them

There are two ways to get the structure into the new CRM, and each leaves something different behind.

Create it yourself. You control names, types and options. It takes time: one field at a time in the settings, or by a script if you have one. This is the route when the importer needs the fields to exist, as HubSpot's file import does.

Let the tool create it. The tool decides names and types, and you review them afterward. With Import2 in Attio, a sample migration creates the non-system attributes from the old CRM, and you review them in object settings and update or archive them. Review them.

Whichever you choose, ask what happens when you cancel. Attio's help page says that undoing an Import2 migration removes the imported records but not the lists, attributes or structures it created, and that a full reset requires contacting Import2. If you test an Import2 migration on a production workspace, undoing it leaves the attributes it created.

A worked example

Say a team has 31 custom fields across people, organizations and deals in Pipedrive, and 40,000 contacts. This is an illustrative scenario, not a customer.

They export the field list with fill counts. Nine fields are empty on every record; those stay behind. That leaves 22.

Reading the 22 against the table, they find:

  • 3 date range fields (campaign dates, contract term, trial period). Each becomes two fields.
  • 1 monetary field on deals. The deals hold EUR and USD. The destination field takes one currency, so they decide to convert before the move and keep the original amount in a text field.
  • 2 dropdown fields. One has 14 options in Pipedrive and 11 in the destination; three options need to be added.
  • 1 address field. They map it to the destination's location field.
  • 1 user field (account owner). Two former employees have no user in the new CRM; they decide what those records get.

A sample run on records that carry these fields shows which of them lose values before the full run.

Step 5: Run a sample and check each field

A sample catches the type and option problems on a small set. Make sure it includes records with values in the risky fields: the multi-selects, the money, the dates, the owners. A random sample from a CRM where most records have few custom values can pass and prove nothing.

For each custom field, compare source and destination on three counts: how many sampled records had a value, how many arrived with a value, and how many arrived equal. A field where the first number is 40 and the second is 31 has nine silent blanks. Find their values and look for a shared pattern, such as one unmatched option label or one currency.

Keep parent records in the sample. A deal without its linked company and contact cannot show whether the links carry over.

Step 6: Read the per-record report and fix by reason

If the tool gives a per-record result, sort it by reason, not by record. Ten failures with the same reason are one fix. A report that says "failed" with no reason makes you guess, so prefer a tool that states one.

Typical reasons map back to the rules above: an option not found, a value outside a validation rule, a user that matched no workspace member, a phone number not in E.164. Fix the cause in the destination or the source, then re-run the sample, not the whole migration.

Step 7: Know what a rollback deletes

Decide before the full run what you do if the result is wrong. A rollback that deletes records but leaves fields, options and objects behind means every test run adds clutter to a workspace people use. Ask the tool or vendor three questions: does cancel delete the records, does it delete the structure it created, and does it touch structure that existed before. The answer for each should be written down in its documentation.

What each route does with custom fields

Route Structure Check before the run Undo
Native CSV import (HubSpot, Attio, others) HubSpot needs properties first; Attio: see its CSV import guide Your own comparison Check the vendor's docs
Import2 into Attio Created during migration; you review attributes after a sample Sample migration Records removed; structure stays
Third-party tool (MigrateMyCRM by SyncMatters) Custom fields created and mapped through the tool's mapping interface Ask the vendor Ask the vendor

Import2 has its own limits: records map to objects, not to lists, so list data goes through the CSV importer, and incorrectly formatted phone numbers and invalid domains cause import errors.

Where Shuttio fits

Shuttio moves data from HubSpot, Pipedrive, Affinity or CSV into Attio, Clarify or Odoo, and from Attio into Clarify. Affinity to Odoo is not supported, so for that pair use another route.

Every ticked object lands in the destination with its fields, options and the links to other ticked objects. A reference to an object you did not tick is kept as text and is not linked. You review the fields before anything is written. A multi-select source field is marked "Kept as text" in the field review: its values are written as one text value. For a migration from a connected CRM, you then run a free sample of each ticked object: 5% of its records, at least 10 and at most 1,000, picked at random. The sample is random, so a field that few records use may appear on only a few sampled records or none. Check the per-field counts on the sample, and test a rarely used field separately before the full run. A CSV import has no sample and starts as the full run. The report lists every record with its result and a reason for each failure. Cancel deletes what the migration created in reverse order, including objects, fields and options. Exceptions: an Attio object it created is deleted only when empty, an Odoo field only while no record holds a value, and a matched existing record stays.

Into Attio, Attio's own Migrate button (Import2) is the other option. Attio's help page says undoing an Import2 migration removes only the imported records; Shuttio's cancel also removes the objects, fields and options it created, with the exceptions listed above. Into Clarify or Odoo, a CRM migration is priced once per migration by record count, from $249 up to 50,000 records; a CSV import is free.

Checklist before the full run

  • Field list exported with fill counts; unused fields cut
  • Mapping written by field name, not by key
  • Every field type checked against the destination
  • Date ranges, multi-selects and multi-currency fields have a plan
  • Dropdown values compared with destination options; gaps closed
  • User fields: every named person exists once in the new CRM
  • Sample that includes records with values in the risky fields
  • Blanks counted per field, source against destination
  • Failure reasons read and fixed at the cause
  • Rollback behavior confirmed, including fields and options

FAQ

Do custom fields transfer automatically when I switch CRMs? Only if the tool creates them. A file import in HubSpot needs the properties to exist first. Tools like Import2 into Attio create them during the migration, and you review them afterward.

Why are my dropdown values blank after the import? The value probably did not match a defined option. HubSpot expects a value to match an option's label or internal value, and Attio matches select values on label or ID. Compare the distinct source values with the destination options and add or rename the difference.

Where does the currency go when I move a monetary field? In Pipedrive, the amount and the currency are two values. If the destination field supports one currency, as Attio's does, Attio supports one currency per attribute, so convert amounts in other currencies first or keep the original in a separate field.

Can I change a field's type during migration? Only where the destination's rules accept the old values. Attio needs a date format picked and stores up to 4 decimal places; HubSpot skips values that break a property's validation rules. Test the change on the sample and count the blanks.