Migrate from The Service Manager to Pipedrive

Service Manager Incidents map to Pipedrive Activities of type Task. The original incident title becomes the activity subject; description maps to the notes field. Priority, category, and affected CI metadata become custom fields in Pipedrive since the CRM has no native ITSM priority concept.

Service Manager Incident long-description and resolution-notes fields exceed the character limits for activity subject fields. These map to Pipedrive Notes attached to the corresponding Activity record, preserving the full incident narrative with original create timestamps. The notes maintain the complete incident history including all resolution steps and communications, ensuring customer-facing teams have access to the full context when reviewing records in Pipedrive.

Service Manager Problems have no direct Pipedrive equivalent in the CRM data model. Root-cause analysis text and known-error details migrate as Notes attached to the linked Incident Activity record in Pipedrive. This approach keeps the full audit trail accessible to the customer-facing record while maintaining the relationship between the problem record and associated incidents that were resolved through the known-error procedure.

Service Requests map to Pipedrive Deals when they represent a billable or customer-facing service engagement that has commercial significance. The request title becomes the deal name, while request category and urgency map to custom fields on the deal record. Request status drives the Pipedrive deal stage mapping, allowing service requests to flow through standard sales pipeline stages. This transformation preserves the service context while adapting it to CRM workflow capabilities.

Each Service Request is also represented as an Activity in Pipedrive so that timelines and owner assignments are visible in Pipedrive's activity feed alongside the corresponding deal record. This dual representation ensures that service request handlers can see their assigned work in the activity timeline while managers can track overall deal progress. The activity record captures the operational details while the deal captures the commercial relationship.

Change Requests map to Pipedrive Activities with custom fields capturing the change type, risk level, CAB approval status, and implementation schedule. This preserves the operational context of each change request within the CRM record. However, approval chains and workflow routing that exist in Service Manager are not reproducible in Pipedrive's data model and must be rebuilt as Pipedrive automations or handled through external workflow tools.

Service Manager CIs representing organizational assets (servers, software products, business services) map to Pipedrive Organizations. CI class type (Hardware, Software, Business Service) becomes a custom field on the Organization record. CIs with a display name and owning organization get linked accordingly.

Service Manager CI-to-CI relationships such as contains, depends-on, and impacts form a typed graph that has no equivalent in Pipedrive's flat entity model. We store the relationship type and target CI ID as custom fields on the source Organization record. This preserves the relationship metadata for reference purposes, allowing your team to manually reconstruct relationships in Pipedrive's relationship model or maintain the graph structure externally.

Service Manager users (both analysts and affected end-users) map to Pipedrive People. Analysts who created or were assigned incidents become the Pipedrive Activity owner. Affected users with accounts in Service Manager become CRM contacts. Display name splits into first and last name where possible.

Service Manager Support Groups define team ownership and escalation paths for incidents and service requests. These groups have no direct Pipedrive equivalent in the CRM's user management model. The group name migrates as a custom field on Activity records so teams can filter activities by the original support team that handled an incident or service request. This allows managers to analyze workload distribution across legacy support groups.

Service Manager Service Catalog items represent the offerings available to end-users through the service portal. These catalog items are preserved as a custom field on the linked Service Request Deal in Pipedrive, so the originating service offering is visible in the sales record. This allows sales and customer success teams to understand what service level the customer originally requested and track how service offerings map to revenue.

Attachments stored in Service Manager's SharePoint document library or file share are downloaded during the migration and re-uploaded to the corresponding Pipedrive Activity or Organization record. Inline images embedded in incident notes or problem descriptions are extracted and stored as separate file attachments. Pipedrive plan tiers impose per-file and per-user storage limits that must be verified against total attachment volume before migration execution.

Service Manager knowledge-base articles contain structured ITSM documentation with workflow associations and publish-status fields. These articles have no Pipedrive equivalent since Pipedrive lacks native article storage or knowledge-base features. We extract article titles and the Service Manager article URL as Notes attached to the Organization record linked to the CI the article references. This preserves a navigable reference for customer-success teams without duplicating full article content in the CRM.

Service Manager incident status transitions including Active, Pending, Resolved, and Closed states along with the timestamps of each transition are stored as a custom log field on the Pipedrive Activity record. This preserves the complete incident lifecycle history for customer-success reviews and allows teams to analyze response times and resolution patterns. The timeline data supports service level analysis and customer health scoring in Pipedrive.