CRM migration
Field-level mapping, validation, and rollback between Zilliant CPQ and Nutshell. We move data and schema; workflows are rebuilt natively in Nutshell.
Zilliant CPQ
Source
Nutshell
Destination
Compatibility
7 of 10
objects map 1:1 between Zilliant CPQ and Nutshell.
Complexity
BStandard
Timeline
1-2 weeks
Overview
Moving from Zilliant CPQ to Nutshell is a platform simplification: Nutshell is a lightweight CRM with basic quoting rather than a full CPQ engine. Zilliant's complex pricing layers (catalog, matrix, agreement, override), guided selling rules, and Groovy-scripted custom logic do not map to Nutshell's record types. We migrate the operational record data (Products, Accounts, Contacts, Deals) and deliver a written inventory of every Sales Agreement, Price List, and BDA field requiring manual rebuild in Nutshell. The pricing complexity of a manufacturing CPQ cannot be compressed into Nutshell's standard fields without a scoped transformation plan written during discovery. We flag BDA list-type fields that lose C4C localization on transfer and advise customers to re-establish translated labels from source C4C records post-migration. Workflows, Groovy scripts, and guided selling rule packages are not migrated as code.
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 Nutshell, 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
Nutshell
Product
1:1Zilliant CPQ Products (the base entity, equivalent to ERP Materials) map to Nutshell Products with SKU, name, description, and unit price. Variant configurations and characteristic-based BOM rules in Zilliant cannot be migrated as configuration logic—Nutshell has no constraint engine. We export the variant structure as a structured JSON note on each Product record and deliver a variant-rule inventory document for the customer's admin to implement as product bundles or sub-products in Nutshell.
Zilliant CPQ
Account
Nutshell
Account
1:1Zilliant CPQ Accounts map to Nutshell Accounts. Standard address, industry, and revenue fields migrate directly. Large account hierarchies with custom address structures require field-level mapping against Nutshell's standard address fields. ERP_ID cross-references stored in Zilliant Account records migrate to a custom text field erp_id__c in Nutshell.
Zilliant CPQ
Contact
Nutshell
Contact
1:1Zilliant CPQ Contacts map to Nutshell Contacts with first name, last name, email, phone, and account linkage preserved. Partner function records attached to Zilliant Contacts require additional mapping to Nutshell's contact role or tag system. BDA custom fields on Contact use the lookup table mapping between C4C and CPQ—list-type BDA values lose C4C localization and migrate as raw code values only.
Zilliant CPQ
Quote
Nutshell
Deal
1:1Zilliant CPQ Quotes map to Nutshell Deals. Quote headers (customer reference, quote date, expiration) become Deal fields. Line items (SalesItems) map to Deal line items or product-linked tasks depending on the Nutshell configuration. Quote status states (draft, submitted, accepted, rejected) map to Nutshell Deal status values. Closed quote history migrates with full line-item detail preserved.
Zilliant CPQ
Price List
Nutshell
Product pricing
lossyZilliant CPQ Price Lists (catalog, reference, global list, published, and matrix types) do not have a direct Nutshell equivalent. We migrate the primary catalog price as the Product.unit_price in Nutshell. Matrix pricing (volume-based and tiered) migrates as a structured JSON note on the Product or as a custom pricing table custom field, and we deliver a pricing-rule inventory document specifying each matrix dimension for manual reimplementation as Nutshell custom fields or spreadsheet-based lookup.
Zilliant CPQ
Sales Agreement
Nutshell
Account (custom fields)
lossyZilliant CPQ Sales Agreements (customer-specific pricing contracts with effective date ranges and discount tiers) have no Nutshell equivalent object. We migrate agreement header data (customer, effective dates, discount percentage) to custom fields on the linked Account record. Tiered discount structures migrate as structured notes. The customer rebuilds agreement enforcement as a manual review step or custom field validation in Nutshell. We deliver a full Sales Agreement inventory with field mapping as part of the migration package.
Zilliant CPQ
Guided Selling Rules
Nutshell
Not applicable
1:1Zilliant CPQ Guided Selling rules (characteristic-based constraint and recommendation logic) are structured rule packages, not individual data records. Nutshell has no constraint-based configuration engine. We export the rule structure as a JSON rule package and deliver a guided-selling inventory document listing each rule's trigger conditions, constraint logic, and recommended Nutshell replacement (product bundles, pre-configured Kits, or a checkbox-matrix of option fields on the Product). Rebuilt guided selling is outside migration scope.
Zilliant CPQ
Business Data Attributes (BDAs)
Nutshell
Custom fields
lossyZilliant CPQ BDAs are custom fields mapped from SAP C4C via lookup tables. String, Boolean, and Decimal BDA types migrate to Nutshell custom fields of equivalent type. List-type BDA fields from C4C carry only the raw list code value in Zilliant CPQ—C4C's localized display labels are not synced and are lost on export. We flag every list-type BDA field during scoping and advise customers to re-establish translated labels from C4C source records post-migration.
Zilliant CPQ
User
Nutshell
User
1:1Zilliant CPQ Users migrate to Nutshell Users by email match. Domain-approval restrictions in Zilliant (unapproved email domains cannot sign in) have no Nutshell equivalent—user provisioning proceeds without domain validation during migration. Role-based UI Profiles controlling field visibility (such as ERP_ID column access) do not transfer; Nutshell's field-level permissions are configured separately post-migration.
Zilliant CPQ
Attachment
Nutshell
File
1:1Zilliant CPQ Quote attachments migrate to Nutshell as linked Files on the corresponding Deal record. The pre-patch bug where single attachment clicks triggered multiple downloads is a resolved source-environment issue and does not affect the migration. Attachment metadata (filename, upload date, uploader) preserves on the Nutshell File record.
| Zilliant CPQ | Nutshell | Compatibility | |
|---|---|---|---|
| Product | Product1:1 | Fully supported | |
| Account | Account1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Quote | Deal1:1 | Fully supported | |
| Price List | Product pricinglossy | Fully supported | |
| Sales Agreement | Account (custom fields)lossy | Fully supported | |
| Guided Selling Rules | Not applicable1:1 | Mapping required | |
| Business Data Attributes (BDAs) | Custom fieldslossy | Mapping required | |
| User | User1:1 | Fully supported | |
| Attachment | File1: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
Nutshell gotchas
Contact tier limits enforced on import
No bulk API endpoint requires paginated extraction
Email sequences not exportable via API
Foundation plan disables key sales features
Pair-specific challenges
Migration approach
Discovery and pricing structure assessment
We audit the source Zilliant CPQ environment for object volume (Products, Accounts, Contacts, Quotes, Price Lists, Sales Agreements), BDA field count and types, active Groovy scripts, ERP_ID column visibility, and any guided selling rule packages. We assess the pricing structure complexity: number of Price List layers, matrix dimensions, and agreement tier count. The discovery output is a written migration scope, a pricing-transformation strategy document, and a list of items requiring manual rebuild (Groovy scripts, guided selling rules, Sales Agreement enforcement logic).
Destination schema design in Nutshell
We design the Nutshell destination schema: standard objects (Account, Contact, Product, Deal) with any required custom fields (erp_id__c, bda_code__c, agreement_data__c, pricing_note__c) created before any data import. We map Zilliant Price Lists to Product.unit_price (primary) plus a JSON pricing_note for matrix detail. We map Sales Agreement headers to Account custom fields. We map BDA fields to Nutshell custom fields with types matched to String, Boolean, or Decimal. BDA list-type fields are flagged for post-migration label re-establishment.
Pricing transformation and BDA localization recovery
We decompose Zilliant's multi-layer pricing into a primary unit price plus structured metadata. Volume tiers and matrix dimensions are serialized into a pricing_note JSON field on each Product. Sales Agreement tiers are decomposed to effective-date-sliced agreement_data__c records. For every list-type BDA field, we cross-reference the C4C source record to recover the localized display label and store it alongside the raw code value in the corresponding Nutshell custom field. We export the complete pricing-rule inventory and BDA localization table as supplementary documents.
Record migration in dependency order
We run migration in dependency order: Products (with pricing_note and erp_id__c), Accounts (with agreement_data__c), Contacts (with BDA custom fields), Deals (with line items from Quote SalesItems), Files (from Quote attachments). Owner resolution matches Zilliant user emails to Nutshell user emails. Any Zilliant Owner without a matching Nutshell User is held in a reconciliation queue for the customer's admin to provision before record import resumes.
Validation using two-step export comparison
Because Nutshell's API cannot filter by custom fields, we validate custom field migration through a two-step export comparison: we export the full Nutshell dataset after migration (which includes all field values for every record) and cross-reference against the source Zilliant extraction. We spot-check 25-50 records across Products, Accounts, Contacts, and Deals for field-level accuracy. BDA list-type fields are validated against the C4C source label table exported during scoping. ERP_ID preservation is validated by comparing the erp_id__c field in Nutshell against the hidden-column export from Zilliant.
Cutover, Groovy handoff, and guided-selling inventory delivery
We freeze Zilliant CPQ writes during cutover, run a final delta migration of any records modified during the migration window, then enable Nutshell as the system of record. We deliver the Groovy script inventory (with logic as text exports), the guided-selling rule package inventory (as JSON), and the Sales Agreement decomposition document. We support a one-week hypercare window where we resolve any data reconciliation issues. Workflow rebuild, Groovy reimplementation, guided selling reconfiguration, and agreement enforcement logic are outside migration scope and are documented for the customer's admin team to handle as a separate implementation task.
Platform deep dives
Zilliant CPQ
Source
Strengths
Weaknesses
Nutshell
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 Nutshell.
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 Nutshell migration scoping. Not seeing yours? Book a call.
Walk through your Zilliant CPQ to Nutshell 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 Nutshell
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.