Migrate from Deepser to HubSpot Service Hub

Deepser Service Requests map directly to HubSpot Tickets. Every field — priority, status, category, assigned agent (Deepser Agent to HubSpot User), requester (Deepser Customer to HubSpot Contact), and timestamps — migrates 1:1 into HubSpot Ticket properties. Ticket pipeline is set from a default Service Request pipeline that we configure before import. Original Service Request ID is preserved in a custom property deepser_sr_id__c for audit trail.

Deepser Change Requests map to HubSpot Tickets with a dedicated change-request pipeline and Record Type so they route separately from Service Requests. The change-type classification (Standard, Minor, Major, Emergency) from Deepser is preserved as a custom property change_type__c on the HubSpot Ticket. We configure pipeline stage names (Assessment, Approval, Implementation, Review, Closed) to reflect ITIL change-request lifecycle states before migration begins.

Deepser Customer records map to HubSpot Contacts. The full contact card — name, email, phone, company association, and custom fields — migrates into HubSpot Contact properties. Deepser's company association links to the Company record during Company import so that the AccountId lookup on Contact is resolved at import time rather than retroactively.

Deepser Company records map directly to HubSpot Accounts. Company name is the primary dedupe key during import. We run the Account import before the Contact import so that every Contact can be linked to its Account via the AccountId lookup at the moment of Contact insert, avoiding orphaned contacts in HubSpot.

Deepser Agent records map to HubSpot Users. We resolve each Agent by email against the HubSpot destination portal's User table. Any Agent without a matching HubSpot User goes to a reconciliation queue for the customer's admin to provision before the ticket import phase begins. Deepser's role and team assignment fields map to HubSpot Team membership and User role. We note the Deepser 3-agent minimum during scoping because it affects how we size the migration team structure.

Deepser IT Assets have no native HubSpot equivalent. We map them to a custom HubSpot object named IT_Asset__c with standard properties for serial_number__c, asset_type__c, location__c, assigned_user__c (Contact lookup), and lifecycle_status__c. The custom object schema is designed during discovery based on the customer's active Deepser ITAM module fields. Lifecycle status values (Active, In Maintenance, Retired, Disposed) map from Deepser's asset status enumeration. This requires HubSpot Professional or Enterprise tier since custom objects are not available on Starter.

Deepser Custom Fields scoped to Tickets, Customers, Companies, and Assets are discovered during the scoping phase. We create equivalent HubSpot custom properties of matching type — text, number, date, dropdown — on the corresponding HubSpot object before migration. Deepser multi-select or checkbox fields map to HubSpot multi-checkbox or single-checkbox properties. Picklist values are re-created as HubSpot dropdown options. Custom field schemas vary per Deepser installation, so this phase is custom for every migration.

Deepser knowledge base articles migrate to HubSpot Knowledge Base articles with article title, body content (rich text), and category preserved. Article attachments migrate as HubSpot file uploads linked to the article. Multi-language article sets from Deepser (English, Italian, Spanish, German) are mapped to HubSpot Knowledge Base article versions where the destination Knowledge Base has multi-language support enabled on Professional or Enterprise. We flag this during scoping if multilingual articles are present.

Deepser ITIL Workflows include approval gates, automated tasks, and conditional routing that have no direct HubSpot Service Hub equivalent. We do not migrate Workflows as code. We deliver a written inventory of every Deepser Workflow step type, trigger condition, and action with a recommended HubSpot Service Hub Automation equivalent documented per step. The customer's admin or a HubSpot Solutions Partner rebuilds the automation post-migration. Approval-gate workflows are the highest-risk item in this inventory because they carry operational authority that must be explicitly re-established in HubSpot.

Deepser report definitions and dashboard layouts are not exportable and do not migrate. We document the schema of every Deepser report — the underlying ticket filters, date ranges, group-by fields, and chart types — during the discovery phase so the customer's admin has a rebuild specification. The underlying ticket and activity data migrates fully, giving the HubSpot reporting dashboard the same raw material to work from.

Deepser billing modules track time-based line items, worklogs, movements, and operational billing records linked to tickets and assets. HubSpot Service Hub has no native billing object. We map Deepser billing fields to custom properties on the HubSpot Ticket (billing_type__c, worklog_hours__c, billing_amount__c) and IT_Asset__c custom object. Customers who rely on Deepser's billing module for invoicing or cost allocation need a separate billing workflow redesign; we document the field map and flag this as a process change, not a data migration.

Deepser file attachments linked to Service Requests, Change Requests, Customers, and Knowledge Base articles migrate to HubSpot Files. We download the original file from the Deepser grid export, upload to HubSpot using the Files API, and link to the parent Ticket or Contact record via ContentDocumentLink. File naming conventions from Deepser are preserved to aid identification post-migration. Very large attachments (over 25 MB) exceed HubSpot's direct upload size limit and are handled with a shared storage link noted in the migration report.