Migrate from Practice Master Pro to Salesforce Sales Cloud

Practice Master Pro's CMCLIENT stores both client identification (name, address, industry) and matter details (matter number, description, billing amount, status). We split CMCLIENT into two Salesforce objects: Account for firm/client information and Opportunity for matter-level data. Matter number is preserved in a custom Matter_Number__c field on Opportunity for cross-reference.

CMRELATE links contacts to matters using relationship type codes (Attorney, Paralegal, Client, etc.). Each contact first becomes a Salesforce Contact with an AccountId pointing to the primary matter's Account. Secondary matter associations become Account Contact Relations, and contact-to-specific-matter roles map to Opportunity Contact Roles using the CMRELATE relationship type as the Role field value.

CMFEES contains attorney/staff IDs, matter references, date, duration, billing rate, and total fee. Salesforce Sales Cloud has no native time-tracking object. We create a Time_Entry__c custom object with lookup fields to Contact, Account, and Opportunity. Duration and fee amounts map to custom number fields. If the firm uses Salesforce Billing Cloud, CMFEES data routes there instead.

CMCOST stores expense entries tied to matters — cost type, amount, date, matter reference, and staff ID. We map this to a custom Expense__c object in Salesforce with lookups to Account and Opportunity. Expense category values are mapped via value_mapping to a custom pick-list on the Expense__c record.

CMJRNL records are free-text journal entries with timestamps and author IDs. Each CMJRNL record migrates as a Salesforce Note attached to the relevant Account or Contact. Original timestamps and author IDs are preserved in custom datetime and text fields on the Note so audit trails remain intact in Salesforce.

CMCALENDAR contains event records with start/end times, subject, location, and staff/contact associations. Each record migrates as a Salesforce Event with the original start and end times preserved. Attendee associations map to EventWhoIds where a Salesforce Contact exists; unrecognized contacts are flagged for review.

Practice Master Pro matter status codes (Open, Closed, Pending, Billed, Written Off) map to Salesforce Opportunity StageName values via a value_map defined during discovery. Each mapping carries the original status code into a custom Legacy_Status__c field for continuity in pre-migration reports.

Practice Master Pro attorney IDs are internal codes, not email addresses. We resolve them by matching the attorney name in CMFEES/CMCOST against Contact names in the CMRELATE migration. Matched attorneys receive a Salesforce User record; their records are assigned OwnerId. Unmatched attorney IDs are flagged and assigned to a fallback Salesforce user for review.

Total expected billing per matter comes from CMCLIENT (FFEEAMT field). Individual time entries come from CMFEES. We aggregate CMFEES totals and store them as Opportunity.Amount if the firm uses Opportunity-level billing, and store individual line items in Time_Entry__c records. Any discrepancy between FFEEAMT and CMFEES sum is surfaced as a reconciliation warning before the migration commits.

Practice Master Pro stores creation timestamps in CMCLIENT. Salesforce's CreatedDate is set at migration time. We preserve the original practice management create date in a custom Original_Create_Date__c datetime field on each Opportunity and Account so historical reporting reflects when the matter actually opened.

Each Practice Master Pro file uses internal IDs (e.g., RECNUM, CLIENTID) to uniquely identify records and build relationships between files. We store these legacy IDs in custom text fields on every Salesforce record (e.g., Legacy_Client_ID__c, Legacy_Matter_ID__c) so the relationship graph can be audited post-migration and delta runs can reference source IDs for de-duplication.

CMRELATE supports multiple contacts per matter, and one contact can be associated with multiple matters (N:N). Salesforce Opportunity Contact Roles model one contact per Opportunity role, which satisfies the per-matter side. When one contact appears across multiple matters, we create one Opportunity Contact Role per matter-contact pair. If a contact has no Salesforce Contact record yet, we create a Contact stub and flag it for data completion.