Move Item Data Without Tedious Rework

Organise item data first and clarify how it can be transferred

Clarify early with BonZumo whether your item data can be imported, prepared for transfer or set up manually, and who will check the chosen method. If you want to move your item data without tedious rework, you first need a clean source file and a clear target structure. That includes preparation: which items exist, which sizes belong to them, which price applies where, and which fields really need to be maintained in BonZumo later. If these questions stay open at the start, the rework usually appears only after the switch, right in the middle of daily service. Then your team notices missing sizes, unclear names, or prices that do not fit the menu you actually sell.

So your first step should be to save an unchanged backup of your current file. Never keep working directly in the only original spreadsheet. Create a copy for cleanup and note which columns already exist today, such as item name, category, size, price, product group, or tax reference from your previous system. That way, you can later trace whether an error already existed in the source file or only appeared because of a wrong assignment during the transition. This sounds basic, but it is exactly what saves time when someone asks later why one item is missing or why two prices suddenly look different.

Before transferring anything, you need to define the target structure in BonZumo

BonZumo works with maintained items, categories, and prices. Depending on how your business is set up, there may also be additional connections, such as recipes and ingredients or location-specific menus. Before setting up item data or using any available transfer method, clarify the file format, field mapping and who will check the result. You should first clarify how your offer should be structured in the target system: will a wine be managed as one item with several sizes, or as several separate items? Should side dishes appear individually? Which categories does your service and counter team actually need for fast selection later on?

These are not minor technical details. They determine how clear your POS will feel in everyday work. A typical mistake is carrying over the old structure without questioning it, even though it only grew that way for historical reasons. If you currently have a category like “Other Drinks” with 60 entries, daily selection will not get better just because the data was transferred completely. It is better to use the changeover to define the target structure consciously before anyone starts entering or moving data. A shorter, better-structured selection usually helps more than a perfect copy of an old list that nobody actually liked using.

Clear item names save you confusion later during service

Rework often does not come from missing data, but from unclear naming. So check every item and ask whether your team will understand it at a glance later. “Red wine 0.2 l,” “Red wine 0.5 l,” and “Red wine bottle” work better in practice than three entries all called simply “House Red.” Especially at the counter and in table service, every follow-up question costs time, and similar item names increase the risk of wrong bookings. The goal is not literary elegance, but unmistakable daily usability.

Also look for duplicate or near-duplicate entries. In a menu list, it is easy to find two drink names that look identical but carry different prices because an older entry was never removed. But do not delete these duplicates blindly. First check whether they really mean the same product or whether size, recipe, location, or sales context differs. What looks like a duplicate item may actually be an intentional variation. This matters especially if one venue sells a product in a different size, or if two similar items belong to different menu structures.

Sizes, variants, and units need to be treated as a separate decision

A lot of rework happens when sizes and units are mixed carelessly in one field. A hypothetical example: your drinks list contains “Apple spritzer 0.3,” elsewhere “Apple spritzer large,” and then “White wine 0.2/0.5” in a single cell. These mixed forms may look harmless in a spreadsheet, but later they are difficult to assign cleanly. So separate product name, size, and price as clearly as possible, both conceptually and during cleanup. If you do that work early, later checks become much easier because every row actually means one clear sellable thing.

The same applies to kitchen items and recipes. If you want to work later with ingredients and recipes, it must be clear which sales item actually represents which operational unit. A burger menu is something different from the individual burger, and a bottle of mineral water is something different from a glass. The more clearly you make these distinctions before the migration, the less often you will have to rename items afterward, create them again, or split recipes back apart. This is one of the places where a little discipline before launch saves a lot of repair work later.

It is better to check prices and number formats before the first test run

One common source of tedious corrections is inconsistent number formatting. In one file, prices use commas; in another, dots; sometimes there are even currency symbols or spaces included. Then you get values such as “7,50 €”, “7.5”, “7,500”, or empty cells for items that were temporarily unavailable. If those differences are not cleaned up first, you will later have to check many positions one by one. So review your price columns carefully for one consistent format and for missing values. Even small formatting differences can hide bigger practical problems once the list is transferred.

Also plan a simple total check. You should not compare only individual prices, but also the overall picture. If your cleaned list contains 180 sellable items, you should not suddenly end up with only 163 or 197 after migration. A quick look at the price range helps as well: do unusual values such as 0.00, 99.99, or 999.00 make sense, or are they placeholders, typing mistakes, or misplaced decimal points? These outliers are much easier to catch before go-live than during the first busy evening. A short manual review of suspicious values is usually faster than correcting dozens of mistakes under pressure.

Tax and sales-unit assignment should be a separate operational discussion

Many operators hope that tax assignments and similar business logic will automatically come out correctly during a system change. You should not rely on that. Whether an item is professionally assigned the right way needs to be checked against your offer and your existing master data. This matters especially if your file contains different item types, menus, takeaway shares, or older legacy entries. The technical transfer and the correct operational classification are two different tasks. One is about getting data into the right place; the other is about deciding what the data should mean in your operation.

For you, that means one practical thing: clarify in advance who in your business carries the content responsibility for these assignments. Usually that is not only a technical person, but someone who understands the menu, the sales flow, and the reporting. Write down for which item groups you want a separate review instead of approving everything in one go. That helps you avoid a situation where prices are visible, but items are still sorted incorrectly in daily work or misunderstood internally. It also makes discussions with your provider or technical contact more precise, because you know which groups need special attention before approval.

A small sample reveals errors earlier than a full migration

The safest way to reduce rework is a limited test run. Do not start with the entire menu. Start with a small but meaningful sample. Good candidates are items from different categories, for example a soft drink, one beer in two sizes, one wine, one main dish, one menu item, and one side dish. If this mix is set up cleanly and appears correctly, you can identify much faster whether names, categories, prices, and sizes have arrived logically. You do not need volume first; you need contrast first.

Then check this sample exactly where your team will actually work later. Does the item appear in the right category? Is the name short enough for quick selection and clear enough for daily sales? Is the price correct? Do variants appear where people expect them? This step is especially important with location-specific menus. An item can be set up correctly in principle and still appear in the wrong location, or be missing in the right venue. That is why a sample should not only be checked in a spreadsheet view, but also in the actual sales context where the team will search, select, and sell.

The sales view matters more than the spreadsheet view

An item list can look complete on screen and still be impractical in daily work. That is why the key question is not only whether fields are filled, but how the menu later appears in sales. In BonZumo, your team works with items, categories, and the actual selection for table service or counter sales. So after every migration step, you should check the sales view and ask whether the structure works for real orders instead of merely looking tidy in a table. A technically complete list is not the same thing as a usable sales setup.

Use typical daily situations for this test, without triggering productive changes during live business. A hypothetical example: two wine sizes, one drink with a similar name, one menu with a side dish, and one item offered only at one location. If your team can find these cases quickly and understand them clearly on screen, the migration is far more successful than if only the row count of the original spreadsheet happens to match. In practice, service speed and selection clarity are the real test, because that is where bad structure becomes visible immediately.

Only migrate recipes and ingredients once the sales items are stable

If you want to work with recipes and ingredients, it is tempting to migrate everything at once. In practice, it is often more sensible to first stabilize the sellable items and only then add the deeper operational layer. A recipe is not very useful if the related sales item still has to be renamed, merged, or moved to another category afterward. Every later change then creates more adjustment work elsewhere. What felt like efficiency at the start can quickly become repeated cleanup across several connected areas.

So a sensible order is this: first lock down sales items, categories, sizes, and prices cleanly, and then build recipes and ingredients on top of that. This also makes later costing and inventory work easier, because you are working on a stable structure. If you run several locations, also check whether one recipe is really used the same way everywhere or whether menus and offers differ by venue. Location-specific menus only help you if the underlying item data is already organized clearly. Otherwise, you risk maintaining operational detail on top of item names that still change during the final setup.

Approval should be an acceptance step, not a gut feeling the night before

Do not approve the data just because the list “mostly fits.” Instead, define exactly when the migration counts as accepted from your point of view. A useful acceptance step consists of a few clear points: the item count is plausible, spot checks from each important product group are correct, unusual prices have been checked, sizes are separated cleanly, and the selection in sales is understandable for the team. Only when these points are met should you build the rest of your setup on top of it. This turns the handover into a controlled decision instead of a last-minute guess.

At the same time, plan for some remaining work on purpose. Not every menu is so clean that absolutely nothing needs adjustment after a first migration. The goal is not some magical zero-rework promise. The goal is that only small, deliberate corrections remain instead of hundreds of individual repairs under pressure. If a provider or your internal technical team shows you the concrete migration path, ask them to explain exactly which preparation you need to deliver yourself, which checks happen together, and who carries the final operational approval. Then the system change becomes a controlled master-data process instead of a surprise package just before launch.