A hosted shop builder carries you reliably for the first few years. How to tell when it no longer does — and what a migration actually involves.
A hosted shop builder is a sensible decision at the start. It costs little, it runs without a server of your own, and it brings payment methods, shipping rules and order handling that you would otherwise have to assemble piece by piece. For the first few years that is usually enough.
At some point the balance tips. Not on a single day, but gradually: the shop keeps running exactly as before, but every change to it costs more time than it used to.
The catalogue grows faster than the tools. Two hundred articles can be maintained by hand. Twenty thousand cannot. When a round of price changes only fits outside business hours, because editing runs article by article in a browser, you have reached the limit.
The import stays a form. Many builders can read data in, but always their way: fixed columns, fixed order, no rules. As soon as a supplier's data looks different from the form, manual work appears — every single time.
Reporting is missing where you need it. Which articles have not sold in a year? On which is the margin below what you calculated? If those questions can only be answered with an export and a spreadsheet, you are already working beside the shop rather than in it.
Small wishes turn into big questions. An extra field on every article, your own price tiers, a different step at checkout: in a builder that is either provided for or it is not. The "not possible" answers add up over the years.
Anyone considering a move usually thinks about the appearance first. That is the smaller part. Setting up a shop system, styling it and connecting payment methods and shipping rules is manageable, plannable work.
A migration is decided by the data. The old system produces an export, and that export is almost never what the new system needs: categories sit as text in one column, variants stand next to each other as separate articles, manufacturers are spelled three different ways, prices sometimes include tax and sometimes do not, and some images are missing.
That is where the effort sits, and that is where it is decided whether the new shop is better than the old one or merely different. A data migration that simply carries the last few years of mistakes across moves the problem into a new system.
With a large catalogue, upkeep is not a side task but the actual work on the shop. It consists of three things that keep repeating.
Analysis. What is actually there? Which articles have no description, no image, no category? Where do names differ so that the shop's own search cannot bring them together? Building that report properly once pays off, because you need it again every month.
Filtering. Hardly any change affects the whole catalogue. It affects one brand, one series, one supplier list, everything below a certain margin. The difference between an hour and a week lies in whether that subset can be named reliably.
Price updates. New purchase prices, changed tiers, promotions with a start and an end date. As a run that can be traced and reversed — not as a series of individual edits after which nobody knows what applied yesterday.
With those three steps as a repeatable routine, a catalogue in the tens of thousands stays manageable. Done by hand, past a certain size you are only ever catching up.
Your own shop is rarely the only place you sell. Marketplaces, price portals and platforms come along, and each channel wants the data in its own shape: different categories, different mandatory fields, different image sizes, its own rules for titles and descriptions.
The temptation is to maintain each channel separately. That works exactly until a price changes. After that you pay the difference — as lost trust from customers who see two prices, or simply as margin.
The workable route is the other one: one maintained set of data as the source, from which every channel gets its own version. What changes on an article changes once.
Three questions that come before choosing a system, not after.
How many articles will there be in three years, and who maintains them? The answer determines how much automation pays off — and whether it pays off at all.
Which routines are genuinely your own? Anything standard should stay standard. Custom work pays off at the two or three points where you really do work differently from everyone else.
Who can change the system later? A shop only one person understands is a risk, regardless of whether that person is a contractor or sits in the building.
A migration is not worth it because another system is more modern. It is worth it when today's upkeep costs more time than the move plus the upkeep afterwards.
If you are wondering whether your shop still fits your catalogue: write me two sentences about how many articles you carry and what slows the upkeep down most. I will tell you honestly whether a move pays off — and if it does not, that too.