Migrate from Zilliant CPQ to Microsoft Dynamics 365 Sales

Zilliant Products (the base entity equivalent to ERP Materials) map directly to Dynamics 365 Product2. We preserve the product hierarchy, variant configuration characteristics, and unit-of-measure settings. ERP_ID cross-references on Product records transfer to a custom field on Product2 for downstream order-fulfillment lookup. Products with complex characteristic-based variant rules require a CPQ add-on (Experlogix, Tacton, or PROS) to preserve constraint logic; we document the rule structure and flag where native Dynamics configuration ends.

Zilliant Quotes map to a two-stage model in Microsoft Dynamics 365 Sales : the Quote object stores the quoted configuration, and the parent Opportunity stores the pipeline stage (Proposal, Negotiation, Closed Won/Lost). Quote line items map to OpportunityLineItem. We preserve Quote status, expiration dates, and any attached files as SharePoint document locations in Dynamics. Historical Quote records that are already closed transfer as Opportunity records with their final stage locked.

Zilliant Price Lists with catalog, reference, global list, and published types map to Dynamics 365 Price List entities. We preserve the full price type hierarchy and sequencing, and handle multi-currency Price Lists by mapping the currency code to the TransactionCurrencyId on the Price List. Matrix price types that define quantity-based or attribute-based pricing map to Product Quantity Rules or require a CPQ add-on for full fidelity.

Zilliant Price Items linked to Products within Price Lists map to Price List Items in Microsoft Dynamics 365 Sales . The ERP_ID column on Price Item rows (which can be hidden via UI Profiles but is still present) transfers to a custom field on Price List Item for ERP cross-referencing. We explicitly query hidden column data during extraction to avoid missing ERP mapping rows that downstream order-fulfillment systems depend on.

Zilliant Sales Agreements store customer-specific pricing contracts with effective date ranges, discount tiers, and pricing overrides. These map to the Agreement entity in Dynamics 365 (available through the Agreement Management add-on or via custom fields on the Account). We preserve tiered pricing structures as pricing detail lines and flag any date-range logic that requires Power Automate-based renewal reminders post-migration.

Zilliant Account records (subject objects linked to Quotes and Opportunities) map directly to Dynamics 365 Account. Large account hierarchies with custom address structures require field-level mapping of billing versus shipping address roles. Account-to-Contact linkages transfer with the Contact import so that the Account lookup is satisfied at the moment of Contact insert.

Zilliant Contact records with PartnerRoleRecord associations map to Dynamics 365 Contact. We preserve contact-to-account linkages, and any BDA custom fields on Contact transfer as custom fields on the Dynamics Contact entity. BDA list-type values store only raw codes from C4C; we flag every BDA field during scoping and advise that translated labels will need to be re-established from the C4C source post-migration.

Zilliant Sales Items (the line-item subject type with quantity, pricing, and product references) map to Dynamics 365 OpportunityLineItem. Complex BOM item configurations with nested quantity settings require recursive resolution of the Product2 structure before migration. We validate that each Sales Item has a resolved Product2 reference and PricebookEntry before insert to avoid orphaned line items.

Zilliant Guided Selling rules and constraint-based configuration are stored as structured rule packages, not individual records. We export them as a written rule package document covering constraint logic, characteristic dependencies, and guided flow triggers. These do not migrate as active rules; the customer's admin rebuilds them in a CPQ add-on (Experlogix, Tacton, PROS) or documents them for Power Automate-based routing post-migration.

Zilliant Groovy scripts extend standard functionality via custom business logic. These are configuration artifacts, not data records, and do not export via CSV or API. We catalog every active Groovy script during scoping, export its logic as text, and deliver a written inventory with recommended replacement patterns in Power Automate, Dataverse plugins, or a CPQ add-on. Groovy logic that cannot be expressed natively requires a separate development engagement.