Rehearse a CSV Import Before Changing Live Business Records

Moving customer or service records from a spreadsheet into business software is a data change, not simply a file upload. A file can open successfully while identifiers lose leading zeros, dates change meaning, and existing customers become duplicates. A rehearsal should reveal those outcomes before anyone touches live records.

Start with a small synthetic CSV, an agreed mapping, and a preview of the intended changes. The deliverable is a decision about whether the import rules are safe enough to proceed, supported by records you can inspect.

Specify the file contract before choosing the file

List the columns, their meaning, which are required, and the expected encoding and delimiter. State whether the file includes a header. Treat identifiers such as customer codes as text when their exact characters matter. Decide how blank cells differ from instructions to erase an existing value.

RFC 4180 describes a common CSV format, including quoted fields containing commas, line breaks, or quotation marks. It is informational and acknowledges differences among implementations. “CSV” alone is therefore not a complete agreement between exporter and importer.

Write one example value beside every ambiguous column. A date such as 04/05/2027 is insufficient without a convention. Agree on an unambiguous format, and decide what the importer does with a value that does not match it.

Build a small file that challenges the rules

Use invented people and records. Include ordinary rows alongside cases that expose parsing and business-rule mistakes:

• A customer code such as 00042, which must retain its leading zeros.
• A business name containing a comma and a contact name containing an accent.
• A quoted note containing a line break.
• A missing required identifier and an impossible date.
• Two rows with the same matching identifier but different phone numbers.
• A row matching an existing test customer and another representing a genuinely new customer.
• A blank optional field on a row that matches a populated destination record.

Keep the expected outcome beside each case in a separate test record. Do not quietly correct every awkward row before testing; the point is to learn whether the importer rejects, explains, or mishandles it.

Decide how rows match existing records

Choose the authoritative matching key with the business owner. A name can change, and two people can share one. An email address may be absent or shared. If the source and destination use different identifiers, document the cross-reference rather than guessing.

Define insert, update, unchanged, and rejected outcomes. If two source rows target the same destination, decide whether the entire batch stops or those rows require review. Avoid silently letting the later row win unless that is an explicit requirement.

For the blank phone number, a reasonable policy might preserve the existing number unless an explicit clear instruction is supplied. Another workflow may require different behavior. The acceptance criterion is that the chosen policy is documented and demonstrated, not that every business uses the same rule.

Preview changes before applying them

A useful rehearsal preview shows which records would be inserted, changed, skipped, or rejected, with row references and reasons. For updates, make the previous and proposed values inspectable by an authorized reviewer. The totals should reconcile to the number of parsed data rows.

Review a representative record from each category. Check the customer code, date, accented name, multiline note, and blank-field behavior. Confirm that a parsing error has not shifted data into neighboring columns.

Define the failure boundary too. If processing stops halfway, will the batch roll back, retain a clearly identified partial result, or resume safely? Run the interruption case in the test environment. A promise of “all or nothing” needs evidence from the actual importer.

Reconcile and rehearse recovery

After applying the test batch, compare expected source identifiers with destination identifiers. Counts alone cannot detect one missing record offset by one duplicate. Inspect changed values and confirm that rejected rows did not modify existing data.

Repeat the same file. Under the agreed matching policy, it should produce the expected unchanged or controlled-update result rather than accidental duplicates. Record how a corrected rejected row can be resubmitted without replaying unrelated work.

Before a live import, identify the approver, affected records, recovery method, and verification owner. A batch marker or change log can help locate the import's effects, but recovery must respect legitimate edits made afterward. Do not describe a backup as a tested rollback unless restoration has actually been rehearsed.

Contact Dynelink to turn a planned spreadsheet migration into explicit mapping rules, a reviewable preview, and a reconciliation exercise. The examples here are hypothetical test data, not client migration results.