Migrate from Pega Sales Automation to Microsoft Dynamics 365 Sales

Pega Accounts map directly to Dynamics 365 Account. They are the top-level import anchor with no parent dependencies, so we import them first in every migration run. Standard fields (AccountName, Industry, Website, Address, Phone) map 1:1. Pega's industry classification codes require mapping to the Dynamics 365 Industry code picklist. We use the Pega Account's internal pyID as a cross-reference field during migration for audit trails.

Pega Contacts map to Dynamics 365 Contact with a mandatory AccountId lookup that must be resolved at migration time. Pega's import documentation mandates loading Contacts only after Accounts are confirmed imported. We resolve the Contact-to-Account reference using Pega's pyPartyAccountID property and match against the Account records we loaded in the first phase. Contact status and disposition codes from Pega map to a custom Contact field for audit.

Pega Leads represent unconverted prospects and carry Pega-specific disposition codes. They map directly to Dynamics 365 Lead with Lead Status preserved. We create a custom field pega_disposition_code__c to retain the original Pega disposition value for reporting continuity. If any Pega Leads overlap with migrated Contacts (same email address), we flag them for manual review rather than auto-converting, because Lead-to-Contact conversion is a business decision the customer's sales ops team makes.

Pega Opportunities map to Dynamics 365 Opportunity. They reference both Account (via pyOpportunityAccountID) and optionally Contact, and include stage progression, amount, close date, and probability. We resolve AccountId at migration time before inserting Opportunities, and map Pega stage names to equivalent Microsoft Dynamics 365 Sales Process stage values. Stage history and forecast category migrate as extended properties on the Opportunity.

Pega Products are sellable items attached to Opportunities via an Opportunity-Product junction. They map to Dynamics 365 Product2 records. Standard Price Book entries are created during migration. The Pega product code maps to the Product's Number field. If the customer uses Pega's pricing rules, we migrate the base unit price and note that dynamic pricing logic requires rebuild in Microsoft Dynamics 365 Sales .

The Pega Opportunity-Product junction record (which links a Product to an Opportunity with quantity, unit price, and discount) maps to Dynamics 365 Opportunity Product Detail. We resolve the parent Opportunity reference and the Product2 reference before inserting, preserving the quantity, unit price, and discount fields on the junction.

Pega Activities (calls, emails, tasks, meetings) are tied to parent entities (Opportunity, Contact, Account). The import sequence requires Activities to load after their parent records. We flatten Pega's activity type hierarchy into Dynamics 365's separate Task (with TaskSubtype for calls), Event (for meetings), and EmailMessage objects. Activity timestamps and disposition codes migrate to custom fields for continuity. Email body content migrates to EmailMessage; call duration migrates to custom Task fields.

Pega Cases (Work Objects) carry their own lifecycle states, assignments, SLA timers, and dependency chains that do not map directly to any standard Dynamics 365 entity. We evaluate whether Cases should map to a Dynamics 365 custom entity, to the Incident table (if Service is licensed), or to Tasks on the parent Account or Opportunity based on the customer's Case type taxonomy. We design this mapping during scoping and validate it in the sandbox migration before production import.

Pega Campaigns group Leads and Activities for coordinated outreach. They map to Dynamics 365 Campaign, with campaign membership records and campaign status preserved. Linked Opportunities that originated from campaign response are reconciled against the Opportunities already migrated in the earlier phase. Campaign budget and scheduled start/end dates migrate to standard Campaign fields.

Pega Sales Teams define which users have access to a given Account or Opportunity. Pega stores team membership as a separate assignment entity. If the destination Dynamics 365 org uses the native Teams model, we map team assignments to Dynamics 365 Team membership records. If the org uses manual sharing or territory-based access, we map team assignments to equivalent sharing rules and document the difference in the handoff documentation.

Pega Territories segment Accounts and users by geography or business unit using assignment rules that trigger on record creation. We map Pega territory assignments to Dynamics 365 Territory records, preserving the territory hierarchy. Territory-based routing rules are not migrated as automation; they are documented for the customer's admin to configure in Microsoft Dynamics 365 Sales Territory Management post-migration.

Pega supports unlimited custom properties on any base entity configured via App Studio or Rule configuration. There is no automated discovery endpoint listing every custom field across the schema. We enumerate custom fields entity by entity via the Pega API or by reviewing Ruleset exports, then manually map each to a corresponding Dynamics 365 custom field with matched data type. Pega Text maps to Single Line of Text or Multiple Lines of Text; Integer and Decimal map to Number; DateTime maps to Date and Time. Custom field mapping is the most manual step in any Pega migration and drives schedule variance.