Migrate from Handyman to Salesforce Sales Cloud

Handyman customer records map directly to Salesforce Account. Business name maps to Account.Name, website to Account.Website, industry to Account.Industry (value-mapped to Salesforce's pick-list), and annual revenue to Account.AnnualRevenue. Customer create_date is preserved in a custom datetime field since Salesforce CreatedDate reflects migration time.

Handyman contact records associated with customers map to Salesforce Contact with AccountId populated from the parent Account. First name, last name, email, phone, mobile phone, job title, and address fields map directly. Contacts without a customer parent link land on a default Unassigned Account record or get flagged for manual assignment before the full run.

Handyman work orders map to Salesforce Opportunities using a Field_Service record type created specifically for migrated jobs. job_name maps to Opportunity.Name, total_amount to Opportunity.Amount, status to Opportunity.StageName via a value-mapping table (Pending → 'Prospecting', In Progress → 'Value Proposition', On Hold → 'Id. Needs Analysis', Completed → 'Closed Won'), and customer_id resolves to AccountId through the customer-to-account email match.

Handyman uses four static stages with no probability weight. Salesforce Opportunity Stage requires per-value probability and ForecastCategory. FlitStack builds a mapping table during planning: Pending → Prospecting at 10%, In Progress → Value Proposition at 25%, On Hold → Id. Needs Analysis at 50%, Completed → Closed Won at 100%. Stage-changed timestamps from Handyman are stored in a custom datetime field for audit continuity.

Salesforce requires a record type so that work-order-specific fields are scoped to a page layout and pick-list values are isolated from other Opportunity types. FlitStack creates a Field_Service record type before migration, assigns it to the appropriate profiles, and maps all work orders to that record type during the load so field-level security applies correctly.

Handyman line items (parts, labor, materials) map to Salesforce Opportunity Products. Each unique part_name in Handyman requires a corresponding Salesforce Product, then a PriceBookEntry linking it to the active price book. quantity and unit_cost map to Quantity and UnitPrice on OpportunityLineItem. The migration builds a Handyman Imports price book if no existing catalog matches the parts list.

Handyman technician records have no Salesforce CRM equivalent. FlitStack migrates them as Contacts with a custom Role__c pick-list field set to 'Technician'. technician_email is matched to an existing Salesforce user by email; unmatched records are flagged before migration so your team either invites the technician as a Salesforce user or assigns their work orders to a fallback owner.

Handyman file attachments on work orders (photos, signed forms, diagrams) re-upload as Salesforce Files linked to the parent Opportunity. File size limits of 25 MB per file apply — larger files are flagged for chunking. Inline images in notes are extracted and re-hosted as Salesforce Files with the note preserved as a ContentNote record.

Handyman job notes and internal comments migrate as Salesforce Tasks (Type = 'Call' for verbal notes, Type = 'Email' for written updates) linked to the Opportunity. Timestamps and owner information are preserved. Notes with rich-text formatting become Salesforce ContentNote records attached to the opportunity.

Any Handyman custom fields per object — service_address, job_type, service_category, priority_level, customer_rating — require Salesforce custom fields with the __c suffix created in Setup before data loads. The migration plan audits all custom fields during discovery, creates them with the correct data type (text, pick-list, number, date), and maps them field-by-field during the load run.

Handyman work-order owner_id resolves by email match against Salesforce users. If a Handyman owner email matches a Salesforce user record, OwnerId is populated directly. Unmatched owners are flagged before migration — your team either creates Salesforce users for them or assigns their work orders to a designated fallback owner before the full load runs.

Handyman generates its own internal record IDs for all objects. These are stored in custom text fields (Source_System_ID__c) on the corresponding Salesforce record so delta-run deduplication works correctly and your team can cross-reference the source record if a discrepancy surfaces after go-live.