Migrate from Vtiger All-In-One CRM to Salesforce Sales Cloud

Vtiger Accounts map directly to Salesforce Account. Industry, website, phone, billing address, and shipping address migrate to equivalent Salesforce Account fields. Account is the first object imported because Contacts and Potentials both reference it. We resolve any duplicate Account names during the pre-migration deduplication phase and flag records where the Account name matches a Contact name (Vtiger's flatter model vs. Salesforce's strict Account-Contact separation). Multi-currency accounts (available if Vtiger's multi-currency setting is active) require Active Currencies to be enabled in the Salesforce org before Account import begins.

Vtiger Contacts map to Salesforce Contact. We map name fields (FirstName, LastName), email, phone, mobile, title, department, and address fields directly. Vtiger's Contact-to-Account relationship migrates as Salesforce Contact.AccountId, resolved by matching the source Account's vtiger_id or Account Name. Standalone Contacts in Vtiger (not linked to an Account) are imported as Salesforce Contacts without an AccountId, and we flag these for the customer's admin to link to an Account post-migration. Custom fields on Contact migrate with type mapping: Vtiger picklist becomes Salesforce Picklist, Vtiger checkbox becomes Boolean, currency fields become Currency (18,2) in Salesforce.

Vtiger Leads map to Salesforce Lead. Lead_Status, Lead_Source, Industry, and NumberOfEmployees migrate to equivalent Salesforce Lead fields. Any Lead_Score or rating values stored in Vtiger custom fields become custom Lead fields (lead_score__c, rating_override__c) in Salesforce. We do not auto-convert Vtiger Leads to Salesforce Contacts during migration; the customer's admin runs the Lead Convert action post-migration to create the Account-Contact-Opportunity triad. Lead Convert rules can be pre-configured in Salesforce before migration for a smoother day-one experience.

Vtiger Potentials map to Salesforce Opportunity. The Sales Stage, Amount, Close Date, Probability, Description, and Pipeline assignment migrate to Opportunity.StageName, Amount, CloseDate, Probability, Description, and a Salesforce Record Type that corresponds to the Vtiger pipeline. Closed-Lost and Closed-Won status migrate as Salesforce Stage values. Multi-currency Potentials require the Salesforce org's Active Currencies setting to include the source currency ISO code before Opportunity import; otherwise Amount values are rejected. We create one Salesforce Record Type per Vtiger pipeline so that stage picklist values stay scoped per line of business.

Each Vtiger pipeline becomes a Salesforce Record Type on Opportunity with a corresponding Sales Process that whitelists the relevant stage values. We pre-configure the Record Type and Sales Process in a Sandbox before production migration. Stage probability percentages migrate from Vtiger to Salesforce StageProbability, rounded to the nearest Salesforce-allowed integer. If Vtiger uses multiple pipelines with the same stage names but different meanings, we create separate Record Types with distinct Page Layouts to prevent sales reps from accidentally moving deals across business units.

Vtiger Help Desk Tickets map to Salesforce Case. Ticket status (Open, Pending, Closed), priority (Low, Medium, High, Urgent), assigned agent, related Contact, and internal notes migrate to Case.Status, Priority, OwnerId, ContactId, and Description. Ticket number (the human-readable identifier like HD-0042) is preserved in a custom field vtiger_ticket_number__c on the Case for audit and cross-reference. If Vtiger's round-robin assignment rules are active, we document the current assignment distribution and advise the customer's admin to configure Salesforce Case Assignment Rules post-migration. Social ticketing channels (if enabled in Vtiger) do not migrate; these require a separate Social Customer Service setup in Salesforce.

Vtiger Products (managed under the Inventory module) map to Salesforce Product2 records. Product name, code (Part Number), unit price, vendor association, and stock quantity migrate to Product2.Name, ProductCode, UnitPrice, and a custom vendor lookup. If Vtiger's Inventory module is disabled, Products may not exist in the export and we flag this during pre-migration module audit. Product2 records must be imported before Quotes and Sales Orders because those objects reference Products via PricebookEntry. We create a Standard Pricebook during migration so that Quote and Sales Order imports have a valid pricebook reference.

Vtiger Quotes map to Salesforce Quote, which is available from Salesforce Sales Cloud Professional tier. Vtiger requires the Inventory module to be enabled for the Quotes module to function; if Inventory is disabled, no Quote records will exist in the export. We check the source account's module configuration during discovery and flag this dependency before data extraction. Quote PDFs are not migrated as native files; we export them as attachments and re-associate them with the Salesforce Quote record post-import. Line items on Quotes require the Products to exist in Salesforce first, so we sequence the import as Products, then PricebookEntries, then Quotes.

Vtiger Sales Orders map to Salesforce Order. The Order object in Salesforce requires the Order Management feature to be enabled in the destination org (available from Enterprise edition). We confirm the Salesforce edition before including Sales Orders in scope. Line items on Sales Orders require Products to exist in Salesforce first, so we sequence the import after Products and Quotes. Sales Order status (Created, Approved, Delivered, Cancelled) maps to Salesforce Order.Status. If the customer does not have Order Management enabled in Salesforce, we convert Sales Orders to Opportunity Line Items and document the change in the mapping spec.

Vtiger Purchase Orders carry vendor linkage and line items but have no direct Salesforce Sales Cloud standard object equivalent. We map them to a custom Purchase_Order__c object with fields for Vendor (lookup to Account), PO_Number__c, PO_Date__c, Status__c, and line items as a related list. Vendor records must be imported before Purchase Orders so that the Account lookup is satisfied. If the customer's Salesforce org already has a vendor management setup, we align the mapping accordingly. Purchase Orders are lower priority in the import sequence and are imported after Accounts, Contacts, and Opportunities.

Vtiger Projects with task dependencies and milestones map to Salesforce's Project object (available via Salesforce Lightning Sync or as a custom Project__c object). Task-level dependencies (Finish-to-Start) are preserved as custom dependency fields (depends_on__c, predecessor_task__c) if the standard Project object does not support them natively. Milestones migrate as custom Milestone__c records linked to the Project. Projects often have lookups to Accounts (vtiger_accountid), Contacts, and Potentials, all of which must exist in Salesforce before Project import begins. We sequence Projects after Accounts and Contacts in the import order.

Vtiger standalone Tasks and Project sub-tasks map to Salesforce Task. Subject, status, priority, due date, assigned user, and description migrate directly. Sub-task hierarchy is preserved where Salesforce supports it; otherwise we flatten sub-tasks to top-level tasks and flag the flattening in the reconciliation report. Task assignment migrates by resolving Vtiger owner IDs to Salesforce OwnerId via the User mapping. Recurring tasks are migrated as individual Task records with a custom recurrence_flag__c field rather than as native Salesforce recurring tasks (which use a different data model).

Vtiger exports attachments as individual files per record with no bulk download option in the standard UI. For migrations under 500 attachments, we extract files alongside their parent record, stage them in object storage, and re-associate them with the Salesforce parent record (Account, Contact, Opportunity, Case) via ContentDocumentLink. For migrations over 500 attachments, we stage files in object storage (S3-compatible) and process the re-association in batches post-import. This out-of-band file transfer adds a step to the migration timeline and requires the customer to provision adequate Salesforce Files storage. We validate ContentDocument checksums against the Vtiger source file list to confirm no attachments are dropped.

Vtiger custom fields on any standard object (Account, Contact, Potential, etc.) migrate as Salesforce custom fields with equivalent data types. Vtiger picklist values become Salesforce Picklist values; Vtiger multi-select picklists become Salesforce multi-select Picklist fields; Vtiger checkboxes become Boolean fields; Vtiger date fields become Date fields; Vtiger currency fields become Currency (18,2) fields. We generate a field-type comparison table during discovery that maps each Vtiger field type to its Salesforce equivalent. Custom field API names in Salesforce follow the __c suffix convention and must be validated against the destination org's field-level security settings before migration.

Vtiger workflow definitions (triggers, conditions, and actions created in the Process Designer) are configuration metadata rather than data records. They cannot be exported as a transferable payload and re-imported into Salesforce. We extract workflow definitions as JSON metadata and provide a re-implementation guide that maps each Vtiger trigger, condition, and action to its equivalent Salesforce Flow element (Get Records, Decision, Update Records, Create Records, Action). The customer's Salesforce admin or a certified partner rebuilds critical automations post-migration. Workflows with complex branching logic may require a Discovery Flow and multiple sub-flows in Salesforce, increasing rebuild scope.

Vtiger's multi-currency and multi-language settings (available from One Growth tier at $12/user/mo) require explicit configuration in the Salesforce destination org before Potentials, Quotes, and Sales Orders with non-USD currencies can be imported. We audit Vtiger's active currencies and currency ISO codes during discovery, then configure Salesforce's Manage Currencies settings to match before any monetary records are imported. Exchange rate history does not migrate; the customer's admin sets current exchange rates manually or via an AppExchange currency management tool post-migration. Multi-language labels (Vtiger's language pack for field labels and picklist values) do not migrate; we document any non-English picklist values for manual translation in Salesforce.