CRM migration

Migrate from Zilliant CPQ to Salesforce Sales Cloud

Field-level mapping, validation, and rollback between Zilliant CPQ and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.

Zilliant CPQ logo

Zilliant CPQ

Source

Salesforce Sales Cloud

Destination

Salesforce Sales Cloud logo

Compatibility

92%

11 of 12

objects map 1:1 between Zilliant CPQ and Salesforce Sales Cloud.

Complexity

BStandard

Timeline

8-12 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Zilliant CPQ to Salesforce is a CPQ-to-CPQ migration where the primary challenge is not field mapping but pricing schema preservation and the handling of custom Groovy logic that does not export as data. Zilliant CPQ uses Products as the base entity with layered pricing schemes (catalog, matrix, agreement, and override) and stores custom business logic in Groovy scripts that live outside the standard export. We extract Price Items with explicit queries against hidden ERP_ID columns, preserve Price List hierarchies and Sales Agreement structures as typed Salesforce records, and export Guided Selling rules as structured rule packages rather than record-by-record imports. Groovy-scripted business logic is catalogued and delivered as text for manual reimplementation at the destination. BDA (Business Data Attribute) fields mapped from SAP C4C retain only raw list-code values without C4C localization, which we flag during scoping. Workflows, automations, and forms do not migrate as code; we deliver a written inventory for the customer's admin to rebuild in Salesforce Flow.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Zilliant CPQ logo

Zilliant CPQ

What's pushing teams away

  • Slow loading and performance issues during complex operations are the most cited frustrations, particularly during quote generation with many line items
  • Time lag between configuration completion and pricing calculation creates friction in fast-moving sales cycles, with users describing it as a recurring bottleneck
  • Manufacturing complexity that exceeds the platform's constraint-based configuration model forces teams to maintain workarounds outside CPQ, undermining the single-source-of-truth goal
  • Integration complexity with multiple ERP systems (SAP, Salesforce) creates data synchronization drift that requires manual correction
  • Some users report the platform's opinionated approach to pricing logic conflicts with unique discounting requirements in their specific vertical

Choosing

Salesforce Sales Cloud logo

Salesforce Sales Cloud

What's pulling them in

  • The AppExchange marketplace with 5,000+ prebuilt apps gives enterprises integrations for nearly every business workflow without custom development.
  • Native Einstein AI for lead scoring, opportunity insights, and predictive forecasting adds intelligence without a separate platform purchase.
  • Territory management, multi-currency support, and advanced forecasting satisfy the needs of complex B2B sales organizations with structured revenue teams.
  • Slack, Tableau, and CPQ are deeply integrated into the core platform, keeping the sales stack unified for teams already in the Salesforce ecosystem.
  • Organizations with a large, established Salesforce implementation choose it because switching costs — integrations, custom code, trained admins — are prohibitive.

Object mapping

How Zilliant CPQ objects map to Salesforce Sales Cloud

Each row shows how a Zilliant CPQ object lands in Salesforce Sales Cloud, 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

maps to

Salesforce Sales Cloud

Product2

1:1
Fully supported

Zilliant CPQ Products (the base entity, equivalent to ERP Materials) map to Salesforce Product2 records. Variant configuration rules (characteristic-based constraints for assemble-to-order and engineer-to-order workflows) map to Salesforce CPQ Option Constraints, Feature Groups, and Option Tags. We preserve the product hierarchy as Salesforce Product Family and map the ERP_ID column as a custom external ID field prod_erp_id__c for ERP cross-referencing during order fulfillment.

Zilliant CPQ

Quote

maps to

Salesforce Sales Cloud

Quote

1:1
Fully supported

Zilliant CPQ Quotes map to Salesforce Quote (Sales Cloud standard object from Professional tier). Quote headers, line items (SalesItems), pricing calculations, and guided-selling context migrate. Historical Quote status states (Draft, Pending Approval, Approved, Lost, Won) map to Salesforce Quote Status values. We preserve Quote description and any structured pricing context in custom Quote fields. Quote PDFs and attachments migrate as ContentDocument linked to the Quote.

Zilliant CPQ

SalesItem (line items)

maps to

Salesforce Sales Cloud

QuoteLineItem

1:1
Fully supported

Zilliant CPQ SalesItems (the line-item subject type) map to Salesforce QuoteLineItem. Quantity, UnitPrice, Product2Id (resolved via SKU lookup), and any custom line-level fields migrate. Complex BOM (Bill of Materials) item configurations with nested quantity settings require recursive line expansion during transform. We preserve the BOM hierarchy as nested QuoteLineItem rows with a parent line reference.

Zilliant CPQ

Price List

maps to

Salesforce Sales Cloud

Pricebook2

1:1
Fully supported

Zilliant CPQ Price Lists (catalog, reference, global list, published, and matrix price types) map to Salesforce Pricebook2 records. The price type hierarchy and sequencing are preserved as Pricebook2 description fields and Pricebook isActive flags. Multi-currency Price Lists require explicit currency mapping from Zilliant's currency codes to Salesforce CurrencyIsoCode values during import.

Zilliant CPQ

Price Item

maps to

Salesforce Sales Cloud

PricebookEntry

1:1
Fully supported

Zilliant CPQ Price Items (linked to Products and Price Lists) map to Salesforce PricebookEntry. The ERP_ID column (id_col_quote_configuration_priceItems_erpId) may be hidden per-role via UI Profiles—we explicitly query hidden column data during extraction to preserve ERP cross-references that downstream order-fulfillment systems depend on. Price Item effective dates map to PricebookEntry UseStandardPrice and StartDate/EndDate fields.

Zilliant CPQ

Sales Agreement

maps to

Salesforce Sales Cloud

Contract

1:1
Fully supported

Zilliant CPQ Sales Agreements (customer-specific pricing contracts with effective date ranges, discount tiers, and pricing overrides) map to Salesforce Contract records linked to the corresponding Account. Tiered pricing structures from Zilliant map to Contract Line Items or custom Price Agreement Line Item objects depending on the destination Salesforce CPQ edition. We preserve agreement status, renewal dates, and pricing override flags.

Zilliant CPQ

Guided Selling Rules

maps to

Salesforce Sales Cloud

Configuration Rules (Option Constraints)

1:1
Mapping required

Zilliant CPQ Guided Selling rules (characteristic-based product rules driving guided selling flows and constraint-based configuration) are stored as structured rule packages, not individual records. We export them as a structured rule inventory document listing the rule name, trigger characteristics, constraint logic, and recommended Salesforce CPQ Option Constraint equivalent. The rules are not auto-migrated; they are documented for the customer's admin to rebuild using Salesforce CPQ's constraint model post-migration.

Zilliant CPQ

Account

maps to

Salesforce Sales Cloud

Account

1:1
Fully supported

Zilliant CPQ Accounts (subject objects linked to Quotes and Opportunities) map to Salesforce Account. Standard and custom attributes migrate. Large account hierarchies with custom address structures require field-level mapping of address sub-fields (Street, City, State, PostalCode, Country) and Parent Account resolution. We resolve account references before Quote import to satisfy the lookup relationship.

Zilliant CPQ

Contact

maps to

Salesforce Sales Cloud

Contact

1:1
Fully supported

Zilliant CPQ Contacts (subject objects with PartnerRoleRecord associations) map to Salesforce Contact. Contact-to-Account linkages and custom BDA fields migrate. Partner function records attached to contacts require additional mapping to Contact PartnerRole or a custom Contact Role field depending on the destination configuration.

Zilliant CPQ

Business Data Attributes (BDAs)

maps to

Salesforce Sales Cloud

Custom Fields

lossy
Mapping required

BDAs are custom fields mapped between SAP C4C and Zilliant CPQ via lookup tables supporting String, Boolean, and Decimal types. List-type BDA fields store only the raw code value from C4C—C4C's localized display labels are not preserved in Zilliant CPQ. We flag every BDA field with list-type data during migration scoping, export both the code value and a reference to the C4C label source, and advise customers that translated labels must be re-established from C4C source records post-migration. BDA String and Decimal fields migrate as custom fields on the equivalent Salesforce object.

Zilliant CPQ

User and Access

maps to

Salesforce Sales Cloud

User

1:1
Fully supported

Zilliant CPQ User management includes domain-approval restrictions (users with unapproved email domains cannot sign in) and Role-based UI Profiles controlling field visibility (e.g., ERP_ID column). We extract user records and map to Salesforce User by email match. UI Profile role mappings that control ERP_ID visibility are documented as Salesforce Field-Level Security or Page Layout assignments for the customer's admin to reapply.

Zilliant CPQ

Attachment and Notes

maps to

Salesforce Sales Cloud

ContentDocument and Note

1:1
Fully supported

Zilliant CPQ attachment metadata (a known bug in pre-patch versions caused single clicks to trigger multiple downloads equal to the total attachment count) is preserved as ContentDocument metadata during extraction. We document the patch status of the source environment before migration. Attachments and Notes migrate as Salesforce ContentDocument records linked via ContentDocumentLink to the parent Quote, Account, or Contact.

Gotchas + challenges

What specifically takes care here

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 logo

Zilliant CPQ gotchas

High

Groovy scripted logic does not export as data

Medium

ERP_ID column may be hidden but still critical

Medium

SAP characteristic labels can duplicate after legacy migration

Medium

BDA list-type fields lose C4C localization

Low

Attachment downloads could fire multiple times on older builds

Salesforce Sales Cloud logo

Salesforce Sales Cloud gotchas

High

Workflow Rules and Process Builder are retired

High

Bulk API batch quota exhaustion during large imports

Medium

Storage overage billing is non-obvious

Medium

Account-Contact many-to-many relationship mapping

Low

Territory and team member import ordering dependencies

Pair-specific challenges

  • Groovy scripted logic does not migrate as data

    Zilliant CPQ allows custom business logic via Groovy scripts that modify standard functionality. These scripts are configuration artifacts, not data records—they are not included in standard CSV exports or API bulk reads. We cannot migrate Groovy logic automatically. We catalog every active Groovy script during scoping, export its logic as text, and deliver it as a structured rule inventory document with recommended Salesforce Flow or Apex equivalents for manual reimplementation at the destination. This is a manual step outside the standard data migration scope.

  • ERP_ID column may be hidden but is still critical

    The ERP_ID column on Price Item rows (id_col_quote_configuration_priceItems_erpId) can be hidden system-wide or per-role via UI Profiles. Migration tooling that reads only visible columns will miss ERP cross-references that downstream order-fulfillment systems depend on. We explicitly query hidden column data during extraction. If the source environment has role-based ERP_ID visibility, we document which roles have access and map those to corresponding Salesforce Field-Level Security profiles post-migration.

  • BDA list-type fields lose C4C localization

    Custom BDA fields mapped from SAP C4C store only the raw list code value in Zilliant CPQ—C4C's localized display labels are not synced. For list-type BDAs, the migrated Salesforce custom field will contain the code value but not the human-readable label. We flag every BDA field with list-type data during scoping and advise customers that translated labels must be re-established from C4C source records or re-entered manually post-migration.

  • Price Item hierarchy chunking required for large product families

    Zilliant CPQ Price Items are linked to Products and Price Lists in a three-way relationship that can produce high row counts (tens of thousands of Price Item rows for complex product catalogs). We chunk the migration by product family and validate pricing logic post-transfer against live system outputs. Without chunking, large Price Item sets can exceed API batch limits and produce orphaned pricing rows. This is mitigated by running product-family sub-imports with cross-validation of pricing totals after each chunk.

  • SAP characteristic labels can duplicate after legacy migration

    A documented issue in Zilliant CPQ (resolved in a recent patch) caused SAP characteristics to create duplicate labels during CPQ migrations from legacy systems. If the source environment predates the fix, we run a label-deduplication pass before importing to prevent duplicate characteristic options from polluting the Salesforce Product2 characteristic model. We document the patch status of the source environment during discovery and apply the deduplication step as a pre-import transform if needed.

Migration approach

Six steps for a successful Zilliant CPQ to Salesforce Sales Cloud data migration

  1. Discovery and extraction

    We audit the Zilliant CPQ source environment: Products (with variant configuration rules), Quotes, Price Lists, Price Items (with explicit hidden-column ERP_ID queries), Sales Agreements, Accounts, Contacts, BDA field definitions, Guided Selling rule packages, active Groovy scripts, and attachment metadata. We document the patch status for the SAP characteristic label bug and UI Profile ERP_ID visibility settings. We assess Quote volume, Price Item row count, and product family complexity to determine the chunking strategy and timeline. The discovery output is a written extraction plan and migration scope document.

  2. Destination schema design

    We design the Salesforce destination schema: Product2 with Option Bundle, Feature, and Option constraint models for variant configuration; Pricebook2 with price type mapping; Contract and Contract Line Items for Sales Agreements; custom fields for BDA data with field types matched to Zilliant BDA types (String, Boolean, Decimal); and custom fields for Quote and QuoteLineItem to capture Zilliant pricing context not natively available in Salesforce. Guided Selling rules are mapped to a Configuration Rules inventory document (not migrated as records). We deploy the schema to a Salesforce Sandbox for validation before production migration.

  3. Groovy logic cataloguing

    We extract every active Groovy script as text, document its trigger context, input parameters, business logic, and output actions, and map each to a recommended Salesforce Flow or Apex equivalent. This is a documentation deliverable, not an automated migration step. The customer's admin or a Salesforce partner uses the inventory to rebuild logic post-migration. We include a priority ranking (high/med/low) based on business impact of non-migration.

  4. Sandbox validation migration

    We run a full migration into a Salesforce Sandbox using production-like data volume. The customer reconciles record counts, spot-checks 25-50 random Quotes against Zilliant source values (line item pricing, totals, discount application), validates Price Item lookups against ERP_ID references, and signs off the schema and mapping before production migration begins. Pricing logic validation against live system outputs occurs at this stage.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Product2 (with option constraints), Pricebook2, PricebookEntry (chunked by product family with ERP_ID preserved), Accounts, Contacts, Contracts (for Sales Agreements), Quotes (with QuoteLineItems resolved to Product2 and PricebookEntry lookups), Guided Selling rule inventory document (delivered as structured export, not imported), and BDA custom field data (with code values migrated and labels flagged for re-establishment). Each phase emits a row-count reconciliation report before the next phase begins.

  6. Cutover, validation, and rebuild handoff

    We freeze Zilliant CPQ writes during cutover, run a final delta migration of any records modified during the migration window, then enable Salesforce as the system of record. We deliver the Groovy logic inventory, Guided Selling rule document, BDA field label reconciliation list, and UI Profile mapping document to the customer's admin team. We support a one-week hypercare window where we resolve reconciliation issues. We do not rebuild workflows, automations, or forms; those are documented separately for the customer's admin to rebuild in Salesforce Flow.

Platform deep dives

Context on both ends of the pair

Zilliant CPQ logo

Zilliant CPQ

Source

Strengths

  • Variant configuration models for complex manufactured products are purpose-built and accessible to sales teams without engineering involvement
  • Real-time pricing calculations and dynamic cost estimations eliminate manual quote math errors
  • Guided selling flows steer reps toward margin-positive configurations automatically
  • Salesforce CPQ and SAP integrations are natively supported with documented connector endpoints
  • Product modeling supports characteristic-based rules for assemble-to-order and engineer-to-order workflows

Weaknesses

  • Performance degradation on complex operations with many line items is a documented user complaint
  • Configuration-to-pricing lag creates quote turnaround friction in fast sales cycles
  • Heavy reliance on Groovy scripting for custom logic means bespoke workflows do not export cleanly
  • BDA custom-field architecture between C4C and CPQ introduces localization loss on list-type fields
  • No publicly documented API rate limits or bulk-export mechanism in available documentation
Salesforce Sales Cloud logo

Salesforce Sales Cloud

Destination

Strengths

  • Largest enterprise app ecosystem in CRM with 5,000+ AppExchange integrations covering nearly every vertical workflow.
  • Native Einstein AI delivers lead scoring, opportunity insights, and predictive forecasting without a third-party layer.
  • Advanced territory management, multi-currency, and flexible forecasting satisfy complex B2B revenue structures.
  • Deep platform extensibility: Custom Objects, Apex, Flow, and the Metadata API allow full schema customization.
  • Well-documented REST API, Bulk API, and Composite API with published rate limits for programmatic migration.

Weaknesses

  • Pricing model is layered and opaque in practice: per-seat fees plus storage overages, add-on subscriptions, and annual uplifts compound to 30–40% above sticker price.
  • Workflow Rules and Process Builder are deprecated, forcing all orgs onto Salesforce Flow — a migration task that catches many teams by surprise.
  • Steep administrative complexity: meaningful configuration requires a dedicated Salesforce admin or consultant.
  • API rate limits are edition-gated (100k/day base for Enterprise) and easily exhausted by large historical imports without throttling.
  • Data export is exportable via Data Loader but preserving relationship integrity across 30+ objects requires careful ETL sequencing.

Complexity grading

How hard is this migration?

Standard CRM migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Zilliant CPQ and Salesforce Sales Cloud.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Zilliant CPQ: Not publicly documented.

  • Data volume sensitivity

    B

    Zilliant CPQ doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Zilliant CPQ to Salesforce Sales Cloud migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Zilliant CPQ to Salesforce Sales Cloud data migrations

Answers to the questions buyers ask most during Zilliant CPQ to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Zilliant CPQ to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between eight and twelve weeks for environments with under 5,000 Quotes, 2,000 Products, and straightforward pricing hierarchies. Migrations with complex variant-configuration models, large Price Item hierarchies (over 100,000 rows), multiple ERP_ID cross-reference tables, multi-currency Price Lists, or extensive Groovy script libraries requiring documentation move to fourteen to twenty-two weeks because of schema chunking by product family, pricing logic validation against live system outputs, and Groovy logic documentation scope.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Zilliant CPQ.
Land in Salesforce Sales Cloud, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day