Migrate from SellingLane CRM to Microsoft Dynamics 365 Sales

SellingLane Buyer records migrate to Microsoft Dynamics 365 Sales Contact. Bidder ID, registration date, and bidder tier or standing preserve as custom fields on Contact. Buyer verification status (approved, pending, suspended) is a custom property in SellingLane and maps to a custom picklist field in Dynamics; we validate the picklist values during the audit phase and alert the customer if any buyer's status is set to a deprecated value no longer in the active picklist. We cross-reference verification status against live buyer records to confirm data completeness before committing the migration.

SellingLane Lots carry lot number, item description, reserve price, and starting bid. There is no native Lot object in Microsoft Dynamics 365 Sales , so we pre-create a custom Auction Lot entity with fields for Lot Number, Item Description, Reserve Price, Starting Bid, and Reserve Status. Reserve-status logic (met, not met, no reserve) maps to a custom picklist. We also capture all SellingLane custom fields on lots during the audit phase by querying the platform's field configuration endpoint, since SellingLane's custom field schema is not publicly documented. We cross-reference every custom field against live lot records before committing the migration.

SellingLane bid records are relational: each bid links a Buyer to a Lot and carries a timestamp, amount, and bid type (floor, absentee, online). A flat CSV export of bids loses the Lot context unless we export Lots first and re-associate bids by matching lot_id in the destination. We sequence the migration to load Auction Lot records before Auction Bid records, include foreign-key references in our staging schema, and resolve the Contact (Buyer) lookup and Auction Lot lookup at insert time. Bid type and disposition preserve as custom picklist fields. Bid ordering must be validated against the original timestamp stack to ensure winning-bid ranking is correct in the destination.

SellingLane organizes lots and bids by Auction Event (sale date, location, catalog). Microsoft Dynamics 365 Sales has no native Auction Event object. We present two reconstruction strategies during scoping: build Auction Event as a custom parent entity with date-anchored lot groupings, or embed event metadata (event date, event name, location) as custom fields on the Auction Lot record and use Dynamics views to filter by event. The customer selects the strategy before migration begins. We flag this gap during the scoping call and document the chosen approach in the migration scope.

Registration records include buyer ID, event ID, registration date, and payment method on file. We map to a custom Auction Registration entity with lookups to Contact and Auction Event. Registration date and payment method on file preserve as standard fields. Where the destination org uses a native Registration entity from a third-party auction solution (for example, a Dynamics-certified auction app on AppExchange), we map to that entity instead and flag the integration during scoping.

Post-sale payment records include amount, method, date, and buyer association. We map to Microsoft Dynamics 365 Sales Invoice or a custom Payment entity depending on whether the destination uses Finance modules. Trust-account balance carry-forward values flag as custom currency fields on the Contact or Invoice. Payment method (check, wire, credit card) maps to a custom picklist if Dynamics standard payment fields do not accommodate the source values.

SellingLane supports custom fields on auction listings with a schema that is not publicly documented. We discover custom field definitions during the audit phase by querying the SellingLane field configuration endpoint, generate a complete field manifest, and pre-create matching custom fields on the Auction Lot entity in Microsoft Dynamics 365 Sales before any data loads. We flag any custom field with a deprecated or deleted definition in SellingLane that can silently drop values, and alert the customer before migration commits.

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 the destination using a naming convention that preserves the record context (for example, Lot-[lot_number]-[filename]). Microsoft Dynamics 365 Sales native attachment support or SharePoint integration handles the re-association, depending on whether the destination org has SharePoint document management enabled.

SellingLane uses auction-specific workflow stages (Registered, Won, Lost, Paid, Closed). These do not map directly to Dynamics Opportunity stages because the auction lifecycle is not a standard sales pipeline. We map auction stages to a custom picklist field on the Auction Lot entity or, if the customer uses Opportunities for post-sale settlement, we create a separate Record Type with stage values matched to the auction lifecycle. We flag any stage that has custom automation triggers in SellingLane for the customer's admin to rebuild in Microsoft Dynamics 365 Sales Flow.

SellingLane staff assigned as lot owners or bidder managers map to Microsoft Dynamics 365 Sales User records. We resolve owners by email match. Any SellingLane Owner without a matching Dynamics User goes into a reconciliation queue for the customer's admin to provision before record import resumes. We validate user email uniqueness across the destination org before migration begins.

Lots and buyers in SellingLane may carry classification tags for lot category, buyer type, or sale classification. We export tag sets and apply them as Dynamics multi-select picklist fields or Labels depending on the classification use case. Tag-based automations in SellingLane do not transfer; we document them separately in the automation inventory for the customer's admin to rebuild.