Map the columns in your export

Your export has whatever headers your old system used. This is how those become fields.

How to do it

Upload the file. The screen reads your headers and proposes a mapping for the ones it recognises: "Contact name" to full name, "Mobile" to phone, and so on.

Then you decide. Every column ends up in one of two states: mapped to a field, or explicitly ignored with a reason. There is no third state and no default.

Why it proposes and does not decide

Header names are close enough to guess and not close enough to trust. Two systems both use "Reference" and mean unrelated things. A guess that is right nine times out of ten produces one silently wrong field in a file of forty thousand rows, and the wrongness is discovered by a client.

So the guess is a starting point on a screen you confirm, and the confirmation is the record of what was decided.

What blocks the run

Two things, and both are named rather than counted.

An unplaced column. A header nobody mapped and nobody ignored. The screen lists it by name. Ignoring it is one click, and the reason you type is kept.

A required field with no column. A contact with no name or no email is not a contact. The screen names the field, not the number of problems.

What proves it worked

The import will not start while either exists. Press run with an unplaced column and you get its name back, not an error code.

When your headers are the same as last time

The mapping is saved as a profile against the source, so the second import of the same export does not repeat the exercise. A changed header shows up as a new unplaced column rather than being quietly absorbed, which is the behaviour you want the day your old system renames something.

Data arriving from a feed rather than a file

Same accounting, same completeness rule. A feed has no headers to map, so the mapping is stored against the source instead, and it is checked by the same function. A feed cannot skip a rule a spreadsheet has to satisfy.