CRM migration

Migrate from Comarch Field Service Management to Salesforce Sales Cloud

Field-level mapping, validation, and rollback between Comarch Field Service Management and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.

Comarch Field Service Management logo

Comarch Field Service Management

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

100%

12 of 12

objects map 1:1 between Comarch Field Service Management and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

48–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Comarch Field Service Management operates as an ERP-adjacent FSM suite with deep integration into back-office systems, featuring work order dispatch, technician scheduling, mobile field execution, and inventory management across large field-service operations. Salesforce Sales Cloud, when augmented with Field Service Lightning, models field operations through WorkOrder, ServiceResource, ServiceAppointment, and Asset objects with a scheduling engine that relies on Service Territory and Skills-based matching. The migration carries Comarch's service records, asset registry, resource roster, and parts usage into Salesforce's object graph — but the scheduling logic, dispatch rules, and routing preferences are destination-side configurations that require manual rebuild. The primary complexity is translating Comarch's proprietary work order hierarchy (header-line-item-task structure) into Salesforce's WorkOrder-to-WorkOrderLineItem model while resolving Comarch technician IDs to Salesforce User or ServiceResource records by email match. We use Comarch's API export for work orders, assets, resources, and contracts, transform the payload into Salesforce Bulk API format, and run a delta-pickup window (24–48 hours) to capture any records modified during the cutover before committing the full load.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Comarch Field Service Management logo

Comarch Field Service Management

What's pushing teams away

  • Quote-based pricing with no public tiers makes budget forecasting difficult, and renewal negotiations often result in significant cost increases without clear justification.
  • Enterprise-grade complexity means implementation timelines stretch to 12–18 months with heavy professional services involvement, creating dependency on Comarch consultants.
  • Interface design lags behind newer FSM competitors, with users reporting clunky navigation on the dispatcher side and slow mobile sync in low-connectivity areas.
  • Customization depth requires developer-level access for non-standard workflows, making day-to-day admin changes slow and dependent on technical staff.
  • Integration Hub dependencies can create lock-in; breaking apart connected Comarch ERP or CRM modules during migration requires careful schema extraction.

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How Comarch Field Service Management objects map to Salesforce Sales Cloud

Each row shows how a Comarch Field Service Management object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Comarch Field Service Management

Work Order

maps to

Salesforce Sales Cloud

WorkOrder

1:1
Fully supported

Comarch work orders map 1:1 to Salesforce WorkOrder. The WorkOrderNumber in Salesforce auto-generates unless the source system's work order ID is preserved as a custom field (Original_Work_Order_ID__c). Scheduled date maps to Salesforce's ServiceDate field. Dispatch status maps to Salesforce's Status field using value mapping (Comarch status codes → Salesforce picklist values).

Comarch Field Service Management

Work Order Line Item

maps to

Salesforce Sales Cloud

WorkOrderLineItem

1:1
Fully supported

Comarch task-level line items within a work order map to Salesforce WorkOrderLineItem records linked by WorkOrderId. Each line item inherits the parent work order's AccountId and AssetId. Line item status, duration, and description map to WorkOrderLineItem's Status, Duration, and Description fields respectively. Unit price maps to UnitCost if parts billing is tracked.

Comarch Field Service Management

Customer / Account

maps to

Salesforce Sales Cloud

Account

1:1
Fully supported

Comarch customer records map to Salesforce Account. The Account object is created before WorkOrder records because WorkOrder requires an AccountId foreign key. Comarch's customer billing address maps to Account.BillingAddress; service site address maps to Account.ShippingAddress or to a separate Location record if geo-coordinates are required for Salesforce's Service Territory model.

Comarch Field Service Management

Equipment / Customer Asset

maps to

Salesforce Sales Cloud

Asset

1:1
Fully supported

Comarch equipment records linked to customers map to Salesforce Asset. The Asset's AccountId links it to the customer Account, and the InstallDate, Status, SerialNumber, and Product2Id fields map directly. Comarch maintenance history maps to a custom field (Last_Maintenance_Date__c) or to the Asset's related Entitlement records if SLA terms are preserved.

Comarch Field Service Management

Technician / Field Worker

maps to

Salesforce Sales Cloud

ServiceResource

1:1
Fully supported

Comarch technicians cannot map directly to Salesforce User — they first need to exist as Salesforce Users (or be created as such) before a ServiceResource record can link to them via the RelatedRecordId field. We match Comarch technician email addresses to existing Salesforce Users. Unmatched technicians are flagged for admin decision: invite them to Salesforce first or assign to a fallback ServiceResource.

Comarch Field Service Management

Service Resource Skills

maps to

Salesforce Sales Cloud

SkillRequirement

1:1
Fully supported

Comarch skill certifications attached to technicians map to Salesforce SkillRequirement junction records on ServiceResource. The SkillId field references a Salesforce Skill object that must be pre-created (e.g., 'HVAC-Certified', 'Electrical-Licensed'). Each skill assignment from Comarch creates a SkillRequirement record linked to the migrated ServiceResource.

Comarch Field Service Management

Schedule / Dispatch

maps to

Salesforce Sales Cloud

ServiceAppointment

1:1
Fully supported

Comarch dispatch records (technician assignments with time windows) map to Salesforce ServiceAppointment linked to the WorkOrder. The scheduled start/end times from Comarch map to ServiceAppointment's SchedStartTime and SchedEndTime. The assigned technician maps via ServiceResourceId. ServiceAppointment status maps from Comarch dispatch status using value mapping.

Comarch Field Service Management

Parts / Inventory Item

maps to

Salesforce Sales Cloud

Product2 + WorkOrderLineItem

1:1
Fully supported

Comarch parts catalog items map to Salesforce Product2 records with IsActive=true and a PricebookEntry linked to the org's standard pricebook. Parts consumed on a work order line item map to WorkOrderLineItem with QuantityUsed and UnitCost. Bin location and warehouse ID from Comarch map to custom fields on Product2 (Bin_Location__c, Warehouse__c) since Salesforce's Location object is optional and requires additional setup.

Comarch Field Service Management

Service Contract / SLA

maps to

Salesforce Sales Cloud

Entitlement + Contract

1:1
Fully supported

Comarch service contracts with SLA terms map to Salesforce Entitlement and Contract objects. The Contract object holds the commercial terms (start/end dates, contract type), while the Entitlement object defines SLA rules (response time, resolution time) that can be linked to the Asset or Account. Comarch SLA priority levels map to Entitlement.Priority using value mapping.

Comarch Field Service Management

Service Territory

maps to

Salesforce Sales Cloud

ServiceTerritory

1:1
Fully supported

Comarch regions or zones map to Salesforce ServiceTerritory records. Each ServiceTerritory has an OperatingHoursId reference and optionally a ParentTerritoryId for nested hierarchies. If Comarch stores geofence polygon data (lat/long bounds), that data can be stored as custom geometry fields on ServiceTerritory or as a custom Location-based object for use with Salesforce FSL's routing engine.

Comarch Field Service Management

Checklists / Service Report Templates

maps to

Salesforce Sales Cloud

WorkOrderLineItem + Custom Object

1:1
Fully supported

Comarch service checklist templates attached to work orders need reconstruction in Salesforce. The checklist structure (ordered steps with pass/fail or value-capture fields) can be modeled as a custom Checklist_Response__c object linked to WorkOrderLineItem, or stored as JSON in a custom Long Text Area field. We preserve the template name and the completed responses as structured field-value pairs.

Comarch Field Service Management

Customer Signature

maps to

Salesforce Sales Cloud

ContentVersion + Custom Field

1:1
Fully supported

Comarch e-signature captures from field technicians map to Salesforce Files (ContentVersion/ContentDocumentLink). The signature image is uploaded as a file linked to the WorkOrder. We also create a custom boolean field Signed_in_Field__c on WorkOrder to flag records where a signature was collected, and a custom date field Signature_Captured_Date__c for timestamp preservation.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Comarch Field Service Management logo

Comarch Field Service Management gotchas

High

Quote-only pricing hides true cost of migration

High

Integration Hub creates soft data lock-in

Medium

Custom user-defined fields require schema inspection

Medium

Historical schedule records are date-sensitive

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • Comarch technician IDs do not map directly to Salesforce ServiceResource records — email match is required first

    Comarch FSM stores technicians as internal FSM records with their own ID scheme. Salesforce requires a ServiceResource record linked to a Salesforce User via the RelatedRecordId field. We resolve this by matching Comarch technician email addresses to existing Salesforce Users. Unmatched technicians are flagged before migration — your admin must either invite them to Salesforce first or assign them to a fallback ServiceResource owned by a system user. Without this step, dispatch assignments on migrated WorkOrders will have null ServiceResourceId values, breaking the technician-to-work-order link in Salesforce's FSL Gantt.

  • Comarch work order hierarchies require careful parent-child sequencing in Salesforce

    Comarch FSM supports multi-level work order nesting (parent work order → sub-work orders → tasks). Salesforce's WorkOrder object is flat — hierarchy is modeled through WorkOrderLineItem records or through separate parent WorkOrder and child WorkOrder objects with a ParentWorkOrderId field (available in FSL). If Comarch uses sub-work orders, we map each sub-work order as a separate WorkOrder record with ParentWorkOrderId populated, which requires parent records to insert before children. Circular reference detection runs on the Comarch export to flag any orphaned or recursive nesting before the Salesforce load begins.

  • Comarch SLA and contract terms require reconstruction using Salesforce Entitlement and Contract objects

    Comarch stores SLA terms (response time, resolution time, priority escalation rules) as part of its contract configuration. Salesforce models SLA enforcement through the Entitlement object linked to Account or Asset, with Milestone triggers defined in Entitlement Processes. The migration carries Comarch's SLA tier name and numeric thresholds into a custom pick-list field (SLA_Tier__c) and maps the contract start/end to Contract.StartDate and Contract.EndDate. Milestone definitions, business hours, and entitlement processes must be configured by your Salesforce admin post-migration — FlitStack delivers an Entitlement setup plan as part of the migration package.

  • Comarch mobile e-signature captures need Salesforce Files reconstruction

    Comarch's mobile app collects customer e-signatures on service completion as image blobs or PDF attachments. Salesforce WorkOrder has no native e-signature field. We re-upload each signature as a Salesforce File (ContentVersion) and link it via ContentDocumentLink to the WorkOrder record. A custom boolean field Signed_in_Field__c on WorkOrder marks which records have a captured signature. Your admin may also want to enable Salesforce's built-in Digital Signature feature or integrate DocuSign for a more robust signing workflow — we provide a rebuild reference for the signature process.

  • Comarch dispatch rules and routing preferences have no Salesforce equivalent and must be rebuilt

    Comarch's scheduling engine applies dispatch rules based on technician skills, geographic proximity, workload balancing, and priority-based bumping — all configured within Comarch FSM. Salesforce FSL uses Scheduling Policies (work rules + service objectives) to guide its optimization engine, but these are defined entirely in the destination org and have no data-level equivalent in Comarch. We preserve the skill-technician mapping and territory assignment in our migration data, which becomes the input for rebuilding Scheduling Policies in Salesforce FSL. However, the optimization logic (how the engine chooses one technician over another) must be reconstructed by your Salesforce admin using FSL's Scheduling Policy Work Rules and Service Objectives.

Migration approach

Six steps for a successful Comarch Field Service Management to Salesforce Sales Cloud data migration

  1. Audit Comarch FSM data model and export API capabilities

    We connect to Comarch's API (or request a bulk data export) and inventory the full object inventory: work orders, line items, technicians, skills, assets, parts, contracts, and service appointments. We profile record counts, identify null rates on critical fields (e.g., technician email, asset serial number), and surface any custom fields or extended attributes unique to your Comarch configuration. This audit produces a source-system data quality report and flags any objects that cannot be exported via Comarch's standard API — some legacy Comarch FSM configurations may require CSV export for certain objects.

  2. Design Salesforce schema: objects, fields, record types, and entitlements

    Based on the Comarch audit, we produce a Salesforce schema setup plan: which custom fields to create on WorkOrder, WorkOrderLineItem, Asset, and ServiceResource; whether to use record types for different work order categories; how to structure Service Territories and Operating Hours; and which Entitlement Processes to configure for SLA enforcement. We deliver field-level mapping documentation, a custom field creation checklist, and a Salesforce admin handoff guide so the destination schema is built before any data is loaded.

  3. Resolve Comarch technicians to Salesforce Users and ServiceResource records

    We run an email-matching pass across Comarch technician records against your Salesforce User list. Matched records get a ServiceResource with RelatedRecordId pointing to the existing User. Unmatched technicians are flagged in a resolution report — your admin either invites them to Salesforce first or designates a fallback ServiceResource owner. No WorkOrder records load until all referenced ServiceResource IDs are confirmed present in Salesforce, preventing orphaned dispatch assignments.

  4. Migrate assets, accounts, and contracts before work orders

    Salesforce WorkOrder requires an AccountId and optionally an AssetId. We sequence the migration so Account records load first, then Asset records (linked to AccountId), then Contract and Entitlement records. This ensures foreign key integrity when WorkOrder records land — each work order's AccountId and AssetId references a record that already exists in Salesforce. Parts and Product2 records are migrated in parallel since they are referenced by WorkOrderLineItem but do not require prior record creation.

  5. Run sample migration with field-level diff before full commit

    A representative slice of 200–500 records — spanning work orders across different statuses, line items, service appointments, and assets — is migrated first. We generate a field-level diff comparing the source Comarch data against the target Salesforce records, surfacing any truncation (field length limits), missed value mappings (null picks), and foreign key mismatches. The diff is reviewed by your team before the full migration run is approved. This step typically catches mapping issues for custom fields or pick-list values that were not in the original mapping spec.

  6. Execute full migration with delta-pickup window and audit log

    The full migration runs against Salesforce using Bulk API for high-volume WorkOrder and WorkOrderLineItem inserts. A 24–48 hour delta-pickup window runs concurrently — any records modified in Comarch during the migration cutover are captured and applied before final reconciliation. An audit log records every insert, update, and skip operation with source record ID and error detail. If reconciliation fails, one-click rollback reverts the Salesforce org to its pre-migration state. After rollback verification, the full migration can be re-run with corrected mapping.

Platform deep dives

Context on both ends of the pair

Comarch Field Service Management logo

Comarch Field Service Management

Source

Strengths

  • Advanced automated scheduling engine that optimizes technician routing and increases on-time arrival rates across large distributed workforces.
  • Native mobile application with real-time access to schedules, customer data, asset history, and parts catalogs from the field.
  • Integration Hub provides seamless data sharing with ERP, CRM, and accounting systems out of the box.
  • Predictive analytics capabilities flag asset maintenance needs based on performance data, reducing unplanned downtime.
  • Enterprise-grade multi-site deployment with support for multilingual interfaces and global data residency requirements.

Weaknesses

  • Quote-based pricing model with no public tier information creates opaque procurement and renewal negotiation processes.
  • Implementation requires significant professional services engagement with timelines commonly exceeding 12 months for enterprise deployments.
  • Interface design and mobile user experience trail newer FSM platforms, particularly on dispatcher-side workflow efficiency.
  • Custom field architecture requires schema inspection before migration, adding pre-migration complexity for organizations with heavily customized setups.
  • Limited publicly documented API coverage means bulk export operations depend on professional services assistance.
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Comarch Field Service Management and Salesforce Sales Cloud.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Comarch Field Service Management: Not publicly documented.

  • Data volume sensitivity

    B

    Comarch Field Service Management doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Comarch Field Service Management to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Comarch Field Service Management to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during Comarch Field Service Management to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Comarch Field Service Management to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most Comarch FSM to Salesforce Sales Cloud migrations complete within 48–72 hours of clock time for organizations with under 10,000 work order records. Larger implementations with 50,000+ work orders, complex entitlement hierarchies, or multi-tier service territories extend to 7–14 days. The longest planning phase is designing the Salesforce Entitlement and Service Territory schema before data loads — the actual data migration clock time is typically shorter than the schema setup phase.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Comarch Field Service Management.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day