Written by: JJ Tan, Founder, Jelly
Key Takeaways For A Smooth Stock Migration
- Decide what to migrate and what to archive, then map every field before touching data to avoid costly rework.
- Fix units of measure, yield conversions and supplier price files first so opening stock and recipe costs stay accurate.
- Run at least two full rehearsals in staging, follow a strict cutover timeline and reconcile opening stock immediately after go-live.
- Relink POS items to dishes and re-cost recipes post-migration to restore live GP visibility from day one.
- Jelly automates invoices, inventory and real-time menu profitability, onboarding UK hospitality businesses in under a week.
See How Jelly Protects Your Margin
Why A Stock Migration Is A Margin-Protection Project
A stock migration is a margin-protection project. Success depends on whether the new system reproduces the correct opening stock position, accurate recipe costs and live GP from day one. If the opening stock is wrong, every reorder alert is wrong. If recipe costs are wrong, every GP figure is wrong. If POS items are not relinked to dishes, GP visibility disappears entirely.
Jelly is built for growing restaurants, pubs and hotels that need to automate invoices, inventory and real-time menu profitability. Most operators see initial value within the first week. Invoices can be sent to a dedicated email address or photographed into Jelly, and photographed invoices usually generate value in less than 24 hours. Jelly connects to Square, EPOS Now, Toast and Lightspeed via real-time API. POS setup takes approximately five minutes. POS-to-dish linking only surfaces items sold since the integration was connected, which keeps mapping clean during a migration. Jelly integrates with Xero for one-click invoice push, with Sage coming soon, and charges a flat £129 per month per location. That combination turns the migration into a margin-protection exercise rather than a records exercise.
Action This Week: Write down the one number that tells you the migration worked, such as opening stock value, recipe cost accuracy or day-one GP. Treat that as your success measure.
With your success measure defined, the first practical decision is what data actually needs to move.
1. Decide What To Migrate And What To Leave Behind
Start by separating what still drives decisions from what only serves as history. Active SKUs, suppliers, categories, locations, recipes and opening stock quantities and values belong in the new system because they affect reorder alerts and recipe costs. Discontinued items, historical transactions, closed invoices and settled payments can stay behind because they add noise without improving daily operations.
In practice, 20–30% of master data typically ends up on the cleanup list. Dormant items are excluded because they poison reorder alerts and supplier price tracking. Migrating only active data reduces complexity and preserves auditability. For a UK hospitality operator, that usually means filtering your item list to ingredients with at least one purchase or sale in the last 24 months. Everything else goes on the archive list.
For your restaurant inventory migration, the core data to carry across includes a full item list with SKUs, on-hand quantities per location, unit costs and supplier details, followed by locations, categories and recipes. Recipe or menu-item data usually needs to be re-entered or carefully mapped separately, because ingredient-to-recipe mappings rarely survive a straight CSV export.
Action This Week: Filter your item list to items with at least one sale or purchase in the last 24 months. Move everything else to the archive list.
2. Map Your Fields Before You Touch The Data
Field mapping is where hospitality migrations differ most sharply from generic inventory migrations. Fields such as SKUs, ingredient categories, units of measure, supplier codes, recipe lines and yield percentages rarely map cleanly between systems. You need a deliberate translation document to handle them. Small field mapping mistakes compound across thousands of SKUs and create weeks of rework.
Build this table for your own data before you touch the import tool:
| Legacy Field | New System Field | Transformation Rule |
|---|---|---|
| Item code | SKU | Direct copy, ensure uniqueness |
| Product group | Category | Map to new category tree |
| Unit of measure | Stock UOM | Convert to base unit (g, ml, each) |
| Cost | Standard or average cost | Strip VAT, store net |
| Supplier code | Supplier ID | Match to cleaned supplier master |
| Recipe line | Ingredient line | Link to SKU, set quantity and UOM |
| Yield % | Yield % | Carry across, verify against prep method |
Your mapping document should record source fields, target fields, transformation logic and validation rules for every data type, including units of measure, item codes, location structures and status codes. Any field without a clear target is a field that will break at cutover, so treat unmapped fields as blockers rather than loose ends.
Action This Week: Build this table for your own data. Treat every field without a clear target as a cutover risk.
3. Get Units Of Measure And Yield Conversion Right
Cases versus units versus grams cause more wrong stock counts in kitchens than missing data. Unit-of-measure differences trip up more inventory migrations than missing data does. A missing conversion can understate consumption by around 80%. If a system treats a 5 kg case as a single stock unit, 40 kg of real usage reads as 8 units. That leaves theoretical stock artificially high.
The rule is to convert at the point of receipt, keep the supplier unit of measure on the purchase record and track in the consumption unit such as grams, millilitres or each. Three worked examples: 1 case of 24 bottles at 24 × 750 ml converts to 18,000 ml; 1 rice bag at 25 kg converts to 25,000 g; 1 tray of eggs converts to 30 pieces.
Yield must be applied on top of unit conversion. Ten kilograms of beef going into a slow-braised ragu might yield 6.8 kg after a 68% yield, and a recipe cost that ignores that loss understates the true portion cost by roughly a third. The Food Standards Agency’s guidance on metric units is the practical reason UK commercial kitchens should run grams and millilitres as the base unit throughout ordering, prep, recipe cards and portion specs.
For a deeper walkthrough of the stocktake process that follows a migration, see our Stock Management System Stocktake Process: 8-Step Guide.
Action This Week: Pick your top 20 ingredients by spend and write down the purchase unit, the count unit and the recipe unit for each. Fix any missing or inconsistent units before migration.
Once your units are consistent, the next source of margin error is supplier pricing, especially how you store gross and net values.
4. Clean Supplier And Price Data First
Supplier price files must separate gross and net values, because VAT-inclusive pricing distorts margin calculations. At the 20% standard rate, the VAT portion of a gross price is one sixth of it. To normalise a VAT-inclusive supplier price at the standard 20% rate, divide the gross amount by 1.2 to get the net amount. For example, £120 including VAT yields £100 net and £20 VAT. Store the net and VAT figures separately rather than only the final gross amount paid.
UK VAT registration and Making Tax Digital requirements mean that accurate net and gross separation applies to every VAT-registered hospitality business. Every supplier record must carry a unique ID. Duplicate supplier codes mean price alerts fire against the wrong record and reorder thresholds become unreliable from day one.
Action This Week: Export your supplier list and check that every supplier has a unique ID. Merge duplicates before migration.
5. Run A Full Rehearsal In A Staging Environment
Run at least two complete test migrations using real production volume data. The first run uncovers major errors. The second verifies that corrections work, because hidden errors only surface at scale rather than on sample products. A rehearsal catches missing quantities, bad SKU matches and broken supplier links while they are still cheap to fix.
Some teams run a third full rehearsal load. The first attempt often fails badly. The second usually fails in ways you can explain. The third should run clean and fit inside the cutover window on the hardware you will use for real. A load that reconciles perfectly but takes nineteen hours is not a passing test if your window is twelve.
Action This Week: Book a staging environment and a half-day with whoever owns the data. Run the import once and time it.
6. Follow A Cutover Timeline
Migrating data into a new stock management system without a sequenced cutover plan is the most common reason hospitality operators lose GP visibility for weeks. The table below gives the core sequence. Name an owner for every row before you start.
| When | What Happens | Owner |
|---|---|---|
| T-2 weeks | Mapping freeze, no new fields added | Ops lead |
| T-1 week | Full rehearsal in staging, reconcile outputs | Ops lead + finance |
| T-1 day | Final physical count, freeze legacy transactions | Head chef + ops |
| Cutover day | Transaction freeze, final extract, load, validate | Ops lead |
| Go-live | Go or no-go sign-off, open new system | Owner |
| Post-go-live | Monitor first 72 hours, reconcile opening stock | Ops lead |
| D+14 | Decommission legacy system, keep read-only before | Owner |
A freeze window of 24 to 72 hours in which no changes are allowed in the legacy system is a critical success factor shortly before go-live, because without it differences arise between the migrated data state and actual inventory.
Set your go or no-go criteria and your rollback trigger before cutover day. Set your rollback trigger before you are tired. For example: “We roll back if the trial balance does not tie by 6am Sunday.” At 6am Sunday with a load 90% complete, nobody rolls back voluntarily.
Action This Week: Put the cutover date in the calendar and work backwards. Book the final count and the go or no-go meeting now.
7. Reconcile Opening Stock After Cutover
Most migrations fail because nobody physically counted the highest-velocity SKUs before trusting the new system’s reorder alerts. Spot-check the top 20–30 highest-velocity items against a physical shelf count before switching off the old tool.
Opening stock must be reconciled on a defined cut-off date against the old system’s closing stock, because movements may be posted in a different period than the physical event. Count high-value, high-velocity and high-shrinkage items first. Set a variance tolerance before you start. Any item outside that tolerance gets a physical recount before the new system’s reorder alerts are trusted.
For a detailed guide to the ongoing stocktake process that follows, see our Stock Management System Stocktake Process: 8-Step Guide.
Action This Week: List your top 30 items by value and velocity. Count those first.
8. Decide Whether You Need A Parallel Run
A parallel run means both old and new systems process the same transactions simultaneously. For mid-market implementations, a parallel run typically lasts two to four weeks. It catches missing quantities, bad SKU matches and broken supplier links while they are still cheap to fix.
Parallel operation over two to four weeks enables direct comparison and gives teams time to practise processes in the new system without endangering ongoing operations. However, prolonged dual-system operation usually creates confusion. Parallel running should have predefined tolerance thresholds for inventory count variance, transaction latency and order status mismatches. Anything outside tolerance should trigger investigation before the cutover decision.
A parallel run is worth the effort if your inventory accuracy is already fragile or your team is adopting new operating models. A clean cutover usually works better when transaction volumes are manageable and your data is clean.
Action This Week: Decide whether you are running parallel or cutting over clean. Write the decision down and tell the team.
9. Relink POS Items To Dishes And Re-Cost Recipes Post-Go-Live
Recipes only draw down stock once each POS item points at the right recipe, so operators must confirm POS item-to-recipe mapping before go-live. This ensures a sale reduces the correct ingredients from the first order. A clean inventory system go-live means the system can deplete stock and report cost from day one.
In Jelly, POS-to-dish linking only surfaces items sold since the integration was connected. This keeps mapping clean during a migration and avoids the legacy menu clutter that plagues system-to-system moves. Connecting your POS takes about five minutes, as mentioned earlier. After go-live, check that every dish sold in the first service has depleted the correct ingredients. Fix any that did not before the second service.
For a step-by-step guide to POS integration setup, see our Stocktake Integration With POS: Step-By-Step Guide.
Action This Week: After go-live, confirm that every dish sold in the first service has depleted the correct ingredients. Fix any mismatches immediately.
Start Your Migration With Jelly
The nine steps above apply to any migration, but how much work each one takes depends on where you are starting from.
Migrating From Spreadsheets Vs Migrating From Another Stock System
The starting point changes the workload significantly. Spreadsheet migrations need more upfront data cleaning and SKU de-duplication before a single row is imported. System-to-system migrations need field mapping and export checks, but the data is usually more structured.
Most teams complete the CSV import itself in under an hour once the spreadsheet is cleaned up with consistent SKUs, one row per item and no merged cells, but verification takes a day or two of spot-checking the highest-velocity 20–30 items against a physical shelf count. The cleaning phase, not the import, is where time goes.
As noted in section 1, recipe mappings rarely survive a CSV export, so budget for re-entering that data separately from the item and supplier import.
If you are coming from spreadsheets, block two days for cleaning before you touch the new system. If you are coming from another system, request a sample export and check the field names against the mapping table in section 2 above. For a broader comparison of what to look for in a new platform, see our Inventory Management System Comparison: UK Hospitality.
Frequently Asked Questions
How Long Does A Stock System Migration Take?
For most UK hospitality operators moving from spreadsheets or a legacy system to a modern platform, the data cleanup rather than the system configuration is the biggest variable. Simple migrations with clean data can be completed in four to eight weeks from kickoff to decommissioning the old system. More complex migrations involving multiple sites, messy supplier data and recipe rebuilds can take longer. Jelly onboards and generates initial value in the first week. Price alerts and spending insights are live as soon as suppliers start sending invoices to a dedicated email address or the kitchen photographs invoices into the platform. That means you can start protecting your margin before the full migration completes.
What Is A Parallel Run And Do I Need One?
As covered in section 8, a parallel run means running both systems side by side for two to four weeks. The main decision is whether your inventory accuracy is fragile enough to justify the extra workload. If you do run parallel, set predefined tolerance thresholds for inventory count variance before the run starts, and maintain a daily reconciliation log tracking issue type, root cause, owner and resolution date.
What Data Should I Migrate And What Should I Leave Behind?
The rule from section 1 applies: migrate anything that will be needed to complete work in the new system, and archive anything that only serves as a historical record. For most operators, that means active SKUs, suppliers, recipes and opening stock move, while closed transactions and discontinued items stay behind. Many operators migrate opening stock balances while retaining historical stock movements separately for reporting and audit purposes. Keep the legacy system read-only for at least 30 days post-cutover so teams can still look up history when needed.
Who Should Own The Migration?
The business owner or operations manager should own the migration. The biggest misjudgment in migration projects is treating migration as a pure IT task, because it is a holistic operational challenge. For a UK hospitality operator, the owner or operations manager should own the overall migration, with the head chef owning recipe and ingredient data and finance owning opening stock reconciliation. Assign a named owner to each of the four data families: items, suppliers, recipes and opening stock. If nobody can name the person who signs off on each data object, the migration has no accountability and the numbers will be questioned in month two.
Conclusion: Turn Your Migration Into Margin Protection
You have now seen the full migration sequence: decide what to migrate, map fields, fix units, clean suppliers, rehearse, follow a cutover plan, reconcile opening stock, decide on parallel running and relink POS. Operators who protect their margin treat each step as a margin decision rather than a data-entry task.
Jelly is built for growing restaurants, pubs and hotels that need to automate invoices, inventory and real-time menu profitability. Most operators see initial value within the first week, often within 24 hours if they photograph invoices into the platform. Jelly connects to leading POS systems and accounting tools so stock, sales and invoices stay aligned.
If you are planning a cutover or already mid-migration, the next step is a conversation.