Migrate from Customer Database App to Microsoft Dynamics 365 Sales

Customer Database App contacts map to either Dynamics 365 Contact (for established customer records) or Lead (for records that represent unqualified prospects still in the early pipeline). We apply a qualification split using the contact's group membership and any pipeline stage label: contacts assigned to a sales stage label or a customer group map to Contact; contacts with no stage assignment and a prospect group label map to Lead. The original Customer Database App record ID is preserved in a custom field cda_original_id__c on both Lead and Contact for cross-reference. Where Customer Database App exports a single flat record, D365 requires a parent Account for Contacts, so we create a placeholder Account using the contact's company name or 'Individual' for sole-proprietor records.

The company name field in Customer Database App maps to the Account Name field in Dynamics 365. Where the source record has no company name (sole proprietor records), we create an Account named after the contact's full name for the parent relationship. Account.Phone maps from the source phone field; Account.Website maps from the source website field if present. Account is created before the Contact import so that the AccountId lookup on Contact is satisfied at insert time.

Every active field in the Customer Database App CSV column header becomes a custom field in Dynamics 365. We infer the data type from the first 20 non-null values in each column: numeric strings become Decimal or Integer fields; date-format strings become Date fields; yes/no or boolean strings become Two Option fields; everything else becomes Text (255). D365 requires custom fields to be created in the solution before data import begins, so we provision the full schema during the scoping phase and deploy it to the destination org before any records load. Free-text fields containing commas are sanitized to prevent CSV parsing issues during import.

Customer Database App stores groups and tags as comma-separated label strings on each contact record. We split these into individual values and map them to a D365 multi-select picklist custom field (cda_tags__c) if the count of distinct tags across all records is under 200 unique values (D365's picklist limit). If the tag vocabulary exceeds 200 unique labels, we map to a plain text field and recommend using D365 Topics (on the Ideas or Topics tab of Contact) for future tag governance. We preserve the original comma-separated string in a text backup field cda_original_tags__c.

Customer Database App Kanban pipeline stages are stored as a label string on the contact record. We map these to a custom text field cda_pipeline_stage__c on Contact or Lead during initial migration, preserving the exact stage label. The customer's Dynamics admin then rebuilds these as Opportunity Stages (if converting to Opportunities) or as Lead Status values within a D365 Sales Process. We document the full stage list with record counts in the migration scope deliverable so the admin can configure the Sales Process correctly.

The birthday date stored on Customer Database App contacts maps to the standard Birthdate field on the D365 Contact record. D365 does not have a separate birthday notification workflow, but the date is available for segmentation in D365 Reports and Dynamics 365 Customer Insights. If the destination org does not have the Birthdate field enabled, we create a custom date field cda_birthday__c as a fallback.

Customer Database App exports individual record PDFs and contact photos as separate files. We bundle these into a ZIP archive alongside the CSV and attach each file to the corresponding Contact record in D365 as a Note with an file attachment (Annotation). File naming convention uses the contact's original record ID to enable programmatic matching. Where the contact splits into a Lead and a Contact during qualification, we attach the file to the Contact record and add a Note reference on the Lead pointing to the Contact.

Vouchers are a standalone object in Customer Database App with no direct equivalent in Microsoft Dynamics 365 Sales . Voucher balances are not exported via CSV and the object has no exportable schema. We do not migrate voucher balances or usage history. We recommend exporting a supplemental voucher report directly from Customer Database App as a separate CSV for manual re-entry in a custom D365 entity if the customer's business requires tracking voucher data.

Call history and caller-ID logs in Customer Database App are transient device-level records that are not exported via CSV, VCF, or MySQL sync. We do not migrate call history. We recommend documenting call-handling procedures separately for the customer's admin to configure D365 phone integration (Dynamics 365 App for Outlook or a third-party telephony connector) post-migration.