Migrate from Customer Database App to Salesforce Sales Cloud

Customer Database App Contact records map directly to Salesforce Contact, with a required Account parent. We extract the company or organization name from the corresponding custom field (commonly named Company, Organization, or Business), create a Salesforce Account for each distinct value, and link the Contact to that Account. If no company field is populated, we create a single Default Account and attach all Contacts to it, flagging each record for manual review post-migration. Email, phone, address, and all standard fields map directly to their Salesforce equivalents.

If the source data includes a status or stage field that distinguishes between active customers and prospective leads, we split: records marked as prospects or leads map to Salesforce Lead; records marked as customers map to Contact. We define the split rule during scoping based on the actual field values present in the exported CSV. The original source status is preserved in a custom field cdba_original_status__c on both Lead and Contact for audit trail.

Each user-defined text field from Customer Database App maps to a Salesforce Text custom field on Contact (or Lead if the split applies). We infer the full field list from the CSV column headers, map field names to valid Salesforce API names (removing spaces, special characters, and truncation to 40 characters), and create each field in the destination org before import. Free-text fields with embedded commas are quoted during CSV generation to prevent parse errors.

Date fields from Customer Database App map to Salesforce Date custom fields on Contact. We validate date format consistency across all records before import; if the source data mixes DD/MM/YYYY and MM/DD/YYYY formats, we apply a format-detection heuristic based on value ranges and normalize before loading.

Numeric and currency fields map to Salesforce Number or Currency custom fields. We preserve decimal precision from the source and set the scale and precision properties in Salesforce to match. Empty numeric fields default to null rather than zero to maintain data integrity.

Boolean or toggle fields in Customer Database App map to Salesforce Checkbox custom fields. We normalize any text representation of true/false (yes/no, 1/0, active/inactive) to Salesforce's native true/false during the transform step before CSV generation.

Customer Database App Kanban pipeline stages map to Salesforce Opportunity Stage values. We extract all distinct stage names from the exported data, create corresponding Stage entries in the destination org's sales process, and map the order to StageSortOrder in Salesforce. If no deal or pipeline data exists in the source, we skip this mapping and document that the customer will create their Salesforce pipeline from scratch.

Customer Database App groups and tags are stored as comma-separated strings on each contact record. We split each comma-separated value into individual tokens, create Salesforce Topic records for each distinct tag, and link each Contact to its topics via TopicAssignment. Alternatively, if the customer prefers a simpler model, we map tags to a multi-select picklist custom field on Contact. The customer selects the strategy during scoping.

Customer Database App birthday date fields map directly to Salesforce Contact.Birthdate, which is a standard date field with no special API handling required. We preserve the original date exactly as exported; no transformation needed beyond format normalization if the source uses a non-ISO date format.

Contact images exported from Customer Database App are bundled into a ZIP archive alongside the CSV. We extract each image file, upload it as a Salesforce ContentVersion record, and create a ContentDocumentLink linking the file to the corresponding Contact record. Image file naming must follow a predictable convention (Contact ID or email-based) for us to match images to records; if the naming is inconsistent, we deliver a reconciliation report with unmatched files for manual assignment.

PDF exports of individual Customer Database App records are bundled alongside the CSV export. We upload each PDF as a ContentVersion, create a ContentDocumentLink pointing to the corresponding Contact, and set the ContentDocument Description to 'Migrated from Customer Database App' for identification. If the PDF filename does not encode the contact identifier, we rely on the customer-provided mapping file to match PDFs to records.

Customer Database App notes migrate to Salesforce Note records. We extract the note body and title from the CSV (if exported as structured columns) or parse them from a supplemental notes export. Each Note is linked to its parent Contact via ContentDocumentLink. Note timestamps are preserved in the Salesforce Note CreatedDate field.

Tasks created within Customer Database App migrate to Salesforce Task records linked to the parent Contact. Task Subject, Status, Priority, and ActivityDate are preserved. Task owner resolves by email match against the destination Salesforce User table; unresolved owners are placed in a reconciliation queue for the customer's admin to address before record import continues.

Voucher balances are not exported via Customer Database App's CSV or VCF format. Vouchers are app-specific objects with no standard CRM equivalent. We do not migrate voucher data. We recommend exporting a supplemental voucher CSV manually from the app (if accessible) and re-entering balances in Salesforce as a custom object or as a custom field on Contact. This is documented in the migration scope as an out-of-scope item requiring manual action.

Caller-ID logs and call history are device-level transient records not exposed via Customer Database App's CSV or VCF export. These records are not migrated. We recommend documenting call-handling procedures and any external call logs (from a connected phone provider) separately, and re-importing call logs from the telephony source directly into Salesforce if the customer has a connected VoIP or call tracking system.

Customer Database App does not track record-level ownership in the same way as Salesforce, but if the export includes an owner or assigned-to field, we resolve each value by email against the destination Salesforce User table. Users without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision before record import resumes. If no ownership field exists in the source, all migrated records default to the migration service user and the admin assigns ownership post-migration.