Migrate from Wintouch CRM to Salesforce Sales Cloud

Wintouch Contact records export from the UI at Contacts > Options > Export Contacts with standard fields (name, email, phone, address) mapping directly to Salesforce Contact fields. We identify all custom fields on the Contact object during discovery and create equivalent custom fields in Salesforce before migration. Wintouch's owner field (the user who created or owns the contact) resolves to Salesforce User via email match; any unresolved owners land in a reconciliation queue for the customer's admin to provision before record import proceeds.

Wintouch Account records (supporting B2B and B2C types with multiple contacts and addresses per account) map to Salesforce Account. Address normalization is required for international accounts — Wintouch stores addresses with legacy formatting that we clean (removing packed digits, correcting date-in-address issues) before mapping to Salesforce BillingAddress and ShippingAddress compound fields. The Account is created before any Contact import so that AccountId lookup is satisfied at Contact insert time.

Wintouch Lead records include custom web form capture data and auto-assignment workflow associations. Lead-to-contact conversion logic in Wintouch is application-layer workflow logic and does not export as data — we document the conversion workflow during scoping so the customer's admin can configure Salesforce Lead Status, Assignment Rules, and Flow-based lead routing post-migration. The original lead score, source, and campaign attribution migrate as custom fields on the Salesforce Lead record.

Wintouch Activity records (completed tasks and scheduled work) migrate to Salesforce Task. Activity date formats carry legacy IBM iSeries date conventions (CCYYMMDD packed decimal) that we normalize to Salesforce-compatible ISO 8601 format during the transform phase. Owner assignment (user who logged the activity) resolves to Salesforce OwnerId via the User mapping. We agree with the customer on open versus completed task filtering before migration and migrate both sets with Status preserved as Completed or Not Started respectively.

Wintouch pipeline stages are customizable per organization. Stage names and ordering are mapped explicitly to Salesforce Opportunity Stage values and whitelisted within a Sales Process that we configure in Salesforce before Opportunity import. Historical deal stage history (if stored as a time-stamped activity log in Wintouch) migrates as Salesforce OpportunityHistory records to preserve the full pipeline progression timeline. The customer approves the stage mapping table during the discovery phase.

Wintouch Deals attach to Accounts and Contacts and carry custom fields for deal value, close date, and pipeline stage. We map Wintouch deal records to Salesforce Opportunity with AccountId resolved from the Account mapping, StageName resolved from the pipeline stage mapping table, and Amount mapped to Amount. OwnerId resolves via the User mapping. Closed-Lost and Closed-Won timestamps migrate to CloseDate and StageName destination values respectively.

Wintouch allows per-object custom field creation across Contacts, Accounts, Activities, Leads, and Deals. Each custom field must be identified individually during scoping, audited for type (dropdown vs. free text, date vs. datetime, numeric vs. currency), and mapped to an equivalent Salesforce custom field of matching type. Fields with no corresponding destination object are archived rather than silently dropped. We deliver a written inventory of all custom fields migrated, all custom fields dropped, and the rationale for each decision.

File attachments stored within Wintouch are not covered by a documented bulk export endpoint. We extract available attachments via available file paths and map them to Salesforce ContentDocument records via ContentVersion (file body) and ContentDocumentLink (linking the document to the parent Contact, Account, or Opportunity). We flag any attachments that cannot be extracted due to inaccessible file paths during the discovery audit and agree on a handling path with the customer before production migration.

Wintouch can generate latitude/longitude coordinates for addresses but only within North America. International addresses (Europe, APAC, LATAM) may lack geo-coordinates in Wintouch. We flag all records with missing geo-data during extraction and either populate a placeholder or omit the field, depending on the customer's preference. Post-migration enrichment tools (e.g., Salesforce Maps, Data.com, Clearbit) can fill missing coordinates after cutover if the customer requests a separate enrichment scope.

Wintouch stores one-click report definitions and customized report layouts in a centralized repository as application-state data. These definitions cannot be exported in a standard export. We extract the underlying record data that feeds the reports (Contacts, Accounts, Deals, Activities in scope for migration) so that the customer can recreate equivalent reports in Salesforce Reports and Dashboards after migration. We deliver a written list of all Wintouch reports identified during scoping, their source objects, and their current filters, which the customer's admin uses as a blueprint for the Salesforce report rebuild.

Wintouch's automation engine — rules that auto-assign leads, fire follow-up sequences, and update pipeline stages — lives in the application layer and is not record-level data. We document every automation trigger during scoping: trigger object, condition criteria, resulting actions, and estimated Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds these in Salesforce Flow post-migration. This documentation deliverable is included in the migration scope; the rebuild itself is outside scope.

Wintouch Owner records (users who created or own Contacts, Accounts, Deals, Activities) map to Salesforce User via email address as the dedupe key. We extract every distinct owner referenced across all migrating objects and match by email against the destination Salesforce org's User table. Owners without a matching Salesforce User go to a reconciliation queue — the customer's admin provisions missing Users (active or inactive depending on whether the Wintouch user is still employed). Migration cannot proceed past this step because OwnerId references are required on standard Salesforce objects.