SF-Data-Arch Data Migration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a junction object between Provider__c and Patient_Visit__c, load the junction records with both legacy codes, and let Salesforce infer the lookups.

  Why it's wrong here

  A junction object is used to model many-to-many relationships, but a visit belongs to one provider, so this changes the data model unnecessarily. Salesforce does not infer lookups on junction records; each lookup still needs an ID or external ID value. This adds objects, storage, and reporting complexity without solving the original requirement.

• ✓

  Load Patient_Visit__c records with a lookup field populated by the legacy provider code, relying on the external ID field to resolve the relationship during the load.

  Why this is correct

  Salesforce resolves relationship fields by matching the value supplied in the relationship field against the target object's external ID field, so loading visits with the legacy provider code in the Provider__c relationship maps each visit to the correct Provider__c record without a prior ID export. This is exactly the pattern Bulk API 2.0 and Data Loader support for external ID lookups, and it scales for multi-million record loads.

• ✗

  Load Patient_Visit__c records into a staging custom object, then use a scheduled Apex job to copy each legacy provider code into a text field and later reconcile manually.

  Why it's wrong here

  Staging plus scheduled Apex adds latency, consumes Apex CPU and SOQL limits, and still leaves the relationship unresolved until a second pass runs. It does not actually use the existing external ID field to establish the lookup during load, and a manual reconciliation step is not viable for 8 million visits. This introduces unnecessary custom code and operational risk compared with a direct external ID lookup load.

• ✗

  Export all Provider__c records with their Salesforce IDs, VLOOKUP the IDs into the visit file, then load visits with the 18-character Salesforce ID in the lookup field.

  Why it's wrong here

  This approach works but is unnecessary given that Legacy_Provider_Code__c is already an external ID on Provider__c. Exporting and VLOOKUP-joining 8 million rows is error-prone, increases file size, and adds a manual step. External ID relationship loading is the supported, more reliable mechanism when a populated external ID already exists on the target object.