Migrate from SellingLane CRM to Freshsales

Buyer records from SellingLane migrate as Freshsales Contacts. Bidder ID, registration date, and bidder tier/standing preserve as custom fields on the Contact. Buyer verification status (approved, pending, suspended) is a custom property in SellingLane rather than a native enumerated field; we flag it as a mapped custom field during scoping and confirm the destination picklist values match the active SellingLane picklist. We also alert customers if any buyer's verification status is a deprecated value no longer in the active picklist. Deduplication uses email as the unique identifier for contacts.

Lots carry lot number, item description, reserve price, starting bid, and custom attributes. We map lot number to the product name or item name in Freshsales and preserve reserve and starting bid as numeric fields. Custom fields on lots are not schema-documented in SellingLane; we discover field definitions during the audit phase by querying the platform's field configuration endpoint and generate a complete field manifest before mapping to Freshsales. Reserve status logic (met, not met, withdrawn) may require a custom field in Freshsales since no native lot-status concept exists.

Bid records are not standalone in SellingLane; each bid links a Buyer to a Lot and carries a timestamp, amount, and bid type (floor, absentee, online). We sequence the migration to load Contacts and Products first, then import bids with their Buyer and Lot references resolved as Freshsales Contact and Product lookups. Bid records without a resolvable Lot or Buyer are held in a reconciliation queue. Bid type and timestamp migrate as custom fields on the Deal or Task. Bid ordering is validated against the original timestamp sequence.

SellingLane organizes lots and bids by Auction Event (sale date, location, catalog). Freshsales has no Auction Event object, so we map events as date-anchored parent records (Accounts with event metadata) or tags on lots. We flag this gap during the scoping call so the customer decides whether to reconstruct event groupings as custom objects or treat lots as independent inventory records. This decision affects reporting structure and must be made before the migration run.

Registration records include buyer ID, event ID, registration date, and payment method on file. We map these to Freshsales Contacts with custom registration fields attached, or to Deals if the customer's workflow treats registrations as pipeline entries. Registration-to-event linkage requires the Auction Event reconstruction decision to be finalized first.

Post-sale payment records include amount, method, date, and buyer association. We map these to Freshsales Deals with the buyer as the associated Contact. Trust-account balance carry-forward from SellingLane is flagged as a custom field requiring migration and confirmed against Freshsales schema before import.

SellingLane supports custom fields on auction listings and buyer records, but the schema is not publicly documented. We generate a complete field manifest during the audit phase and create matching custom fields in Freshsales before any data import. Any custom field with a deprecated or deleted definition in SellingLane is flagged and confirmed against live records for completeness before migration.

Item photos, condition reports, and registration documents attach to Lots and Buyers in SellingLane. We export attachments via the platform's file storage and re-associate them in Freshsales using naming conventions that link each file to the correct Contact, Product, or Deal record. We flag any attachment with a broken or missing parent record before import.

Auction staff assigned as lot owners or bidder managers map to Freshsales Users. We validate user email uniqueness and flag duplicates before import. Owners without matching Freshsales users are held in a reconciliation queue for the customer's admin to provision before record import resumes.