Migrate from Mobile Service App to Freshsales

Mobile Service App customers contain both person and organization data in a single record. We split by type: individual customers map to Freshsales Contacts, while business-name customers map to Freshsales Accounts with the contact person also created as a linked Contact. The source customer ID is preserved as Source_System_ID__c on both records for traceability.

The job record is the central entity in Mobile Service App but has no direct Freshsales equivalent. We map jobs to Freshsales Deals, using custom fields (Job_Status__c, Service_Type__c, Scheduled_Date__c, Completed_Date__c) to preserve job lifecycle data. Job name becomes the Deal name; job amount maps to Deal Amount; job close date maps to Close Date. Each job carries its linked customer as the Deal's primary Account.

Mobile Service App job statuses (Scheduled, En Route, On-Site, Completed, Invoiced) map value-by-value to Freshsales Deal stage values. We use a custom stage set for service jobs rather than a standard sales pipeline, because the open/close semantics differ from a sales-close workflow. Stage-transition timestamps migrate as custom datetime fields.

Each service task (repair, inspection, installation) on a Mobile Service App job maps to a Freshsales Sales Activity record linked to the migrated Deal. Activity type (call, email, meeting, task) is set based on the service task category. Original timestamps and technician name migrate as activity owner. Task description migrates as Sales Activity notes.

Mobile Service App technicians are operational actors, not CRM users in most deployments. We resolve technician email against Freshsales Users for matching — if a technician has a Freshsales login, their records map to User; otherwise, the technician name and contact info migrate as a Technician__c custom field on the Deal. Your admin chooses the preferred resolution rule before migration runs.

Equipment records in Mobile Service App carry model, serial number, install date, and warranty status. Equipment details map to custom fields on the linked Account (Equipment_Type__c, Serial_Number__c, Install_Date__c). If the equipment is a serviceable product (with a SKU and price), it also creates a Product record in Freshsales linked as a Deal Product on the associated job-Deal.

Job location addresses migrate to Freshsales Account address fields (Address, City, State, Zip, Country). Geo-coordinates from Mobile Service App's dispatch data map to custom Number fields (Latitude__c, Longitude__c) on the Account, enabling Freshsales-integrated map views if your team has the appropriate integration configured.

Job photos, signatures, and documents attached to Mobile Service App records migrate as Freshsales Files linked to the corresponding Deal. File size limits per Freshsales plan apply (Growth: 2GB/user, Pro: 5GB/user, Enterprise: 100GB/user). Inline images from job reports are downloaded and re-uploaded as Files with original filenames preserved.

Mobile Service App custom fields at the job level (regional cost center codes, service-agreement IDs, dispatch region flags) migrate as custom fields on the Freshsales Deal object. Field type is preserved: text fields stay text, pick-list values become Freshsales pick-lists, date fields become date fields. Any field with a restricted value set requires value mapping before migration.

If Mobile Service App uses custom objects (extended equipment types, warranty records, contract terms), these map to Freshsales custom modules (Enterprise plan) or custom fields with note-based storage for Growth/Pro plans. We document the relationship model and recreate it as a custom object with lookup fields in Freshsales where the plan supports it.

Mobile Service App invoice records with line-item totals and payment status do not map to a native Freshsales object. Invoice amounts and payment status migrate as custom fields (Invoice_Amount__c, Invoice_Status__c) on the Deal. Full invoicing requires a separate accounting tool integration post-migration.

Mobile Service App user accounts map to Freshsales Users by email match. Unmatched users are flagged before migration — either invite them to Freshsales first or assign their records to a fallback owner. Owner resolution is validated during the sample migration pass before the full run commits.