Migrate from Sercom to HighLevel

Sercom customer profiles map directly to HighLevel contacts. Every contact receives a primary email, phone, name, and address. If Sercom stores multiple contacts per customer account, secondary contacts are created as additional HighLevel contact records linked to the same company, preserving original create dates and allowing tag inheritance for segmentation.

Sercom sites or service locations map to HighLevel companies because HighLevel's Company object supports multiple address fields (billing and shipping), which aligns cleanly with Sercom's location model. Each unique Sercom location becomes one Company record, and we preserve location hierarchy so that contacts can be linked to the appropriate site for dispatch and service reporting.

Sercom work orders are multi-field records with status, priority, assigned technician, and line items. HighLevel has no native work order object, so we map work orders to HighLevel Opportunities with a parallel Work_Order__c custom object linked via relationship fields. Status maps to Opportunity Stage; priority becomes a custom pick-list field.

Sercom asset records (equipment name, serial number, install date, maintenance schedule) have no direct HighLevel equivalent. We create a custom Asset__c object in HighLevel and link each asset to the associated Company or Contact record using a lookup relationship. Additional fields such as equipment type, warranty expiration, and last service date are mapped as custom attributes for complete service history continuity.

Sercom technician profiles (name, role, certifications, availability) map to HighLevel user accounts. FlitStack matches Sercom technician email addresses to existing HighLevel user emails for owner resolution. Unmatched technicians are flagged and assigned to a fallback owner, while role and certification data are stored in custom user fields to support dispatch and compliance reporting.

Sercom service history entries (visit notes, parts used, completion comments) map to HighLevel Notes attached to the relevant Opportunity or Asset record. Timestamps and technician attribution are preserved as Note metadata, and each note can be linked to the corresponding work order custom object for a complete chronological service log.

Any Sercom custom fields tracking FSM-specific data (e.g., dispatch zone, service tier, SLA bucket, parts inventory reference) are created as custom fields in the corresponding HighLevel object. Field types are matched: pick-lists become pick-lists, text becomes text, dates become date fields.

Sercom file attachments on work orders or assets are downloaded and re-uploaded to HighLevel Files, attached to the corresponding Opportunity or Asset record. File metadata such as original upload date and author are preserved, and file size limits follow HighLevel's storage policy of 25 MB per file to ensure successful upload and retrieval.

Sercom tags used to categorize customers, jobs, or assets migrate as HighLevel Tags applied to the corresponding records. Tag names are preserved exactly as they appear in Sercom, and each record can receive multiple tags to reflect its original classification and support filtering in HighLevel's pipeline and reporting views.

Sercom invoices and billing records have no native HighLevel equivalent because HighLevel lacks a built-in billing module. We create an Invoice__c custom object and map fields such as invoice number, amount, date, and payment status as custom attributes, linking each invoice to the relevant Company or Contact for straightforward reconciliation and reporting.

Sercom work order line items (parts, labor, travel) are stored as a related list in Sercom. In HighLevel, these are represented either as a JSON-formatted text field on the Work_Order__c custom object or broken into individual line-item custom fields, depending on the volume and complexity, ensuring that all cost components are preserved and queryable.

Sercom SLA fields (response time commitment, coverage hours, contract tier) have no native HighLevel equivalent. We create SLA__c as a custom pick-list or text field on the Company or Work_Order__c object, preserving the original SLA terms and linking them to the relevant service records for compliance tracking and client reporting.