Migrate from Ascent360 to Salesforce Sales Cloud

Ascent360 Profiles map directly to Salesforce Contact. The Profile's primary email, phone, name, and address fields map to standard Contact fields. We preserve enrichment data (stay history, spend data, preference flags) as custom fields on Contact. Each Profile's unique ID is stored as an external ID field (asc360_profile_id__c) for reconciliation. Parent Account lookup is resolved by matching the Profile's company name against Account Name in Salesforce.

The company or property affiliation on an Ascent360 Profile maps to a Salesforce Account. We deduplicate Accounts by name during import and resolve the AccountId on each Contact at migration time. For multi-property operators, each property becomes a separate Account with its own contact roster. The Ascent360 Profile's source system identifiers are preserved in a custom field asc360_source_ids__c on Account for audit.

Ascent360 Profiles that represent unqualified prospects (pre-first-stay, marketing-only contacts) map to Salesforce Lead rather than Contact. The split rule is defined during scoping based on the customer's lifecycle data — any Profile with no booking history becomes a Lead. We preserve the original Profile ID in an external ID field on Lead for reconciliation back to Ascent360.

Ascent360 Segments define audience criteria (stay frequency, lifetime value, demographic, preference flags). Segment logic does not export as executable criteria. We reconstruct audience membership by extracting all Profile IDs associated with each Segment and creating Campaign Member records in Salesforce pointing to the appropriate Contacts. The Segment name becomes the Campaign name with a Segment-_ prefix for identification.

For hospitality operators using Campaigns as static audience lists rather than dynamic criteria, we map Ascent360 Segments to Salesforce Campaigns with Campaign Type = Static List. Each Profile in the Ascent360 Segment becomes a Campaign Member on the corresponding Salesforce Campaign, preserving the audience grouping intact.

Ascent360 Campaigns include email/SMS content, timing, and channel assignments. The campaign template library (Post-Stay, Birthday, Win-Back, Cross-Sell) does not export as portable objects. We migrate campaign metadata (name, start date, channel, associated segment) to Salesforce Campaign records. Email body content migrates as Salesforce EmailTemplate records if the content is available in the export; the customer's admin rebuilds the send cadence in Salesforce Flow or Marketing Cloud Account Engagement.

Open rates, click rates, delivery rates, and conversion data per Ascent360 Campaign migrate as Salesforce Campaign statistics fields (TotalSent, TotalDelivered, OpenCount, ClickCount, ConvertedCount). Historical performance that exceeds Salesforce's standard field capacity is delivered as a structured CSV for reimport into a custom Campaign Metrics report type.

Ascent360 allows customers to define custom fields on Profiles. These are sometimes excluded from standard bulk exports unless specifically requested. We run a pre-migration field audit against a sample export to identify all active custom properties. Each discovered custom property becomes a custom field on the Salesforce Contact object (__c API name), with field type mapped from the Ascent360 data type. Any custom properties missing from the initial export are flagged and a corrected export is requested before bulk migration begins.

Ascent360 Profiles and Segments carry tags for classification. We migrate tag assignments alongside Profile records as a custom multi-select picklist field tags__c on Contact. If tag counts exceed Salesforce's picklist limit, we create a separate Tag object with a junction to Contact and deliver a data dictionary mapping each tag to its frequency.

Ascent360's address data for direct mail campaigns comes from enriched Profiles. We migrate address fields to Contact.MailingAddress and, where the address represents a property or venue, to Account.ShippingAddress. Physical mail assets (design files, templates) are held content and do not migrate; we document which Campaigns referenced physical mail so the customer's admin can locate or recreate assets.

Abandoned cart recovery is a campaign type tied to eCommerce integration events. The campaign logic does not export. We migrate the integration event log — which contacts were in an active abandoned-cart sequence and at what stage — as Salesforce Tasks attached to the Contact, and create Opportunity records for high-value abandoned carts if the customer wants to track recovery in the pipeline. The eCommerce order context migrates as Opportunity custom fields.

Ascent360's 150+ integrations are connection credentials, not migratable data objects. The data ingested from those systems lives in the Profile record after enrichment. We migrate the enriched Profile data as Contact and Account fields. Historical PMS transaction data (stay records, room charges) migrates as Salesforce Activity history (Tasks and Events) linked to the Contact, with custom fields for stay type, room type, and charge amount. Historical POS data migrates as Opportunity custom fields or as a custom Transactions object if the volume warrants a dedicated object.

Ascent360 Profiles track a primary owner or assigned team member. We extract owner assignments and match by email against the Salesforce destination org's User table. Any Ascent360 owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner assignment migrates as Contact OwnerId and Account OwnerId.

Ascent360's daily enrichment processing appends cleansed and updated contact and behavioral data to Profiles. These enrichment fields (stay frequency, average spend, preference scores, churn risk flags) are read-only derived fields in Ascent360. We migrate all visible enrichment fields as custom fields on Salesforce Contact, prefixed with asc360_enrich_ to distinguish them from natively entered data. The customer should understand that these values represent a point-in-time snapshot; ongoing enrichment requires a new data feed or integration post-migration.