Migrate from Sunbase Data to Salesforce Sales Cloud

Sunbase unified contact model stores Leads, Contacts, and Clients in a single object with role assignments (prospect, customer, partner). Salesforce requires splitting unqualified prospects into Lead and qualified contacts into Contact attached to Account. We define the split rule during scoping using Sunbase's contact status and source fields, compute the split at migration time, and preserve the original Sunbase contact status in a custom field sunbase_contact_status__c on both Lead and Contact for audit. Any Sunbase contact linked to an active Deal migrates as a Contact with AccountId resolved; unlinked contacts with early-stage status migrate as Leads.

Sunbase Clients represent the business entity side of the relationship and map directly to Salesforce Account. Sunbase Client records include business name, address, industry classification, and tax ID where configured. We use the business name as the Account Name and preserve the Sunbase client ID in a custom field sunbase_client_id__c for reconciliation. Client records without a business name (individual clients) map to Salesforce Account Name using the individual name and are flagged for manual review.

Sunbase Deals track the sales pipeline including proposals, quotes, and stage history. We map Deal values, stage names, close dates, and probability percentages. Sunbase's pipeline board configuration does not migrate; we recreate Opportunity Record Types and Sales Processes in Salesforce based on the documented pipeline stages from Sunbase. Custom deal fields migrate as custom Opportunity fields (__c). Closed-Lost and Closed-Won reasons from Sunbase custom properties become Salesforce Loss Reason and Won Reason fields.

Sunbase Leads captured through door-to-door sales forms, web capture, or manual entry migrate to Salesforce Lead. Lead source, status, assignment data, and any scoring values transfer to corresponding Salesforce Lead fields. Sunbase leads tied to automation workflows are flagged with a custom field sunbase_automation_source__c indicating the originating workflow for the admin's rebuild reference.

Sunbase Projects represent installation or job-site operations specific to solar, roofing, or construction. We migrate project metadata, status, budget tracking, and linked work orders into a Salesforce custom object Project__c created during schema design. If the destination org includes Service Cloud, Work Orders map to Salesforce Cases with a Work Order Record Type, and the Sunbase Project becomes the Case's parent record via a lookup. Project status from Sunbase becomes a custom picklist on Project__c or Case Status.

Sunbase Work Orders include permit info, task details, attachments, system specifications, and linked employee assignments. We preserve the full work order record including linked crew assignments and scheduling data. If Service Cloud is not included in the destination org, we create a custom WorkOrder__c object with fields for permit_number__c, system_specs__c, crew_id__c, and a lookup to Project__c. Attachments migrate as Salesforce Files (ContentDocument) linked via ContentDocumentLink.

Sunbase generates invoices including repeat invoices and financing-related billing. We extract invoice line items, payment status, total amount, and linkage to the originating project or client. Invoice data migrates to a custom Invoice__c object with a lookup to Account and Project__c. Historical paid invoices preserve their payment status and dates; financing-related billing records include financing_terms__c from Sunbase custom fields.

Sunbase Employee records include HR data, crew assignments, and GPS location history. Salesforce User represents platform users (sales reps, admins), not full HR records. We migrate Sunbase Employees who are Salesforce users by email match. Crew assignment data, role assignments, and GPS trail data (where available) migrate to a custom Employee__c object linked to the User record. Full HR data (payroll, benefits, PTO) does not migrate because Salesforce is not an HRMS.

Sunbase Appointments sync with Google Calendar and include customer-linked scheduling. We preserve appointment dates, times, assigned contacts, location, and status. Calendar linkage (Google Calendar sync) does not transfer; Salesforce Event records are created standalone and the customer reconfigures any calendar integration post-migration. Appointment status from Sunbase maps to Salesforce Event Status or a custom picklist.

Sunbase Documents include contracts, financing applications, permits, and photos stored within the platform. We extract binary files and preserve filenames, upload dates, and associations to the parent record (Contact, Deal, Project, Work Order). Documents migrate as Salesforce Files attached via ContentDocumentLink to the corresponding Lead, Contact, Account, Opportunity, or Project__c record. Large binary attachments (photos, site surveys) may require chunked upload via Salesforce Bulk API 2.0.

Sunbase Asset and Inventory records track materials, equipment, and supplies across projects. We preserve item names, quantities, linked projects, supplier information, and inventory levels at migration time. Equipment and materials used in project work orders map to a custom Asset__c object with a lookup to Project__c. Stock inventory items with SKU and pricing may map to Salesforce Product2 if the customer intends to use Salesforce for quoting and pricing.

Sunbase supports custom fields within most objects, but field definition metadata (field name, type, validation rules, display order) is not exported alongside data. We extract field values but require the customer to provide a custom field manifest during scoping. We recommend a field-mapping session before migration to confirm Salesforce field types for each Sunbase custom field value. Custom field values that do not have a corresponding destination field land in a staging custom text area for manual review post-migration.

Sunbase pipeline configurations (visual sales boards, stage definitions, and workflow automations) are stored in the platform's internal workflow engine and cannot be exported as structured data. We document pipeline stages and deal statuses from Sunbase during scoping, then create Salesforce Record Types and Sales Processes that match the stage names. Stage probability percentages transfer to StageProbability on the Sales Process. The customer rebuilds automation triggers in Salesforce Flow using the documented logic.

Sunbase workflow automation rules (email triggers, task assignments, stage-change actions, follow-up sequences) are not exposed via any export mechanism and cannot be migrated as functional rules. We document the automation logic manually during scoping: trigger conditions, actions, delays, and recipients. This becomes a written Flow inventory document that the customer's admin or a Salesforce partner uses to rebuild triggers in Salesforce Flow post-migration. Active workflow status is flagged on each migrated record for reference.