Migrate from The Practice to Salesforce Sales Cloud

The Practice client record maps directly to a Salesforce Contact. Salesforce mandates an AccountId on the Contact for most standard operations — if the client has no organization affiliation in Practice.do, FlitStack attaches them to a default 'Individual Client' Account created specifically during migration time to ensure referential integrity in Salesforce.

Practice.do stores the client's organization as a text field or reference on the client record. FlitStack first extracts unique organization names and migrates them as Salesforce Account records, then populates Contact.AccountId via lookup match on the Account Name field to establish the proper parent-child relationship between the two objects.

Each session log in The Practice becomes a Salesforce Event linked to the Contact via the WhoId field. Event.StartDateTime and Event.EndDateTime are populated directly from the session start time and duration fields; the original coach assignment is preserved in Event.OwnerId after email resolution to a matching Salesforce User record.

Follow-up items flagged in The Practice session notes migrate as Salesforce Tasks with Status, Priority, and ActivityDate fields populated from the source task status and due-date values respectively. The Parent WhatId field links the Task to the Contact record, maintaining the relationship between follow-up items and the client they belong to in Salesforce.

Any custom fields on the Practice.do client record (coaching program type, referral source, billing tier, etc.) require Salesforce custom fields to be pre-created with __c suffix before data loads. FlitStack delivers a custom-field creation plan as part of the pre-migration schema package.

Files attached to client records in Practice.do are re-uploaded as Salesforce Files using the ContentDocument and ContentVersion object structure, then linked to the Contact record. Salesforce enforces a 25MB per-file limit on uploads — any files exceeding this threshold are flagged before migration commits so your team can decide how to handle them.

Practice.do coach assignments are resolved by matching coach email addresses against the Salesforce User list. Unmatched coaches are flagged and reported before migration runs — your team either creates Salesforce User accounts for them in advance or assigns their clients to a designated fallback OwnerId during the migration process.

Practice.do client tags are migrated to a custom multi-select pick-list or text field (Cohort_Tags__c) on the Contact object, with the choice between field types depending on the total count of distinct tag values in your data. We surface the distinct tag count before migration so you can choose the most appropriate Salesforce field type for your needs.

If The Practice stores invoice or payment data, FlitStack maps this to either a custom Billing_History__c object or to Opportunities depending on your preferred Salesforce data model for financial records. Standard Salesforce objects do not have native fields for storing legacy payment records without custom configuration on your part.

Salesforce's native CreatedDate and LastModifiedDate fields are set automatically at the time of API insert and reflect the migration load timestamp rather than the original client onboarding date. FlitStack preserves the original values in Original_Create_Date__c and Original_Last_Modified__c custom fields to ensure reporting continuity and historical accuracy in your Salesforce org.

Phone numbers stored in Practice.do are distributed to Salesforce's standard phone fields based on the type tag if Practice.do differentiates between landline, mobile, and work numbers. When type differentiation is not available, all phone numbers land in Contact.Phone and a note is added to the mapping plan for your admin to review after migration.

Session reminder emails, client onboarding sequences, and task-creation automations built in The Practice do not have a direct equivalent in Salesforce and are not migrated. FlitStack exports the automation definitions as a structured JSON reference file that your Salesforce admin can use as a rebuild specification when implementing equivalent functionality in Salesforce Flow.