A spreadsheet import reports success, yet the customer records are wrong. Phone numbers lost their leading characters, dates changed meaning, and a second upload created additional records. The useful acceptance question is whether the intended business data arrived correctly, not whether a progress bar finished.

This guide helps UAE teams brief a developer before importing customer, supplier or product data into business software. It focuses on controlled bulk imports; the integration retry and duplicate-record guide addresses ongoing event delivery.

The artwork is a conceptual import-validation workbench, not a product screenshot or an actual ITZ migration.

Agree the mapping and matching rules

Write down each source column, destination field, type, required status and transformation. Decide which key identifies an existing record and whether a row should create, update or be rejected. A person's display name alone is usually a weak business identifier; choose a rule appropriate to the actual dataset.

Include examples involving international phone formats, Arabic and English text, blank values, dates and decimal amounts. Specify whether a blank source value should erase existing information or leave it unchanged. These are business decisions that should be approved before a script encodes them.

Keep the source and the test environment controlled

Preserve an authorised, dated source copy and work from a separately identified import file. Record the import batch and who approved it. Limit access to personal data and use synthetic records for initial testing whenever practical.

Use an isolated test environment with the relevant schema and rules. Disable or redirect outgoing messages and downstream actions during tests. A harmless-looking customer import can otherwise trigger welcome emails, tasks or external synchronisation. Do not assume a database copy isolates every integration.

Custom software development for controlled data workflows can turn these requirements into an import process with clear validation and exception handling. Plan Your Business Data Import Review to discuss source formats, matching rules and the destination system without attaching customer lists to the initial enquiry.

Make invalid rows visible

Microsoft's model-driven app import guidance describes mapping data and reviewing import results, including error rows. The available controls depend on the selected product and import route; a custom importer needs its own equivalent evidence.

As a proposed design, validate required identifiers, field lengths, permitted values and references before committing changes. Give every rejected row a clear reason and a source-row reference. Avoid a process that silently drops a field or substitutes an unexplained default.

Separate warnings from blocking errors. For example, an optional category may be reviewable while an unknown account identifier blocks a financial relationship. The data owner should approve that distinction rather than letting implementation convenience decide it.

Test duplicate behaviour explicitly

Microsoft's duplicate-detection documentation explains rule-based matching and notes that simultaneous processing can still create duplicates. An enabled detection feature is not evidence that your particular upload, record type and concurrency pattern are protected.

Include a repeated source row, two rows matching one existing record, a changed identifier and a second run of the same batch. Specify the expected result for each. Do not rerun an entire failed file until you know which rows already committed successfully.

Reconcile results before calling the import complete

  • Account for every input row as created, updated, rejected or intentionally skipped.
  • Compare representative destination values against the approved mapping.
  • Check relationships, ownership and visibility from an ordinary user's account.
  • Confirm that totals or other relevant control values reconcile.
  • Resolve or formally accept exceptions before handing the dataset to staff.

Counts alone are insufficient: the correct number of records can still contain incorrect values. Record the batch, mapping version, observed results and approving owner so a later issue can be investigated.

Define recovery before production

Agree a recovery method appropriate to the application and test it. Deleting everything carrying an import label can also delete valid later work or trigger further actions. The backup restore testing guide helps assess recovery evidence, while software consulting can clarify dependencies and release decisions.

Plan Your Business Data Import Review to discuss mappings, validation, duplicate handling, reconciliation and a controlled production run. A successful import should leave an explainable dataset and an accountable handover.

Official Microsoft documentation reviewed 25 October 2026. The acceptance cases and reconciliation process are proposed methods, not measured migration results.