Migrate from Pega Platform to HubSpot

Pega case model has no native HubSpot equivalent — case properties become deal custom properties

Pega cases are BPM work items with typed properties, a lifecycle state machine, and a case type that governs the available fields. HubSpot deals have a fixed schema with a small set of native fields. Every Pega case property — status, priority, case type, business area, SLA tier, and any custom fields — must be mapped to HubSpot deal custom properties. The HubSpot deal name also needs a strategy: Pega's pyID (case number) or pyLabel (case title) can fill that role. We include a case-schema audit in discovery so all Pega case properties are accounted for before the migration runs.

Pega case status strings require explicit value-by-value mapping to HubSpot deal stages

Pega stores case status as freeform or semi-structured string properties (e.g., New, Open, Pending-Approval, Resolved, Closed-Cancelled) with no enforced pick-list on the case class. HubSpot deal stages are pick-list values scoped to a specific deal pipeline. There is no automatic translation — we must build a value map for every Pega status string in your instance, then create the corresponding deal stages in a dedicated Pega Cases pipeline in HubSpot. If a Pega status has no natural HubSpot equivalent, we discuss the mapping with your team before committing.

Pega workflows, decision rules, and process automation do not migrate — rebuild required

Pega's automation engine (decision rules, case-lifecycle stage transitions, Data Transforms, robotic automations, and SLA processors) is application-layer logic that cannot be mapped to HubSpot's enrollment-triggered workflow model. The two systems define automation in fundamentally incompatible ways. We export your Pega workflow definitions as a reference document — showing rule names, conditions, and action sequences — so your HubSpot admin or implementation partner has a rebuild guide. Workflow rebuilding is scoped separately from the data migration.

Pega Work Groups map to HubSpot owners but the mapping is many-to-one and must be configured

Pega Work Groups are operator collectives that can own cases. HubSpot records can only be owned by individual users — there is no group-ownership model. We resolve each Pega Work Group to a HubSpot user by matching the group's primary operator email (or a configured email field). Cases owned by a Work Group with no HubSpot email match go to a fallback owner and are flagged for manual reassignment. If your Pega instance uses Work Groups as the primary ownership model, we recommend that your HubSpot admin pre-creates users matching the Work Group emails before migration begins.

HubSpot Enterprise licensing is required for custom objects — Pega custom classes need a destination

Pega applications often include custom classes (custom objects) beyond the standard Case, Work Party, and Assignment types. HubSpot custom objects are available only on the Enterprise tier (and have per-object-type record limits). We include a custom-object inventory in the discovery phase: if your Pega setup has fewer than the HubSpot-permitted custom object types and your HubSpot plan is Enterprise, we map them 1:1. If HubSpot Enterprise is not yet in scope, we discuss alternatives such as using HubSpot custom properties on the standard deal or contact object to store the most important custom-class data.