Migrate from Zilliant CPQ to Twenty CRM

Zilliant CPQ Accounts (subject objects linked to Quotes and Opportunities) map to Twenty CRM Companies. Standard and custom account attributes migrate as custom fields on the Company object. Large account hierarchies with custom address structures require field-level mapping of address sub-fields (street, city, region, postal code, country) into Twenty's address compound field format.

Zilliant CPQ Contacts map to Twenty CRM People. We preserve contact-to-account linkages via the Twenty People-to-Company relationship. Custom BDA fields on Contact (mapped from C4C via lookup tables) migrate as custom fields on People, but we flag that C4C localized display labels for list-type BDA fields are not preserved—only the raw code value transfers.

Zilliant CPQ Products (the base entity, equivalent to ERP Materials) require a custom object created in Twenty Settings → Data Model before any import. Variant configuration rule sets and characteristic-based product models do not migrate as executable rules; we export them as a structured rule package document for manual recreation. The ERP_ID cross-reference on Products migrates as a custom text field.

Zilliant CPQ Quotes (the core output object with headers, SalesItem line items, pricing calculations, and guided-selling context) map to Twenty CRM Opportunities. Quote header fields (quote number, status, created date, expiration date) map to Opportunity fields. We preserve Quote status as a custom Opportunity field because Twenty Opportunities lack a native status concept equivalent to Zilliant's quote lifecycle states. Historical Quote status states require a custom picklist.

Zilliant CPQ SalesItems (the line-item subject type containing quantity, pricing, and product references) require a custom object in Twenty because Opportunity Line Items are not a native CRM feature. Complex BOM (Bill of Materials) item configurations with nested quantity settings require recursive decomposition during transform. The parent Quote-to-Line-Item relationship is preserved via a lookup custom field on the line item object pointing to the Opportunity.

Zilliant CPQ Price Lists (containing catalog, reference, global list, published, and matrix price types) require a custom object in Twenty. Multi-currency price lists require explicit currency mapping to Twenty's currency field. The full price type hierarchy and sequencing is preserved as structured custom fields on the Price List object.

Zilliant CPQ Price Items (linked to Products and belonging to Price Lists) decompose into multiple custom numeric fields on the Product custom object: list price, agreement price, matrix price, and override price. The ERP_ID column on Price Items can be hidden system-wide or per-role via UI Profiles—we explicitly query hidden column data during extraction to preserve the ERP mapping layer that downstream order-fulfillment systems depend on, and store it as a custom field on the Product.

Zilliant CPQ Sales Agreements (customer-specific pricing contracts with effective date ranges, discount tiers, and pricing overrides) require a custom object in Twenty because no native agreement or contract object exists. Effective dates map to custom date fields, discount tiers map to a custom multi-select field or child object, and pricing overrides are stored as structured fields on the Agreement. We document the agreement-to-account linkage for manual configuration in Twenty.

Zilliant CPQ Guided Selling Rules (product rules defined by characteristics that drive constraint-based configuration) are stored as structured rule packages, not individual records. We export them as a structured JSON and Markdown rule package document listing every rule, its trigger characteristics, constraints, and recommended configuration in Twenty. The rules themselves do not execute at the destination and require manual recreation by the customer's technical team.

Zilliant CPQ BDAs (custom fields mapped between SAP C4C and CPQ via lookup tables, supporting String, Boolean, and Decimal types) map to custom fields on Company or People objects in Twenty. We preserve the BDA-to-C4C lookup relationship in a separate reference table. List-type BDA fields lose C4C localization—we flag every BDA field with list-type data and advise customers that translated labels need to be re-established from C4C source records post-migration.

Zilliant CPQ Users (with domain-approval restrictions and role-based UI Profiles controlling field visibility) map to Twenty CRM workspace Members. We resolve owners by email match. Any Zilliant Owner without a matching Twenty Member goes to a reconciliation queue for the customer's admin to provision users before record import resumes. Per Twenty's import documentation, users must be invited and active before record imports that reference them.

Zilliant CPQ attachment metadata and Notes from the Notes section of Quotes migrate as Twenty Note records linked via the target object (Opportunity, Company, or People). We verify the patch status of the source environment for any customers on pre-patch builds that exhibit the resolved attachment download bug.