Visit your site URL. If it resolves to your branded auction site β even password-protected β you are clear to proceed. If you see a Bidsquare-branded page or a DNS error, stop and contact your onboarding manager before uploading anything.
DIY Data Migration Playbook
Moving your historical data onto Bidsquare yourself β every step in the correct order, with the context you need to avoid the errors that cause manual clean-up. Follow the sequence. Do not skip ahead.
Before You Start
What this guide covers, how to approach it, and the two things to confirm before you run anything.
A self-managed migration is completely achievable β auction houses do it regularly. The steps are straightforward and the system gives you clear feedback at each stage. The key is to work methodically: test small, verify before moving on, and resist the urge to push everything at once. Data that passes validation and links correctly the first time saves significantly more time than trying to fix a large upload after the fact.
Sample files for every step β download before you begin:
β What can be migrated
- Bidder / user accounts
- Consignor profiles
- Commission rules
- Bidderβconsignor account linking
- Historical auction events
- Historical inventory and images
- Inventory linked to consignments
- Hammer prices, buyer's premium, and winning bidders
β What cannot be migrated
- Bidding history (individual bids placed during a sale)
- Buyer invoices and payment history
- Consignor settlement documents and payout history
Historical financial records (invoices, settlements, payments) must be retained in your previous system or exported separately for your own records. They cannot be recreated in Bidsquare.
Before running any upload against your live Production admin, run a small test in Demo (demo.bidsquare.com/seller) first β typically 5β10 users, one consignor, one past event, and a handful of items. This lets you verify your file formats, spot column issues, and confirm linking works, with zero risk.
Once your Demo run looks clean, run a small batch in Production before committing to the full upload β 10β20 records is enough to confirm everything resolves correctly in your live environment. A small production test is the single most reliable way to catch environment-specific issues before they affect your full dataset.
Replace real customer emails with test addresses in Demo β e.g. yourname+test1@yourcompany.com β to avoid triggering real notification emails during test runs.
- Vault plan confirmed. The complete migration sequence (events, items, post-sale data, images, consignors, settlements) is available on Vault only. White-Label customers can upload users. Not sure which plan you're on? Check with your Bidsquare account manager.
- Your White-Label site is launched and connected to your admin. User uploads create accounts on whichever site your admin is connected to. If the site isn't live yet, those accounts land on Bidsquare.com instead β and can't be automatically moved. If your site is still being built but you need to upload users now, ask your onboarding manager for a soft launch β your site goes live and connected without being publicly visible to bidders.
- Platform paddle ranges are configured in Settings βΊ Platform. The system uses these to identify which bidding channel each bidder belongs to when you upload post-sale data. Get them right before uploading any auction data.
- You have the sample CSV for each upload type. Download fresh from each upload screen β don't reuse saved templates. Column names are case-sensitive and change with platform updates.
User and consignor data is loaded via CSV. Before you start building your spreadsheets, the Bulk Upload guide covers every supported column, required formats, and the most common errors. A quick read now avoids most migration support tickets. Steps 1 and 2 below include direct links to the relevant field sections.
Step 1 β Load Users
Recommended first. Loading users before anything else means consignor linking and post-sale buyer assignment work automatically. If users are loaded after other data, these links need to be verified manually.
The most common failure points in user uploads:
| Issue | What to do |
|---|---|
| Duplicate email addresses | By default, duplicates are silently skipped β your record count will be lower than your row count without any error. If you check Ignore Duplicates on the upload screen, the system will process duplicates rather than skip them, which can assist with clean-up. However, the best practice is always to fully review and deduplicate your user data before upload rather than relying on the system to handle it. The system can help, but it cannot make judgement calls about which record is correct. |
| Phone number format | US: 10 digits, no spaces, no country code β 2125551234. International: include country code prefix. Mixed formats will cause a subset of rows to fail silently. |
| Country codes | Use two-character ISO codes β US, GB, CA β not full country names. |
Do not set Preferred = 1 on your first upload |
This immediately triggers the Preferred Bidder email to every marked user, sending a batch of unexpected emails to your entire customer base. Set preferred status in a separate pass after migration is complete. |
Navigate to Users βΊ Users Search βΊ Add User βΊ Bulk Userlist CSV Upload and download the sample template. Never build your own template from memory β column headers are case-sensitive and must match exactly.
Upload your CSV. The system shows a validation summary before confirming β red errors must be resolved, yellow warnings are advisory. Hover any highlighted row for the specific issue. Confirm the upload, then verify the records-created count matches your expected row count.
Do not check Send Sign-Up Email during the upload itself. Confirm the upload results first, then notify customers as a separate, deliberate step.
How the sign-up email works
The Batch Actions β Send Sign-Up Email option in the Users list triggers the Complete Registration email template. This sends each user a personalised link that takes them directly to the login flow on your White-Label site. When they land on that page they are prompted to set a password and complete any missing profile details β address fields, for example, if those were not included in your upload. There is no temporary password. The system handles newly uploaded accounts gracefully: on first visit, the user sets their own password from scratch.
Using MailChimp or another email system instead
Many auction houses prefer to send a migration announcement from their own email platform β MailChimp, Klaviyo, or similar β rather than using the Bidsquare sign-up email. This is completely valid and often produces better open rates because the email comes from a familiar sender. Include your White-Label site URL and tell customers to visit and register or log in.
Either way, the experience for the user is identical: the first time any uploaded user lands on your White-Label site β whether they arrived via the Complete Registration link or just typed in the URL β they are walked through the same first-time setup flow to set their password and complete their profile.
Field reference, upload options, and email flows are covered in the Bulk Upload guide.
π₯ User Upload Reference βStep 2 β Create Commission Rules
Commission rules must exist before consignors. The consignor upload form requires a commission rule to be assigned to each record β the system will reject consignor rows without one.
Navigate to Consignments βΊ Commission and Rules βΊ Add New. Create every commission structure you use β flat rates, step-down tiers, VIP rates. Name them descriptively: Flat 25%, Standard Step-Down 35/25/10, VIP Flat 10%. Staff select rules by name when assigning consignors β ambiguous names cause errors.
One rule must be set as Default β this auto-fills when creating new consignments. Set this to your most common rate. The default can be changed at any time without affecting existing consignments.
When you upload your consignor CSV, each row requires a CommissionRule column that must exactly match the name of a rule already in the system. Create all rules first, note their exact names, and use those names consistently in your consignor file. A mismatch will fail that row.
Module 18 of the User Manual covers commission rule creation, calculation types (flat, tiered, step-down), and the Default rule behaviour.
π Commission Rules β User Manual βStep 3 β Load Consignors
Import consignor records and link each one to their user account. Getting this right enables consignors to log in and view their items, settlements, and portal from day one.
The consignor upload links each consignor to a user account via email address. If the user account does not exist yet, the link cannot be created and the consignor will have no portal access. Complete Step 1 (user upload) before running the consignor upload.
Download the sample CSV from Consignments βΊ Consignors βΊ Upload CSV before building your file.
- Each row is a consignor record β one per seller, not one per consignment.
- The
CommissionRulecolumn must exactly match a rule name from Step 2. - The
Emailcolumn should match the email of the corresponding user account from Step 1 β this is how the link is established. - The
PayeeNamefield is what appears on settlement documents β use the legal entity name, not the contact name, where these differ.
Navigate to Consignments βΊ Consignors and use the CSV upload option. After upload, spot-check several consignor profiles to confirm the linked user account appears on the Bidder tab. A missing Bidder tab means the link was not established β usually a mismatched email address.
Consignor Login is off by default per consignor. Once profiles are uploaded and linked, enable it in bulk via the consignor list or individually on each profile. Only enable after item cataloguing is complete β consignors can see their items the moment Login is enabled, even before the auction is published.
Field reference, linking workflow, and consignor portal setup are in the Bulk Upload guide.
π€ Consignor Upload Reference βStep 4 β Load Past Events via CSV
Create the historical auction shells that your items and post-sale data will be loaded into. Platform paddle ranges must be configured correctly before this step.
The system uses paddle number ranges to identify which bidding platform each bidder belongs to during post-sale data imports. If your platform ranges are not correctly configured before items and post-sale data are loaded, the system cannot auto-detect platforms and bidder assignments will fail or require manual resolution. Set up your platforms in Settings βΊ Platform before running this step.
Recommended ranges: Floor 1β499 Β· Phone 500β899 Β· LiveAuctioneers 900+ Β· White-Label/Website 2,000β6,999 Β· Bidsquare 7,000β9,999 Β· Invaluable 10,000+ (always the highest).
Past auctions can be created manually via Auctions βΊ Create Auction or via CSV upload. Use descriptive event names with the sale date. Set the auction type (Live or Timed) to match the original event. The auction will be used as a container for your historical lots β it does not need to be published at this stage.
Item uploads are done from inside each individual auction β navigate to Auctions βΊ [auction] βΊ Lots & Items βΊ Upload CSV. There is no bulk upload that routes items across multiple auctions in a single file. Work through your historical events one at a time, verifying each before moving to the next.
Module 5 of the User Manual covers Platform Settings in detail β paddle ranges, buyer's premium surcharges per platform, and how platform auto-detection works during post-sale imports.
π·οΈ Platform Settings β User Manual βStep 5 β Load Items via CSV
Import historical lot records into their auction shells. Use the consignor and consignment reference columns to back-fill historical consignments at the same time.
Navigate to the auction's Lots & Items tab and use the Upload CSV option to access the template download. Download fresh each time β never reuse a saved template, as column names change with platform updates.
Key columns for a historical migration:
LotNameβ the only required column for all upload types.LotNumberβ required when loading items into an auction.StartingBidβ required when publishing items to an auction.ReferenceNumberβ your internal legacy ID. Carry this through β it appears on barcode labels and makes future cross-referencing possible.
Upload your CSV into the auction's Lots & Items tab. Review the validation summary β red errors must be resolved before the upload can proceed. After confirming, check that the records-created count matches your expected row count, and spot-check a few lots before moving on to the next event.
Field names, aliases, and requirements for item uploads are in the Item CSV Upload Fields reference.
π Item CSV Fields Reference βStep 6 β Load Post-Sale Data via CSV
Upload outcomes for historical lots β hammer prices, buyer assignments, and invoicing data. This completes the financial record for past events and enables settlements to be generated.
Navigate to the auction's Lots & Items tab and select Upload CSV βΊ Post Sale Data. Download the sample file from that screen before building your file β the post-sale upload expects different columns from the standard item upload. It updates existing lot records rather than creating new ones.
The standard Post-Sale Data CSV upload handles historical winner data from any external bidding platform. LiveAuctioneers and Invaluable have a more streamlined import path in the live admin (because they are the most commonly used third-party platforms and their export files are well-known formats), but that is a convenience, not a technical requirement. Any platform β whether it's a legacy system, a different online bidding service, or an in-house solution β can be handled through the same two-step process: upload users first, then upload post-sale data via this CSV, provided you can extract the necessary fields (lot number, hammer price, buyer email, paddle number or platform name).
The one hard requirement: the platform must be correctly configured in Settings βΊ Platform with the right paddle number ranges before the post-sale upload runs, and the platform name in your CSV must match the configured entry exactly. When those conditions are met, the system will register winning bidders to the correct platform and make them available for invoicing.
LotNumberβ must exactly match the lot number already in the system from Step 5.SoldPrice(also: Hammer Price) β the final winning bid amount. Numeric only, no currency symbol.ItemStatusβ set toSoldorUnsold.BuyersPremiumβ the total buyer's premium as a dollar value. Can be left blank if platform-specific BP is configured and the correct platform is supplied.Emailβ the winning bidder's email address. Must match a user account in the system β this is how the sale is linked to a buyer for invoicing. Without it, the lot cannot be invoiced.Although a post-sale data upload can auto-create a basic user profile when it encounters an email address that doesn't yet exist, this is not the recommended approach. Auto-created profiles are minimal β they do not contain billing address, shipping address, phone number, or other details that a properly uploaded user record would include. Missing shipping addresses in particular cause issues downstream with tax calculations, as the system cannot determine the correct sales tax nexus without a valid address.
The correct flow is to ensure user accounts are fully created via the user upload (Step 1) before running any post-sale data uploads. If users have not yet been loaded, the email will not resolve against a full profile and the lot will show Reg N/A until a proper user account exists and is matched.
Bidder assignment β one of these two columns is also required:
| Column | How it works | When to use |
|---|---|---|
BidderNumber |
The winning bidder's paddle number from the original sale. The system identifies which platform that number falls under based on your configured paddle ranges and auto-registers the bidder accordingly. | Most common for migrations. Source data from other auction systems typically includes paddle numbers rather than platform names. |
Platform |
The platform name must exactly match a configured platform entry in Settings βΊ Platform, and that platform must have the correct paddle number ranges set up. When the platform name matches, the system auto-assigns a paddle number from that platform's configured range and registers the winning bidder accordingly β enabling invoicing and data migration for any platform, not just LiveAuctioneers or Invaluable. | Use when your source data identifies platforms explicitly but original paddle numbers are not available. The platform entry must exist and have correct paddle ranges configured before upload. |
After uploading, spot-check several lots in the Lots & Items tab. Lots showing Reg N/A in the Bidder column were not successfully linked to a buyer β usually a mismatched email address between your post-sale file and the user accounts loaded in Step 1. Resolve these manually by clicking the pencil icon on the lot.
Section 7 of the Item CSV Fields reference covers the Post-Sale Data upload columns.
π Post-Sale Data Fields βStep 7 β Load Lot Images
Upload images for historical lots. This step can be batched and run in parallel with other migration work β it does not block any downstream steps.
Image files must follow a naming convention that matches the identifier you'll use to bulk-assign them. The most common convention for migrations is Lot Number: [LotNumber]_[Sequence].jpg β for example, 101_1.jpg for the first image on Lot 101, 101_2.jpg for the second. Alternatively, use Item ID (the system barcode number) or Reference Number if those are more consistent in your source data.
Navigate to Auctions βΊ [auction] βΊ Lots & Items βΊ Bulk Load Images. Select the rename-by convention that matches your file naming. Upload your image folder. Files that don't match any item are silently skipped β spot-check a sample of items after upload to confirm images attached correctly.
If you are migrating thousands of images, discuss batching strategy with your Bidsquare onboarding manager before starting. Very large single uploads can time out. A phased approach β auction by auction, or in batches of a few hundred images β is more reliable and easier to verify.
The Barcoding & Warehousing guide covers bulk image upload β rename-by options, file size limits, and unmatched images.
πΌοΈ Bulk Image Upload Reference βStep 8 β Publish Past Events to Your Site
Once data and images are verified, publish historical events to your public-facing site. Your full bidding archive will be live and searchable for buyers and consignors.
Before making any historical event public, confirm:
- All lots have lot numbers assigned (Lotted/Unlotted counter shows 0 Unlotted)
- Post-sale lots show real buyer names β no Reg N/A remaining
- Spot-check hammer prices match your source records
- Images are loading correctly on a sample of lots
In the Auctions list, click the Cloud Published toggle for each historical event. The catalog becomes visible on your website immediately. Historical events published this way appear in your auction archive β buyers and consignors can browse past results and consignors with portal access can view their historical settlements.
If Consignor Login is enabled (Step 3), consignors will be able to see their items and historical results as soon as you publish. If consignor conversations about historical valuations are still in progress, hold off on publishing those events β or disable Consignor Login temporarily β until those conversations are complete.
Migration Sequence β Quick Reference
The complete dependency chain at a glance. Each row must be complete before the next begins.
| # | Step | Admin path | Depends on | Blocks |
|---|---|---|---|---|
| Pre | Site soft-launched and connected | Contact onboarding manager | β | Everything |
| Pre | Platform paddle ranges configured | Settings βΊ Platform | Site launched | Steps 4, 6 |
| 1 | Load users | Users βΊ Bulk Userlist CSV Upload | Site launched | Steps 3, 6 (soft β manual clean-up if skipped) |
| 2 | Create commission rules | Consignments βΊ Commission and Rules | β | Step 3 |
| 3 | Load consignors | Consignments βΊ Consignors | Steps 1, 2 | Step 6 (settlements) |
| 4 | Load past events | Auctions βΊ Create / CSV upload | Paddle ranges set | Step 5 |
| 5 | Load items via CSV | Auctions βΊ [auction] βΊ Lots & Items βΊ Upload CSV | Step 4 | Step 6 |
| 6 | Load post-sale data | Lots & Items βΊ Upload CSV βΊ Post Sale Data | Steps 1, 5 | Step 8 |
| 7 | Load lot images | Lots & Items βΊ Bulk Load Images | Step 5 | Step 8 (optional) |
| 8 | Publish past events | Auctions list βΊ Cloud Published toggle | Steps 5, 6, 7 | β |
Your Bidsquare onboarding manager is the right contact for migration-specific questions β particularly for edge cases like mismatched historical paddle ranges, bulk image batching strategy, or data that doesn't map cleanly to the standard column format. Don't try to work around a structural data problem with workarounds β a brief call will usually resolve it faster.
Phone: 1-800-657-0092 Β· MonβFri 9amβ6pm ET Β· support@bidsquare.com
Migration checklist
Work through this in order. Tick each item as you complete it β your progress is saved in this browser.
Phase 1 β Pre-flight
Before you upload anythingConfirm these are in place before running any upload. Getting any of them wrong causes problems that are hard to reverse.
Phase 2 β The migration
Run steps in order β verify each before moving onEach step depends on the one before it. Download the sample CSV fresh from the upload screen for each step.
Phase 3 β Post-migration verification
Before you call it doneSpot-check these before closing out the migration. Catching issues now is faster than resolving them after consignors and bidders have logged in.
The Bulk Upload guide covers the full field reference for user and consignor CSVs β including all column names, required formats, linking profiles, and a detailed common errors section. Keep it open alongside this playbook when running your uploads.