Migrate your Sugar Sell data

Sugar's Accounts module stores company records and is the parent object for most other records. Standard fields include name, industry, website, phone, and address. We migrate Accounts 1:1 with all standard fields and remap any custom Account fields from the source system.

Contacts are people linked to Accounts via a relationship field. Standard fields include name, title, email, phone, and address. We preserve the Contact-to-Account relationship during migration and handle duplicate detection based on email address and name.

Sugar Leads are separate from Contacts and have their own lifecycle stage and status fields. We migrate Leads with all standard and custom fields, preserving Lead status values (New, Assigned, In Progress, Converted, etc.) and the conversion mapping to Accounts and Contacts.

Opportunities track deals and are the core pipeline object in Sugar Sell. Standard fields include name, amount, date_closed, sales_stage, and probability. We preserve pipeline stage values and any custom Opportunity fields; we recalculate derived fields like weighted_amount if the destination has different rounding rules.

Activities in Sugar are split into Calls, Meetings, and Tasks, each with status, date, duration, and related parent fields. We migrate Activities linked to migrated Contacts, Leads, and Opportunities, but the parent reference must be resolved after the parent records are created in the destination. Open vs. closed status is preserved.

Sugar's Cases module (also used for Bug tracking) stores customer service records with priority, status, resolution fields, and associated Account/Contact. We migrate Cases but the Bug-specific fields (like type=Bug) require field-level mapping if the destination uses a different taxonomy for cases vs. bugs.

Quotes in Sugar Sell include line items, pricing, and a PDF generation capability. We migrate Quote records with their associated Product_bundle records. Tax and discount fields are preserved field-by-field.

Sugar's Product Catalog stores product definitions with pricing, description, and categorization. We migrate Products and their associated Manufacturers and Product Types. Where the destination uses a different product schema, we map fields to the closest equivalent and flag any products that cannot be represented.

SugarBPM defines workflow automation tied to module events and conditions. Workflow definitions, sequences, and alert templates are migrated as named records. Any workflow that references a custom field requires that custom field to be present first, so we sequence the migration accordingly.

Custom fields added via Sugar Studio require vardef file changes and are not exposed in the standard CSV export. We extract custom field definitions from the vardefs or Module Loader package, create equivalent fields in the destination before data migration, and then populate them. Sugar Sell Essentials cannot use Module Loader.

Sugar Notes store both text and file attachments. We migrate Notes as text entries and handle file attachments by extracting them from the Sugar file system or API response, re-uploading to the destination's document store. File size and MIME-type restrictions are preserved.

Sugar Reports and saved Dashboards are stored as serialized view definitions tied to module field IDs. We migrate the report structure but field ID references must be remapped to the destination field IDs, which may produce broken links that require manual verification post-migration.

Sugar Users map to Owner assignments on records. We migrate User records with their role, team, and status. Team membership determines record-level access in Sugar, so we recreate the team hierarchy in the destination before assigning ownership.

Sugar uses Tags as a flexible labeling mechanism across modules. Tags are stored as string values linked to the record. We extract all Tags, create matching tag sets in the destination, and relink them. Sugar Lists/Segments (used for marketing) require separate handling as they are query-based, not record-based.