Migrate your Vtiger All-In-One CRM data

Accounts (called Organizations in some CRM imports) map cleanly to Companies/Accounts in most destination systems. Standard fields are stable and well-documented in Vtiger's schema. We preserve Account-to-Contact relationships during migration.

Contacts import cleanly from CSV with support for .vcf format as well. We map standard contact fields (name, email, phone, address) and maintain the Contact-to-Account relationship. Custom fields on Contacts are supported via mapping.

Leads convert to Contacts or are merged depending on destination schema. Vtiger's Lead_Status, Lead_Source, and industry fields need explicit field-level mapping to equivalent destination properties. We flag any loss of lead-scoring data that may not carry over.

Potentials are Vtiger's deal/opportunity object and map to Deals or Opportunities in most destination CRMs. We preserve Sales Stage, Amount, Close Date, and Pipeline assignment. Multi-pipeline support on Professional+ tiers requires pipeline-ID mapping.

Help Desk Tickets map to Tickets/Cases in destination systems. We preserve Ticket status, priority, assigned agent, related Contact, and internal notes. Social ticketing and round-robin assignment rules are metadata only — they do not carry as data but we document them for manual reconfiguration.

Products with pricing, stock information, and vendor associations migrate as Items. We handle product-to-quote and product-to-invoice linkages. Note that Vtiger bundles Products under the Inventory module, which must be enabled for Quotes to function.

Quotes migrate cleanly, but Vtiger requires the Inventory module to be active for the Quotes module to function. If the source account has Inventory disabled, we flag this dependency before migration so the customer can enable it or accept that Quotes may be unavailable in the source extract.

Sales Orders carry line items, totals, and status. They require Products to exist in the destination first to maintain referential integrity. We sequence Products before Sales Orders in the import order and flag any orphaned line items that lack a product match.

Purchase Orders migrate with vendor linkage and line items. Vendor records must be imported before Purchase Orders. We validate vendor existence and flag any Purchase Order records where the linked vendor does not yet exist in the destination.

Projects with task dependencies and milestones map to Projects in most destination systems. Task-level dependencies (Finish-to-Start) are preserved as task links or dependency fields where the destination supports them; otherwise they are flagged for manual reconfiguration.

Tasks under Projects and standalone Tasks migrate with assignee, due date, and status. Subtask hierarchy is preserved where the destination supports it; otherwise we flatten to top-level tasks and flag the structure for review.

Custom fields are fully supported but require field-type mapping — Vtiger field types (picklist, checkbox, date, currency, etc.) must align with destination field types. We generate a field-type comparison report before migration and flag mismatches for customer resolution.

Attachments export individually per record and can be voluminous. We extract attachments alongside their parent record and re-associate them post-import. Large attachment sets (>1,000 files) require staging in object storage before re-upload to the destination.

Workflow automation rules (triggers, conditions, actions) are configuration data rather than records. We export the workflow definitions as JSON metadata and provide a re-implementation guide for the destination platform, as direct workflow migration is not 1:1 compatible across CRMs.