External IDs and upsert for preserving record relationships
Key Takeaway
Store each legacy ID in a custom External ID field with Unique ID set. Then upsert, and link each child to its parent by the parent's External ID value instead of its Salesforce ID.
Salesforce links related records by their Salesforce IDs. The target org gives every loaded record a new ID, so links from the legacy system break unless you remap them. An External ID field stores each record's legacy ID. Upsert uses that value to update a matching record or create a new one. Upsert can also link a child to its parent through the parent's External ID. Together they keep parent-child links intact without hand-matching old IDs to new ones.
Why IDs must be remapped
Salesforce keeps record relationships through each record's unique Salesforce ID, not through record names. Records loaded into a target org get new IDs. So the legacy IDs in your import files must be replaced with the target org's IDs to keep related records correctly associated.
The common way to remap IDs is to match each legacy ID to its new target ID, for example with Excel's VLOOKUP. You then update every related import file with the new IDs.
When matching IDs that way is not practical, create a custom External ID field. Fill it with each record's legacy ID or another unique identifier. Then import related records using External ID relationships, which means each child row refers to its parent by the parent's External ID value.
For example, if Oracle Financials links with Salesforce, an External ID field on Account can capture and display each account's Oracle ID.
A legacy ID can sit in a plain custom field. Setting External ID on that field also indexes it. The index makes relationships easier to maintain and validation reports easier to build.