An import reporting success only proves that a command finished. It does not establish that contacts belong to the right accounts, open work was preserved or rejected rows were reviewed. Agree what reconciliation evidence means before choosing a cutover date.
Related service: CRM, ERP and web application development- 01Profile source records.
- 02Map fields and relationships.
- 03Run a controlled trial.
- 04Reconcile accepted and rejected rows.
- 05Capture final changes and approve cutover.
SECTION 01
Map records before formatting the upload file
Identify which source owns a company, contact, opportunity and activity. Preserve a source identifier alongside the destination identifier so later corrections do not depend on matching a person's name. Define how blank values, unknown list entries, inactive users and duplicate organizations are handled.
Choose a sample that includes awkward records, not just complete recent entries. Database constraints can reject broken references, but a valid reference may still point to the wrong company. Review the mapping with staff who recognize the business context. A small set of manually checked account histories can reveal errors that aggregate counts will not show.
SECTION 02
Illustrative example: contacts with ambiguous company names
Imagine a source sheet has two businesses with the same trading name in different regions. Contacts are linked by company-name text. A trial import creates valid records but assigns several contacts to the wrong business. This hypothetical example shows why a technically successful import is not enough.
The team resolves the company identifiers before retrying. The second trial keeps a rejected-row report for unresolved contacts rather than silently creating a third company. Test that rerunning the same corrected file updates the intended records instead of producing duplicates. Keep source references so reviewers can explain every accepted and rejected row.
SECTION 03
Plan the changes that happen after the trial
Decide whether source editing stops for a window or whether a final change set will be captured. Record the cutoff and who authorizes it. A backup and a restore procedure should be part of the plan, but do not promise an effortless rollback after staff have begun editing both systems.
Ask for reconciliation by record type, key relationship and selected business totals. Check open tasks, ownership and relevant history using real roles. Begin with one team or record family where a staged migration is practical. Existing import tools may be sufficient if they offer the required mapping and evidence; custom migration work is justified by gaps in those controls, not by the desire for a new upload screen.
SECTION 04
Frequently asked questions
Are matching record counts enough?
No. Counts can match while records are attached to the wrong accounts or fields are misinterpreted. Check relationships and representative histories too.
What should happen to a rejected row?
Keep its source reference, error reason and correction owner. Do not silently discard it or invent a default that changes its meaning.
Can we rerun the final file?
Only with a defined duplicate-prevention or update rule. Test repeat imports using stable identifiers before relying on reruns during cutover.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Database constraintsPostgreSQL
- Transaction isolationPostgreSQL
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy