Migrate from Method CRM to Salesforce Sales Cloud

Method Contact records map directly to Salesforce Contact. The primary fields (FirstName, LastName, Email, Phone, MailingAddress) use the same relational model on both platforms. We resolve the Parent Company lookup by matching Method's CompanyId against the migrated Account records. Custom fields on Method Contact (text, number, date, picklist) migrate as Salesforce custom fields (API name ends in __c) on Contact. If Method is on the Enterprise tier and the customer used the full contact schema, we preserve the Method contact record ID as a custom field method_contact_id__c for audit.

Method Company records map directly to Salesforce Account. The company name, website, phone, billing address, and shipping address transfer 1:1. We use the Company name as the Account Name for deduplication during import. Account is created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert. Method's Company record ID is preserved as account_method_id__c for reconciliation.

Method Opportunities map to Salesforce Opportunities with the stage name preserved as StageName and a custom field method_stage__c carrying the original Method stage label. The Amount, CloseDate, and Description transfer directly. We pre-create Salesforce Record Types and Sales Processes before migration so that each Method pipeline can map to a distinct Salesforce Record Type with its own stage probability matrix.

Method stores pipeline stages as picklist values with a configurable display name and order. Salesforce requires stages to be associated with a Record Type and Sales Process, where the Sales Process defines the allowed stage values and probabilities. We extract Method's pipeline stage names and probabilities, create a corresponding Salesforce Sales Process in the destination org, and whitelisted stage values become the allowed picklist values on the Opportunity Record Type. Stage probabilities migrate as decimal values between 0 and 1.

Method Activities (call, meeting, task) map to Salesforce Task and Event. Calls migrate as Task with TaskSubtype = Call; duration and disposition migrate to custom fields. Meetings migrate as Event with StartDateTime, EndDateTime, and Location preserved. Tasks migrate as Task with Status, Priority, and ActivityDate preserved. The WhoId on each record resolves to the migrated Contact's Salesforce ID using the method_activity_id__c cross-reference table. Owner assignment resolves by matching the Method user email against the Salesforce User table.

Method notes migrate to Salesforce Note records. The note body (rich text) transfers as the Note Body field. We link each Note to its parent record (Contact, Account, or Opportunity) via a ContentDocumentLink or the WhatId/WhoId fields. If the original note contains attachments, we migrate the attachments as ContentDocument records and link them to the same parent.

Method Estimates map to Salesforce Quote, which is available as a standard object from Salesforce Sales Cloud Professional. We preserve line items, quantities, unit prices, totals, and the estimate status. The PDF attachment on the Method Estimate migrates as a ContentVersion linked to the Quote via ContentDocumentLink. Note that Salesforce Quote requires an active Pricebook2; we create the Pricebook2 during migration and set it as the Opportunity's Pricebook2 before the Quote is inserted.

Method Invoices are QuickBooks-synced transactional records. Salesforce Sales Cloud does not have a native Invoice object without additional modules (Salesforce Billing or a third-party app). We map Method Invoices to a custom Invoice object (Invoice__c) with fields for invoice number, date, amount, status, and line items. If the customer uses Salesforce Billing, we map to the standard Invoice object. QB linkage metadata (QB entity ID, sync status) is preserved in custom fields on the migrated record for the customer's accounting team to resolve.

Method Sales Orders are available on Pro and Enterprise tiers and sync with QuickBooks. Salesforce Sales Cloud does not have a native Sales Order object. We map Sales Orders to a custom Sales_Order__c object with the same field schema, or to Opportunity Line Items if the customer's sales process treats Sales Orders as a closed-won pipeline artifact. The mapping decision is made during scoping based on the customer's reporting requirements. QB entity references are preserved in custom fields for accounting reconciliation.

Method Customer Cases are available on the Enterprise tier ($73/user/month). They map directly to Salesforce Case, which is available on all Salesforce tiers without additional cost. Case status, priority, description, and created date migrate directly. Method's case comments map as Salesforce CaseComments. If the customer uses Salesforce Service Cloud, Cases can include Entitlement Management and Multi-Channel capabilities; if using Sales Cloud only, Cases are available but without the advanced service features.

Method allows custom fields on standard objects (Contact, Company, Opportunity, Estimate, Invoice). Each custom field has a name, data type (text, number, date, picklist, checkbox, currency), and optional default value. We map each custom field to a Salesforce custom field on the equivalent object, using the same field label and API name where possible (adding __c suffix per Salesforce convention). Picklist values from Method map to Salesforce picklist values; multi-select picklists map to Salesforce multi-select picklists. We pre-create all custom fields in the destination org before any record migration begins.

Method Users map to Salesforce Users. We match by email address as the unique identifier. Any Method User referenced on a record (as owner or assignee) that does not have a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision. Active status, role, and profile do not migrate directly; the customer's admin assigns the appropriate Salesforce Profile and Role during provisioning. We flag any Method user with admin-level permissions for explicit attention during provisioning.

Method supports tagging Contacts and Companies for segmentation. Tags are flat string labels stored on the record. We preserve them as a multi-select picklist field on Contact (tag strings become picklist values), or as a Campaign with CampaignMember if the customer uses tags for marketing segmentation. The customer chooses the target model during scoping.

Method's Files API exposes binary file content and metadata. We extract file content, map the original filename and mime type, and upload to Salesforce as ContentVersion records. ContentDocumentLink associates each file with the correct parent record (Contact, Account, Opportunity, or Case) using the shared method_record_id__c cross-reference table built during migration.

Method Customer Portal access records (portal users, approved documents, access logs) are available on Enterprise tier via API. Portal user associations link to the corresponding Method Contact. We migrate these as Salesforce Contacts with a custom field portal_access__c set to true and portal_last_login__c carrying the last login timestamp. If the customer uses Salesforce Experience Cloud as the portal replacement, these Contacts can be enabled as Experience Cloud users with external licenses.