Migrate your YetiForce CRM data

Contacts are standard YetiForce records with name, email, phone, address, and assigned owner fields. The standard API exports Contact lists with all base fields. We migrate Contacts 1:1 and handle the Organization link by ensuring Organizations are imported before Contacts.

Organization records hold company-level data including address, industry, type, and assigned owner. Standard API exposes all base fields. We map Organizations first in migration order to preserve the parent-child link from Contacts.

Leads in YetiForce capture pre-conversion prospect data including source, status, and company name. The standard API lists all Lead fields. We preserve Lead_Source and Lead_Status as custom fields in the destination system.

Potentials are YetiForce's deal pipeline object tied to an Organization and an assigned user. We map Potential stage names to the destination pipeline stage values via a configuration table, as stage naming conventions vary between installations.

Projects hold name, status, start/end dates, and assigned owner. Custom fields on Projects may use YetiForce-specific data types (tree picklists, reference fields) that require type-aware mapping during migration. Project Tasks are children of Projects and must be migrated after their parent.

Project Tasks link to a parent Project and include subject, status, priority, and assigned user. We map the status and priority picklist values to the destination equivalents. Parent record ID mapping must be preserved to maintain the task hierarchy.

YetiForce Tickets include ticket title, status, priority, category, and related Contact and Organization references. Custom ticket fields require type-aware mapping. We handle the status picklist translation explicitly during import.

Products carry name, unit price, vendor link, description, and stock levels. The standard API exposes all core fields. We map the vendor reference to the migrated Vendor record by matching on vendor name during import.

Services represent recurring offerings with price per unit and description. They share the same data shape as Products in YetiForce. We migrate Services directly to the destination's equivalent product or service object.

Vendor records hold company name, website, address, and assigned owner. The standard API lists all base fields. We migrate Vendors before Products to preserve the foreign-key relationship between the two objects.

User records in YetiForce carry login, name, role, and preference data. Direct user-to-user migration is not supported — we map Users to the destination system by matching email address, then set the role and preference values manually post-import to match the destination's permission model.

File attachments in YetiForce are stored in the file system and linked via record ID. The standard API does not expose binary file download endpoints; we use YetiForce's built-in Export action per record or the batch file export path to extract attachments, then map them to the destination by record ID association.