Data Import Acceptance: Reconcile Records Before You Approve a Migration

CodeMyTown publishes this original worksheet for buyers commissioning an import or evaluating an included import feature. We sell source code and frontend templates. The records and numbers below are synthetic acceptance examples, not customer migration results or an advertised import capability of a particular package.

Choose the unit of a record

Decide what one row represents before choosing a file format. A customer, an invoice and an invoice line have different relationships. Importing one row per line can legitimately produce fewer invoice records than file rows. Without that definition, a row-count comparison can label a correct import broken or hide a duplicated parent record.

Write down the matching key and who controls it. An external reference such as 00017 is often an identifier rather than a number to calculate with. Preserve its exact text if leading zeroes matter. Describe how the destination treats an absent field, an explicit empty field and a request to clear an existing value; they need not have the same business meaning.

Create a small fixture with deliberate exceptions

Start in an authorized staging installation with synthetic records and outbound effects disabled. For this example, one row represents one item adjustment, the quantity is a signed integer, and the external reference must be unique within the import job. The chosen rules are illustrative; agree your actual rules before implementing them.

Under that exact contract, four source rows produce two accepted adjustments and two rejected rows. The accepted quantity sum is eight. Five is not included merely because its row has a numeric quantity: it was rejected for its duplicate reference. An import report should make that reasoning visible instead of displaying a single unexplained “two errors” message.

Reconcile outcomes, keys and relationships

Record the original file hash or version, the mapping version, import-job reference, application release and operator. Then reconcile the mutually exclusive outcomes defined by your importer: for example, accepted, rejected and deliberately skipped. Their total should account for the source records under the chosen row model. Do not count the same rejected row again as a successful update.

Inspect the two accepted destination records through an authorized read. Confirm the references remain 00017 and 00018, the quantities retain their signs, and the records belong to the intended account or workspace. If the import creates child records, check their parent links as well as the total count. A correct global total can conceal a relationship assigned to the wrong customer.

Make parsing and validation separate checks

A file can parse successfully while violating a business rule. RFC 4180 describes common CSV field and quoting conventions; it does not determine your identifier types, duplicate policy, required fields or relationships. A column enclosed in quotes can still be inferred as a number by a later consumer.

Add fixtures for a comma inside a field, a quoted line break, non-ASCII text, a missing required column and an unexpected extra column. Count parsed records rather than physical newline characters. Specify the file encoding and what the importer does with invalid text. Keep the original file unchanged so a later investigation can distinguish the source from a transformed intermediate file.

Define size and row limits for the actual deployment, and ask how the user learns that a file exceeds them. Do not copy an arbitrary large benchmark from a sales page. Your acceptance case should reflect the permitted range and infrastructure in the agreed scope.

Test a repeat and a partial failure

Repeat the same fixture under the documented policy. The correct result might be rejection of an already processed job, an update of existing matches or a new explicitly authorized batch. Choose the intended behavior in advance. “We ran it twice and the total changed” is incomplete without knowing whether a second application was allowed.

Ask the developer to demonstrate a safe partial failure in staging. Which rows committed before the failure? Can the operator resume from a recorded point without duplicating them? Does the interface distinguish a fully rejected job from a partially applied job? An all-or-nothing transaction and a resumable batch have different evidence and recovery needs.

Keep correction and rollback responsibilities explicit. A backup does not automatically provide a selective undo for one import, especially after users make legitimate later changes. Agree how an affected record is identified and how a proposed correction is reviewed before applying it. Use the recovery worksheet to describe any environment restore separately.

Approve an explained result, not an animation

Finish with the source fixture, field mapping, outcome report, authorized destination checks, unresolved exceptions and named sign-off owner. Keep real customer data and credentials out of public tickets. A business owner should be able to explain why four source rows became two accepted records and two rejections before approving a larger run.

Use the evaluation pilot to establish whether an import is included, excluded or still untested. If a frontend displays an upload button but its backend is separately scoped, record that clearly in the API contract. StockNova's frontend page set does not include a production database or server-side import engine.