From Spreadsheets to Software: The 6-Week Plan We Use to Migrate a Food Co-op's Order Sheets, Price Lists and Delivery Routes

What a food co-op's spreadsheet system actually looks like before migration

Almost every co-op we onboard arrives with the same three artefacts: a master order workbook with one tab per producer, a set of price lists sent by email as separate files, and a delivery list that lives in a phone notes app or a printed sheet in the van. Nothing is wrong with them. They just stop scaling.

The detail matters more than the structure. Inside the order workbook you will typically find customer names typed three different ways ("M. Horvat", "Marija Horvat", "horvat marija"), quantities recorded in whatever unit the producer speaks in (kg for potatoes, bunch for chard, crate for tomatoes, piece for eggs), and prices that are sometimes with VAT and sometimes without depending on who sent the file. There are usually a few merged cells holding a note like "only if it rains less this week" and at least one formula pointing at a tab that was deleted last autumn.

The delivery side is even more informal. Routes exist as knowledge in the coordinator's head: which village comes before which, who is never home before 17:00, which restaurant needs a delivery note signed. Migration is not just typing this into a database. It is the first time most of these rules get written down at all, which is why the first two weeks are about capture, not configuration.

Master order workbook: one tab per producer, one column per order week, customers as free text
Producer price lists: separate files or email bodies, inconsistent units and VAT treatment
Membership list: names, phone numbers, pickup point, sometimes a balance owed
Delivery information: route order, access notes and cut-off exceptions held informally
Shadow copies: a private sheet kept by a member who does the invoicing

The 6-week migration plan, week by week

The plan runs six weeks because a co-op's real unit of time is the order cycle, not the calendar. Six weeks gives you roughly four to six order cycles: two to observe and extract the rules, two to load and test data, one to run in parallel, and one to operate live with support still on hand.

Nothing in the plan requires the co-op to pause trading. Order weeks continue in the spreadsheet exactly as before until week five. That constraint shapes everything else, because it means data extraction has to happen against a moving target and every export gets re-pulled shortly before go-live.

Week 1: Discovery. Walk one full order cycle with the coordinator, from opening the sheet to closing the van door. Collect every file, including the ones nobody officially uses. Write down the cut-off times, the delivery days and the exceptions.
Week 2: Data cleaning decisions. Agree the unit list, VAT treatment per producer, minimum order quantities, pickup points and delivery zones. This is a decision week, not a typing week, and it needs the person who does the invoicing in the room.
Week 3: Load producers and products. Producer records, product catalogue, units, prices, availability windows, per-producer VAT rate. Producers receive their own Producer app logins and are asked to confirm their own catalogue.
Week 4: Load customers and delivery structure. Deduplicated members and business buyers, pickup points, delivery zones and route order, plus one test order pushed end to end through the Administrator, Producer and Delivery apps.
Week 5: Parallel run. One real order cycle entered in both the spreadsheet and Plodie. Compare totals per producer, per customer and per route before anything ships.
Week 6: Live cycle, sheet archived. The co-op runs the cycle in Plodie only. The old workbook is set read-only and kept as a reference, not as a working file.

Which spreadsheet columns map to which fields in the Administrator app

Mapping is usually a one-to-many exercise: a single spreadsheet column often has to be split across two or three structured fields, because a sheet stores everything as text and a platform stores products, units, prices and tax separately. The mapping itself is straightforward once the co-op has decided how it wants to describe things.

The recurring hard cases are units and price. A cell reading "kelj 2 veze 4€" contains a product, a quantity, a unit and a total price, and the unit price has to be derived. Similarly, a producer who writes "crate" needs the crate defined as a sellable unit with a stated weight, or shoppers will not know what they are buying and the delivery driver will not know what to count. We resolve these with the producer, never by guessing, because the producer is the one who has to pick and pack against that definition afterwards.

Producer tab name → Producer record (legal name, contact, VAT status, payout details)
Product row label → Product name + category + unit of measure (kg, piece, bunch, crate, litre)
Price cell → Unit price + VAT rate + whether the entered price is gross or net
"Min 5kg" note in a comment → Minimum order quantity on the product
"Only May to July" → Availability window / seasonal on-off on the product
Customer name column → Deduplicated customer record with pickup point or delivery address
Quantity cell → Order line with quantity and unit, tied to the order cycle
Route notes → Delivery zone, stop sequence and per-stop delivery instructions

The data-cleaning decisions that must be made before the first live order

Four decisions have to be closed before a co-op can take a real order in software: unit normalisation, VAT handling per producer, minimum order quantities, and one canonical customer record per buyer. Every one of them is a business decision belonging to the co-op, not a technical setting, and deferring them simply moves the pain into the live week.

Unit normalisation is the biggest. A bunch of chard is a legitimate selling unit, but it must be defined consistently so pricing, picking and invoicing agree. We keep the producer's natural unit wherever we can and attach an indicative weight to it, rather than forcing everything into kilograms and losing how the producer actually works. Crates and mixed boxes get defined explicitly, with contents listed.

VAT is the one that causes real money problems if it is skipped. In a typical co-op some producers are inside the VAT system and some are below the registration threshold, which means the same tomato from two farms is invoiced differently. Each producer gets a VAT status and each product a rate, and we always confirm whether the price the co-op has been quoting members is gross or net. Customer deduplication comes last and is mostly mechanical: merge the three spellings, keep one record, attach the history, and agree that new members are created in the platform only.

Giving producers their own logins instead of emailing an updated sheet

The single biggest workload change for a co-op coordinator is that producers stop sending price lists and start maintaining their own catalogue. Each producer gets a Producer app login, sees their own products, updates availability and prices before the cut-off, and receives their picking list for the cycle without anyone re-typing anything.

Onboarding producers takes patience and works best as a phone call plus a one-page printout, not an email with a link. We seed each producer's catalogue from their last price list so they log in to something familiar rather than an empty screen, then ask them to correct it. The first ask is small: confirm what is available this week. Price editing and seasonal windows come in the second or third cycle.

Expect a spread of adoption. In practice a co-op ends up with producers who update their own availability weekly, and one or two who still phone the coordinator. That is fine, and the platform should accommodate it: the coordinator can update a producer's availability on their behalf, so a low-tech producer never becomes a reason to keep the spreadsheet alive.

Failure modes we have seen, and how to handle each

Migrations rarely fail on data. They fail on habits and on the one person or producer who never made the transition. The parallel run in week five exists precisely to surface these while the spreadsheet is still there as a safety net, and the fixes are organisational as often as they are technical.

The most common is the shadow sheet: a member who keeps a private copy "just for the invoicing" and quietly becomes a second source of truth. It usually appears because the platform did not yet produce a report that person needed. The fix is to find out what the private sheet does that the software does not, add or export that view, and then agree a date when the copy stops being maintained.

The second is the unreachable producer before Friday cut-off. Handle it with a default rule agreed in advance rather than a scramble: either carry forward last week's availability, or mark the producer unavailable automatically if they have not confirmed, and tell every producer which rule applies to them. Whichever you choose, the co-op should never have to guess on Friday afternoon.

Shadow spreadsheet kept by a member → identify the missing report, build or export it, set a stop date
Producer unreachable before cut-off → pre-agreed default (carry forward or auto-unavailable) plus a coordinator override
Customers who order by phone or WhatsApp → coordinator enters orders on their behalf; keep the channel, move the record
Unit disputes at delivery ("that is not a crate") → indicative weights on every non-standard unit, printed on the picking list
Historic member balances → migrate as opening balances in week 4, reconciled against the old sheet during the parallel run
Coordinator becomes the only trained user → train a second person during the parallel week, not after go-live

Key Takeaways

Budget six weeks, measured in order cycles, not calendar days: discovery, data decisions, catalogue load, customer and route load, one parallel cycle, then live.
The hard work is deciding, not typing: unit normalisation, VAT status per producer, minimum order quantities and one canonical customer record must be settled before the first live order.
Map columns to structured fields deliberately. A single cell like "kelj 2 veze 4€" hides a product, quantity, unit and a price that may or may not include VAT.
Give producers their own logins with a pre-seeded catalogue so they confirm rather than create, and let the coordinator update availability for the ones who still prefer a phone call.
Run one full order cycle in the spreadsheet and the platform side by side. It costs one week and catches shadow sheets, unit disputes and cut-off gaps before they cost real deliveries.

For a closer look at where all this data ends up once the migration is finished, see One Platform, Four Apps, which walks through how the Administrator, Shopper, Producer and Delivery roles each handle a single order.

Frequently Asked Questions

How long does it take to move a food co-op off spreadsheets?

Plan for around six weeks, because the real constraint is the number of order cycles you can observe and test against rather than the amount of data to load. A co-op with a weekly cycle gets roughly four to six cycles in that window, which is enough for discovery, loading, one parallel run and one supported live week. Co-ops with fortnightly cycles usually need eight to ten weeks for the same number of rehearsals.

Do we have to stop taking orders during the migration?

No. The plan is built so the co-op keeps trading in its spreadsheet right up to the parallel week. Data extracted early is re-pulled shortly before go-live so nothing entered in the meantime is lost, and only the final week runs on the platform alone.

What happens to our historical order data and member balances?

Historical order lines are usually kept as an archived read-only copy of the old workbook rather than imported line by line, because past text-based records rarely map cleanly onto structured products and units. What does get migrated is anything still operationally live: member records, contact details, pickup points, producer catalogues and any outstanding balances, which are loaded as opening balances and reconciled during the parallel run.

What if some of our producers are not comfortable with apps?

Assume a mixed group and design for it. Producers who want to manage their own availability and prices get a Producer app login with their catalogue already seeded from their last price list, and those who prefer to phone or message the coordinator keep doing that while the coordinator records the update. A low-tech producer should never be a reason to keep a parallel spreadsheet running.

Can a small co-op with only a handful of producers justify moving off spreadsheets?

The trigger is usually complexity rather than size. A co-op with six producers, two pickup points and consistent units can run on a sheet for a long time, but once you add per-producer VAT differences, minimum order quantities, seasonal availability and a delivery route with sequencing, the manual re-typing and reconciliation start costing more hours per week than the migration itself.