Client Database Migration: Map Fields and Check Results
Moving a client database requires more than matching column headings. You need to decide how accounts connect to people, what happens when records already exist, and how to prove that the import preserved the information you intended to move.
At Latest Mailing Database, we suggest a written field map before any bulk import. It gives the team a shared record of the decisions that software cannot make reliably from a column name alone.
Build a field map that includes the meaning
| Incoming field | Destination | Decision to document |
|---|---|---|
| Company | Account name | Is this a legal name, trading name, or branch label? |
| Contact | Contact display name | Does one cell contain one person or several? |
| Updated | Source update date | What event caused this timestamp? |
| Opt out | Relevant suppression setting | Which channel and purpose does the restriction cover? |
A blank source field should not automatically erase a populated destination field. Decide which system is authoritative for each field and how conflicts are queued for review.
Define a stable matching rule
An existing client ID is usually a better starting point than a name. If IDs differ between systems, keep a cross-reference table linking the old and new values. Retain that mapping after migration so historical reports can still be interpreted.
Email addresses require context. A shared address may represent several people or branches, while one client may have several addresses. Treat an email match as evidence to review rather than universal proof that two accounts are identical.
Reconcile a small test import
Consider a hypothetical batch of 50 incoming contact rows. If 30 create records, 15 update records, and 5 enter a review queue, all 50 rows have a documented outcome. This reconciliation shows processing coverage. It does not prove that every imported value is correct.
Inspect examples from each outcome, including records with missing values, shared contact channels, and existing restrictions. Check associations as well as the visible values: a correct phone number attached to the wrong client is still an import error.
Keep an import reference and a rollback plan
Retain the original export, mapping decisions, import timestamp, and IDs created or changed. Where the software supports it, take a recoverable backup before the migration. Confirm how you would undo newly created records without deleting legitimate work entered afterward.
Disable automated campaign triggers during testing. A database transfer should not silently start sending messages because an imported status activated an automation.
Know where the database design ends and selection begins
DB TO DATA’s database structure guide explains accounts, contacts, and activity records. This migration checklist focuses on transferring those relationships without losing their meaning.
If the incoming file is a new audience purchase, use our demonstration-file request to review the proposed columns before ordering. Keep external prospecting records separate from your client histories until your matching and use decisions are complete.