CRM migration
Field-level mapping, validation, and rollback between Zilliant CPQ and Freshsales. We move data and schema; workflows are rebuilt natively in Freshsales.
Zilliant CPQ
Source
Freshsales
Destination
Compatibility
7 of 10
objects map 1:1 between Zilliant CPQ and Freshsales.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Zilliant CPQ and Freshsales serve different core functions. Zilliant CPQ is a manufacturing-focused configure-price-quote platform built around Products, Quote line items, Sales Agreements, and AI-driven pricing optimization with variant configuration and constraint-based rules. Freshsales is a sales CRM from Freshworks built around Contacts, Accounts, Deals, and built-in communication tools at SMB-friendly pricing without a native CPQ module. The migration scope is therefore bounded: we transfer Products, Accounts, Contacts, and Quote headers and line items as data records, but complex pricing schemes, Sales Agreement tier logic, guided-selling rule packages, and any custom Groovy scripts do not migrate as functional code. We preserve ERP_ID cross-references on Price Item rows, map BDAs to Freshsales custom fields, and deliver a written catalog of every active Groovy script and pricing rule for your team to rebuild using Freshsales custom fields, workflows, and deal fields or an integrated CPQ add-on. This migration is most common for distributors or manufacturers leaving Zilliant CPQ who have outgrown its pricing complexity and want a simpler CRM at lower per-seat cost, but who should plan for a separate CPQ replacement if advanced quote configuration is mission-critical.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Zilliant CPQ object lands in Freshsales, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Zilliant CPQ
Product
Freshsales
Product
1:1Zilliant CPQ Products (the base entity equivalent to ERP Materials) map to Freshsales Product records. Standard and custom product attributes migrate as typed fields. Variant configuration rules (characteristic-based rules for assemble-to-order and engineer-to-order) do not migrate as logic; we export them as a structured rule-package document and flag them for manual rebuild in Freshsales custom fields and workflows if the destination requires configuration constraints.
Zilliant CPQ
Account
Freshsales
Account
1:1Zilliant CPQ Accounts map to Freshsales Accounts directly. Large account hierarchies with custom address structures require field-level mapping of the address compound field. We preserve any BDA custom fields attached to Accounts as Freshsales custom fields, but note that C4C localization of BDA list-code values is not preserved in Zilliant CPQ and therefore does not appear in the export.
Zilliant CPQ
Contact
Freshsales
Contact
1:1Zilliant CPQ Contacts map to Freshsales Contacts. PartnerRoleRecord associations on contacts migrate as custom fields on the Contact record. We preserve contact-to-account linkages by resolving AccountId at migration time. Any BDA custom fields on Contact records map to Freshsales custom fields of the corresponding type.
Zilliant CPQ
Quote
Freshsales
Deal
1:1Zilliant CPQ Quote headers map to Freshsales Deals. The Quote status state (Draft, Pending Approval, Approved, Rejected) migrates to Freshsales Deal stage values that we configure before migration. Quote line items (SalesItems) map to Freshsales Deal Line Items if the Freshsales instance has the Products and Line Items module enabled, or to custom fields on the Deal if that module is not licensed.
Zilliant CPQ
Price List
Freshsales
Product + Custom Fields
lossyZilliant CPQ Price Lists (catalog, reference, global list, published, and matrix price types) have no native Freshsales equivalent because Freshsales does not include a CPQ pricing engine. We flatten Price List structures into Product pricing fields (list_price, cost_price, margin fields) and custom fields on the Product record where multi-tier or customer-specific pricing is required. Matrix pricing and agreement-level overrides become custom fields on Account or Deal.
Zilliant CPQ
Price Item
Freshsales
Product Pricing Fields
lossyZilliant CPQ Price Items are linked to Products and belong to Price Lists. ERP_ID column visibility may be toggled per-role via UI Profiles, but we explicitly query hidden column data during extraction to preserve ERP cross-references. These ERP_ID values migrate as a custom field erp_id__c on the Product record. Multi-currency Price Items require explicit currency mapping during extraction.
Zilliant CPQ
Sales Agreement
Freshsales
Account Custom Fields or Deal Custom Fields
lossyZilliant CPQ Sales Agreements store customer-specific pricing contracts with effective date ranges, discount tiers, and pricing overrides. We map agreement structures to Freshsales custom fields on Account (for standing contract terms) and Deal (for deal-specific pricing). Tiered discount structures flatten to custom numeric fields or picklist values because Freshsales does not support multi-tier pricing schedules natively. Agreement expiration dates map to custom date fields with workflow alerts as a rebuild recommendation.
Zilliant CPQ
Guided Selling Rules
Freshsales
Not Migrated (Rule Package Document)
1:1Zilliant CPQ Guided Selling Rules (characteristic-based product rules that drive configuration flows and constraint-based configuration) are stored as structured rule packages, not individual records. We export them as a rule-package document during scoping and flag them for manual reimplementation. Freshsales does not have a native guided-selling or constraint-based configuration module; if this capability is required, we recommend evaluating a companion CPQ tool and treating it as a separate implementation scope.
Zilliant CPQ
Business Data Attributes (BDAs)
Freshsales
Custom Fields
1:1Zilliant CPQ BDAs are custom fields mapped from SAP C4C via lookup tables supporting String, Boolean, and Decimal types. BDA field definitions and values migrate to Freshsales custom fields on the corresponding object (Account, Contact, Product). C4C localized display labels for BDA list-type fields are not preserved in Zilliant CPQ; only the raw list code value exists in the CPQ export. We flag every BDA field with list-type data and advise that translated labels must be re-established from C4C source records post-migration.
Zilliant CPQ
User
Freshsales
User
1:1Zilliant CPQ Users migrate to Freshsales Users by email match. Domain-approval restrictions on Zilliant CPQ user accounts (unapproved email domains cannot sign in) have no Freshsales equivalent; we flag user domain restrictions during scoping for the customer's admin to re-enforce in Freshsales user management. Role-based UI Profiles that control field visibility do not migrate; these become Freshsales field-level security settings configured manually post-migration.
| Zilliant CPQ | Freshsales | Compatibility | |
|---|---|---|---|
| Product | Product1:1 | Fully supported | |
| Account | Account1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Quote | Deal1:1 | Fully supported | |
| Price List | Product + Custom Fieldslossy | Fully supported | |
| Price Item | Product Pricing Fieldslossy | Fully supported | |
| Sales Agreement | Account Custom Fields or Deal Custom Fieldslossy | Fully supported | |
| Guided Selling Rules | Not Migrated (Rule Package Document)1:1 | Mapping required | |
| Business Data Attributes (BDAs) | Custom Fields1:1 | Mapping required | |
| User | User1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Zilliant CPQ gotchas
Groovy scripted logic does not export as data
ERP_ID column may be hidden but still critical
SAP characteristic labels can duplicate after legacy migration
BDA list-type fields lose C4C localization
Attachment downloads could fire multiple times on older builds
Freshsales gotchas
Freddy AI is Pro-tier only despite heavy marketing
Post-migration emails and sequences are disabled
Bot session credits are a one-time 500-session allocation
Phone credits charged per minute with no cap
File storage limits scale with plan tier
Pair-specific challenges
Migration approach
Discovery and source audit
We audit the Zilliant CPQ environment across Products, Accounts, Contacts, Quotes, Price Lists, Price Items, Sales Agreements, BDAs, active Groovy scripts, and guided-selling rule packages. We extract record counts per object, identify custom field definitions, and confirm the visibility of hidden columns (particularly ERP_ID on Price Item rows). We also confirm the target Freshsales edition and whether the Products and Line Items module is licensed, which determines whether Quote line items map to native line items or custom fields.
Destination schema design
We design the Freshsales schema to receive the migrated data. This includes creating custom fields for Sales Agreement terms (effective dates, discount tiers, override flags), ERP cross-references (erp_id__c on Product), BDA fields from Zilliant CPQ mapped by type, and Quote-status-to-Deal-stage mapping. We configure Deal stages in Freshsales to correspond with Zilliant CPQ Quote status states. Schema is validated in a Freshsales sandbox environment before any production data moves.
Groovy script and rule-package catalog
We catalog every active Groovy script in the Zilliant CPQ environment and export its logic as structured text. We also document all guided-selling rule packages. These are delivered as written artifacts, not migrated as functional code. The customer's admin reviews the catalog and determines which rules can be rebuilt using Freshsales workflow builder, which require a companion CPQ tool, and which represent deprecated or redundant logic to retire.
Pricing data flattening and ERP_ID extraction
We flatten Price List structures (catalog, matrix, agreement, override pricing) into Product pricing fields and custom fields on Account or Deal. We extract ERP_ID values from hidden Price Item columns explicitly to preserve ERP cross-references. Multi-currency Price Items are mapped by currency code. BDA list-type values are extracted with their raw code identifiers for migration to Freshsales custom picklists or text fields.
Production migration in dependency order
We run production migration in record-dependency order: Products (with erp_id__c and pricing fields), Accounts (with BDA fields and agreement-term fields), Contacts (with BDA fields and contact-to-account linkage), Quotes mapped to Deals (with Deal stage configuration, line items if Products and Line Items module is licensed), and finally any Sales Agreement data flattened into Account or Deal custom fields. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and rebuild handoff
We freeze Zilliant CPQ writes during cutover, run a final delta migration of records modified during the migration window, and deliver the Groovy script catalog and guided-selling rule-package document to the customer's admin team. We support a one-week hypercare window for reconciliation issues. We do not rebuild Groovy logic, guided-selling rules, or pricing optimization rules in Freshsales as part of the migration scope; those are separate rebuild tasks handled by the customer's admin, developer, or a Freshworks implementation partner.
Platform deep dives
Zilliant CPQ
Source
Strengths
Weaknesses
Freshsales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Zilliant CPQ and Freshsales.
Object compatibility
3 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Zilliant CPQ: Not publicly documented.
Data volume sensitivity
Zilliant CPQ doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Zilliant CPQ to Freshsales migration scoping. Not seeing yours? Book a call.
Walk through your Zilliant CPQ to Freshsales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Zilliant CPQ
Other ways to arrive at Freshsales
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.
