← All postsHow-to

Contact import: moving a list without importing the mess

A contact import is the one moment you can fix a list cheaply. What to clean before loading, how to map fields, and why consent and source have to travel with the records.

How-toC

A contact import looks like a technical step and is actually the only cheap opportunity you will get to fix a list. Everything you load unexamined becomes the baseline: the duplicates, the people who left three jobs ago, the fields somebody once invented. Cleaning before the import costs an afternoon; cleaning afterwards is a project that gets abandoned halfway.

Before you import anything

  • Decide the identity rule — usually email address — and deduplicate the source file against it first.
  • Drop records with no usable contact method. They are not contacts, they are a list of names.
  • Standardise the obvious: country codes, company name spellings, title case on names.
  • Decide which fields you are keeping. An import is the moment to leave behind the twelve columns nobody has filled in since 2023.
  • Separate people from organisations if your destination models them differently, rather than discovering it mid-load.

Mapping fields without losing meaning

The dangerous mappings are the ones that almost fit. A "status" column from the old system dropped into a differently-defined status field produces records that look correct and mean something else, and nobody notices until a report is wrong. Where a field has no clean destination, put it in a notes field with its original label rather than forcing it, and map the ones that drive decisions first. Run a sample of fifty records end to end and read them as a human before loading the rest.

Consent and source must travel with the records. If the original system recorded where a contact came from and when they agreed to be contacted, carry both across — that evidence cannot be reconstructed later, and in most jurisdictions you need it before you send anything.

Running the contact import

  1. Import into a test environment or with a tag identifying the batch, so a bad load can be undone cleanly.
  2. Load fifty records, inspect them, then load the rest. The errors you find in fifty are the errors in fifty thousand.
  3. Keep the source file unchanged as a reference until you are confident, and note where it is.
  4. Assign an owner to every imported record rather than leaving a blank, because ownerless records are the ones that rot.
  5. Re-measure duplicates after the load; a rise means the identity rule was not enforced.

Afterwards

The import is also the moment to set the rule that prevents the next mess: one agreed identity field, enforced at creation, and a short list of required fields. Without that, the clean list you just loaded starts decaying immediately and you will be doing this again in two years with a larger file and less patience.

Ettex Contacts holds the result with an owner, source and consent date on every record, and a dormant state for contacts that stop responding. The ongoing side — duplicate rate, completeness, decay — is the routine described in crm data hygiene, which is what keeps an import from being a one-off heroic effort.

Frequently asked

Should I deduplicate before or after importing?

Before. Deduplicating in the source file is simple; merging inside a live system means reconciling history, ownership and anything already linked to the records.

What if a field has no equivalent?

Put it in notes with its original label rather than forcing it into a field that means something different. A near-fit mapping is worse than no mapping because nobody notices it.

Do I need to carry consent records across?

Yes, where you intend to contact people for marketing. Consent cannot be reconstructed after the fact, and the source and date are what evidence it.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.