ETL Tips and Tricks (Checklist)

Confirm the purpose of the migration
Are you creating new records, updating existing ones, or both?
This determines whether you should use ALTERNATEID or FENXID as your unique identifier.
Only one identifier can be used per project.

Keep the migration policy minimal
Make sure the policy includes only the fields needed for this migration.
Remove unnecessary data requirements.
Fewer fields mean fewer mappings, fewer lookups, and fewer validation failures.

Confirm lookup structure in policy
Check that each datakey uses a single lookup list.
Avoid different lookup lists sharing the same datakey.
This prevents unpredictable lookup mapping issues later.

Choose your identifier once and do not change it
In Map System Fields, map only one:

Check datagroup alignment
If using ALTERNATEID → datagroups must use PARENTALTERNATEID.
If using FENXID → datagroups must use PARENTFENXID.
If this is misaligned, records will not link correctly.

Map all mandatory policy fields
If a required field is not mapped, Preview and Validation will not proceed.
Confirm all mandatory fields are populated in your CSV.

Review automapped values
Even if they are green, spot-check them.

Do not rely on one sample record
Review multiple sample entities in Preview.
Also manually search for a specific ID with known edge-case data.

Run validation after every structural change
If you change mappings, policy fields, datagroups, or datasource — revalidate.

Download the validation report
Even if validation passes, keep the report for traceability.
It shows what was checked and against which migration ID.

Fix issues in the source file where possible
It is cleaner to correct data in the CSV than to compensate with policy changes.

Confirm identifier case consistency
ALTERNATEID comparison is case-sensitive.
ABC123 and abc123 are different.
A mismatch can create new records instead of updating.

Confirm no unintended policy changes were made
If the policy was edited after validation, you must revalidate before loading.

Confirm datagroup behavior
When migrating datagroups, existing datagroups may be overridden.
Ensure this is intended before loading.

Clone instead of editing active projects
If major changes are needed, clone the project rather than modifying a validated one.
This protects your audit trail and reduces rework.

Separate entity types where possible
Avoid mixing Company and Individual in the same migration unless required.
It reduces aggregation complexity and ambiguity risks.