From one seller to many: what actually breaks when a shop becomes a marketplace

The request sounds contained. We have a working shop, we want other sellers on it, add vendor accounts. Estimated as described, it is a few weeks of work: a vendor table, a foreign key on products, a filter in the admin.

It is wrong because a marketplace is not a shop with more suppliers. A shop has one party who owns the catalogue, takes the money, ships the goods and handles the complaint. A marketplace splits that party into many, and every system that assumed a single owner has to be told who the owner is now. That assumption is usually not written anywhere. It is implicit in a hundred places.

First question, and it decides the architecture. Either each seller creates their own listing, or sellers offer against a shared product. Marketplaces for unique goods take the first; marketplaces where ten sellers stock the same SKU take the second, because otherwise the same item appears ten times and search collapses.

The second model is much harder and much better. It needs a canonical catalogue somebody moderates, an offer entity underneath it, and a rule that picks which offer wins the buy box. It also needs an answer for what happens when a seller wants to edit a description they do not own.

• Who may create a product, and who may only attach an offer to one.
• What happens to live offers when a moderator edits the canonical product.
• How duplicates are detected before they reach the catalogue, not after.
• Whether a seller leaving takes their listings with them, or the product survives without offers.

This is where the shop model breaks hardest. A customer adds items from three sellers and pays once. Underneath, that is one payment and three fulfilments, each with its own status, its own shipping cost, its own delivery date and its own possible cancellation.

Everything downstream inherits the split. The confirmation email describes three deliveries. The order page shows three statuses that move independently. A partial refund has to know which seller it came from. Support has to be able to cancel one part without touching the rest. Teams that model this as a single order with a vendor column rediscover the problem in production, usually during their first busy week.

The part that gets left until last and should be settled first, because it is regulatory before it is technical. If the platform collects the full payment and then pays sellers, in most of Europe the platform is handling other people's money and needs the arrangement to be right. Payment providers offer marketplace products precisely for this - split payments, connected accounts, funds that never pool in the platform's own balance.

On top of that sits the commercial logic: commission per category or per seller, when a payout becomes due, what happens to commission on a refunded order, how a seller sees what they are owed and why. A seller who cannot reconcile their own payout stops selling on the platform, and no feature elsewhere compensates for that.

Every marketplace underestimates this. A seller has to register, be verified, supply tax and bank details, load a catalogue, understand the commission and learn the rules. Each of those steps is somewhere a seller gives up, and a marketplace with no sellers has no inventory, which means it has no buyers.

The practical measure is time-to-first-listing. Whatever it currently takes, the work is to cut it. Bulk import that accepts the spreadsheet the seller already has beats a beautiful form they have to fill a hundred times.

The shop being replaced has ranking pages, and a marketplace migration changes URLs - often every product URL, because the structure now carries a seller or an offer. Done without a plan, that is the traffic disappearing exactly when the platform needs it most.

What that plan contains is unglamorous and non-negotiable: a mapped 301 for every old URL to its closest new one, canonical rules for the case where several offers share a product, and a decision about whether seller pages are indexable at all. Most of them should not be. Then a crawl before and after, so the loss is measured rather than assumed.

Nobody can switch a trading shop off for six months, so the migration runs in stages behind a live storefront. Catalogue model and offer entity first, because everything else depends on the answer. Then the order split, then payments and payouts, then onboarding. Seller-facing tooling last, and manually operated at first - a marketplace with three sellers does not need a seller portal, it needs three sellers.

Launch with a small number of hand-picked sellers on the real system rather than a pilot beside it. The failures worth finding are the ones that only appear when a real customer buys from two sellers at once.

We built and have maintained a Shopify storefront and marketplace for FineMeter for more than four years, which is long enough to have lived with every decision made in year one. For VidaPlayer we rebuilt a custom single-seller shop into a full marketplace: seller onboarding, catalogue ownership, orders split across vendors and the payout logic underneath.

Both took longer than the first estimate anyone gave. That is the honest headline of this article: the migration is worth doing and it is not a few weeks, and any quote that says otherwise has priced the vendor field rather than the marketplace.