Migrate a CRM export into a verified database

Why use this

1. A CRM export can contain duplicate people, missing identifiers and fields whose meaning changed over time. Loading it into a cleaner schema without an explicit mapping can silently alter ownership, relationship history or downstream update behavior.

2. A dry-run mapping packet could surface those decisions before database writes. Reviewers could distinguish recoverable formatting changes from ambiguous merges and confirm how rejected records would be handled rather than discovering problems through downstream synchronization.

Why an agent / simpler alternative

Useful judgment

Explain ambiguous field mappings and inconsistent record relationships while preserving source lineage.

Simpler alternative

Use a deterministic importer when the export already matches a stable schema and duplicate rules are agreed.

Unsuitable when

No backup, schema owner or isolated validation destination is available.

Proposed inputs

1. Name

   CRM export sample

   Owner

   Data owner

   Minimum scope

   Deidentified rows with source IDs and field definitions

   Quality check

   Identify missing keys, duplicates and prohibited fields.

2. Name

   Destination specification

   Owner

   Database owner

   Minimum scope

   Schema, constraints and downstream sync rules

   Quality check

   Separate approved changes from proposed migrations.

Access and setup — proposed or unknown

Proposed minimum

1. Local sample copies and a mapping preview without database credentials.

Compatibility unknowns

1. Unknown: current runtime, database connector, import transaction behavior and sync side effects.

External actions requiring approval

1. Schema changes, imports, merges, production writes and enabling downstream synchronization.

Expected deliverable and review checks

Proposed artifact

Field mapping, proposed schema diff, row-level disposition and reconciliation checklist.

Critical checks

1. Source row counts reconcile with accepted, rejected and unresolved rows.

2. Relationship keys and required fields are preserved or explicitly flagged.

Missing output evidence

No new workflow run or output inspection is performed for this editorial layer. The linked implementation evidence retains the original source-specific outcome and artifact limits.

Failure signals and proposed responses

1. Signal

   Two customers share an email but have different source IDs.

   Why it matters

   A convenient deduplication rule could merge unrelated records.

   Proposed response

   Keep both unresolved and require an owner-approved identity rule.

2. Signal

   An import would trigger outbound synchronization.

   Why it matters

   A local correction could spread an unreviewed change.

   Proposed response

   Pause the import proposal and document isolation and reconciliation requirements.

Effort and cost — unknown

Setup work

1. Define field meanings, rejection handling and rollback evidence.

Ongoing review

1. Resolve ambiguous rows and reconcile approved batches.

Unknowns

1. Unknown: data-cleaning effort, database charges and synchronization constraints.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Six fictional CRM rows include a shared email, missing company key and field value outside the proposed enum.

Acceptance checks

1. Preserve all source IDs.

2. Quarantine ambiguous rows and show a complete count reconciliation.

Stop conditions

1. Real customer data, database writes or sync execution is needed.

Limits

1. Dry-run mappings and isolation safeguards are proposals; an approved mapping still needs separate import and downstream-effect checks.