Migrate from Atendare to Salesforce Sales Cloud

Atendare Contacts store lifecycle information through a stage property. If the customer uses lifecycle stages to distinguish prospects from customers, we apply a split during migration: lifecycle stages indicating unqualified prospects map to Salesforce Lead; stages indicating qualified buyers map to Salesforce Contact attached to an Account. We preserve the original Atendare stage value in a custom field original_lifecycle_stage__c on both Lead and Contact for audit and reporting continuity. If Atendare does not use a lifecycle stage property, all Contacts migrate as Salesforce Contacts by default, which is the most common pattern.

Atendare Company records map directly to Salesforce Account. Company name becomes Account Name; company domain or website becomes Account Website. We use Company ID as the dedupe key during import. Account is created before Contact import so that the AccountId Lookup is satisfied at the moment of Contact insert. Company-level custom properties map to custom Account fields, which we pre-create in the destination schema during scoping.

Atendare Deals map to Salesforce Opportunity. Deal value maps to Amount; expected close date maps to CloseDate; owner maps to OwnerId via User email match. Pipeline-specific stage names from Atendare require mapping to Salesforce StageName values, which we configure via a Record Type and Sales Process in the destination org before migration. Atendare does not expose deal probability as a standard field; if the customer uses manual probability estimates, we create a custom probability__c field.

Atendare Pipelines define the stages a Deal moves through, with stage names and ordering varying by account configuration. Each Atendare Pipeline maps to a Salesforce Record Type on Opportunity with a corresponding Sales Process that whitelists the mapped stage values. Stage ordering is preserved; stage probability percentages migrate from Atendare to Salesforce StageProbability (rounded to integers). This configuration happens in a Sandbox org before production migration.

Atendare tracks multiple activity types linked to Contacts and Deals. Call activities map to Salesforce Task with TaskSubtype = Call; disposition and duration migrate to custom Task fields. Meeting activities map to Salesforce Event with StartDateTime, EndDateTime, and Location preserved; attendees link via EventRelation records to the related Contact or Lead. Task activities map directly to Salesforce Task with Status, Priority, and ActivityDate preserved. All Activity timestamps migrate to preserve the historical timeline ordering. Owner assignments migrate by resolving the Atendare owner reference to Salesforce OwnerId.

Atendare users assigned as Deal owners and Activity owners map to Salesforce User records. We resolve by email match against the destination org's User table. Any Atendare User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Atendare users are migrated as inactive Salesforce Users to preserve historical attribution.

Atendare custom fields on Contacts, Companies, and Deals vary by account configuration. We detect all custom property definitions during discovery, map each to a typed Salesforce custom field (Text, Number, Date, Picklist, Checkbox, etc.) with a __c suffix, and pre-create the schema in the Sandbox before migration. Multi-value custom properties map to Multi-Select Picklist. Custom properties with no Salesforce equivalent (e.g., Atendare-specific metadata) are flagged for the customer to decide whether to include or drop.

Atendare Contact segments defined by filter rules migrate as saved filter criteria. We extract the segment definition as written filter logic and deliver it as a configuration document. At the destination, segments are rebuilt as Salesforce Campaigns (for contact lists used in outreach tracking) or as Salesforce Lists (dynamic or static) based on the customer's use case. We do not execute the segment logic during migration because filter criteria in Atendare may reference fields that transform during migration.

Atendare maintains a Product Catalog linked to Proposals and Deals. Product names, SKUs (from Atendare's product code field), pricing, and descriptions migrate to Salesforce Product2 records with Standard Pricebook entries created during import. Product-to-Deal associations migrate as OpportunityLineItem records where the customer uses Atendare's line item features. If Atendare's product catalog is large or frequently updated, we flag it as a recurring sync candidate post-migration.

Proposals are Enterprise-tier objects in Atendare and include line items, totals, and status. They map to Salesforce Quote (a standard object available from Professional tier). We extract proposal records where the API exposes the data, migrate line items to QuoteLineItem, and attach the proposal as a ContentDocument on the related Opportunity. Signed or pending status migrates as QuoteStatus. If the API does not expose proposal body content, we migrate the proposal metadata (name, value, dates, related Opportunity) and flag the body content for manual handoff.

Atendare email marketing campaigns (Pro and Enterprise tiers) are migrated as Salesforce Campaign records with Campaign Member status tracking. Campaign names, target segment definitions, and send dates migrate. Actual email body HTML is extracted where the API exposes it and attached as a ContentDocument or documented for rebuild in Salesforce Marketing Cloud or Content Builder. This requires vendor verification per account because no public API documentation was found for Atendare's campaign object.

Atendare landing pages built in the platform's page builder are hosted assets with no standalone data model exposed via documented API. We do not migrate landing page content. We flag their existence during discovery and recommend the customer export HTML content manually via the platform's built-in export (if available) or plan to rebuild at the destination using Salesforce Experience Cloud or a third-party builder. The written inventory document we deliver includes a list of all Atendare landing page URLs for the customer's marketing team to catalog.

Contracts are Enterprise-tier objects in Atendare. We extract contract records as metadata (contract name, related account, status, dates) and attempt to retrieve attached PDF documents via the API where access is confirmed. Contract PDFs migrate as ContentDocument records attached to the related Account via ContentDocumentLink. If the API does not expose contract attachments, we flag the contract records for manual retrieval and document the manual steps in the handoff inventory.