Moving a Team Spreadsheet into an App Without Losing Data

On Monday morning, four people have the warehouse stock file open at once. A branch admin logs incoming goods, the warehouse lead corrects a returns figure, and someone in purchasing copies a tab for a meeting. By the afternoon the file says there are 140 cartons of liquid soap. The shelf holds 112. Nobody can tell which row changed, when, or who changed it.

This is usually the moment an owner decides to move the work into an app. That is a sensible call, with one trap. If you import a messy spreadsheet as it is, the new app inherits the same mess behind a cleaner screen. This guide covers what to check before importing, how to test with a small batch, and when to actually retire the old file.

Signs the spreadsheet has become the problem

Spreadsheets are great for quick notes. Trouble starts when one file becomes the working system for a whole team. These signs show up often in operations, finance, and sales:

• There are several versions of the file, say "Stock_final", "Stock_final_v2", and "Stock_USE_THIS", and the team argues about which one is right.
• The status column is free text: "ok", "OK", "done", "sorted". Filters and summaries stop being trustworthy.
• Approvals happen in chat. The file just says "approved by supervisor", with no date and no record of who approved it.
• A formula breaks on row 800 and nobody notices until the monthly report refuses to balance.

If two or three of these come up every week, patching the spreadsheet is probably already costing more than fixing the way the work is organized.

One sheet often holds three kinds of data

The most common mistake is treating each sheet as one table in the app. A single sheet often mixes three things: master data (items, customers, employees), transactions (goods received, orders, expense requests), and reports (monthly totals, branch summaries).

In an app, keep them apart. Master data is entered once and reused. Transactions always point back to master data. Reports are calculated from transactions, never retyped. For example, the warehouse file above could map like this:

Old sheet	Type of data	What it becomes in the app	Unique key
Item List	Master data	Item master	Item code
Stock In-Out	Transactions	Stock movements	Movement number
Monthly Summary	Report	Automatically calculated report	Not imported
Returns Log	Transactions	Stock movements with type "return"	Movement number

Look at the "Monthly Summary" row. Those totals do not need importing because the app recalculates them from the movements. Import both and you risk counting the same stock twice.

Clean a copy, not the original

Do all the cleanup on a copy, for example "Stock_for_import_2026-11-02.xlsx". The team keeps using the old file until the test import passes, so daily work carries on as normal.

On that copy, check the following:

1. One row, one record. Delete repeated header rows, subtotal rows, and merged cells. Importers read row by row, so a subtotal row turns into a phantom item.
2. Unique codes are actually unique. Sort the item code column and look for twins. "SBN-01" and "SBN-001" often turn out to be the same product.
3. Free text becomes a fixed list. Status, branch, and unit columns should each have a short list of allowed values, for instance branches limited to "North", "South", and "Central". Fix "Nth" and "north " (with a trailing space) now.
4. Dates and numbers are consistent. Make sure dates are stored as dates and amounts are not stored as text like "$1,200 approx".
5. Codes with leading zeros. A customer code like "00125" or a phone number can lose its zeros if it is read as a number.

That last one is easy to miss. Microsoft's guide to importing or exporting text and CSV files in Excel explains that you can set the data format of each column during import, including text, so values like these are not converted automatically. The same rule applies when moving data into any app: treat code columns as text, not numbers.

Decide who can do what

A spreadsheet usually has two access levels: you can open it or you cannot. Moving to an app is a chance to set permissions by role. Sketch them first in a simple table:

Role	Can add	Can approve	Can view
Warehouse admin	Stock movements for their branch	Nothing	Their branch's stock
Branch lead	Stock movements for their branch	Returns and damaged goods in their branch	All of their branch's data
Operations manager	Item master	Stock adjustments above 10 cartons	All branches
Owner	Nothing needed	Nothing needed	All reports

The table also settles questions that used to get resolved in chat: who approves, and what happens when that person is on leave. If approvals step up by amount, the same pattern works for purchasing, and it follows the same logic as a sales pipeline review for managers, where every stage has an owner and a clear condition for moving forward.

Test the import with 20 rows first

Do not start with 3,000 rows. Pick about 20 that cover the awkward cases: a code with leading zeros, transactions from two branches, one damaged item that needs approval, one return, and one row with a long note.

After the trial import, compare the result with the source file. For example, a check might look like this:

What was checked	In the spreadsheet	In the app	Outcome
Row count	20	20	Match
Code "00125"	00125	125	Set the code column to text
Total cartons received	346	346	Match
Branch names	20 filled	18 match, 2 typos	Clean up the branch list

Two small problems in 20 rows usually mean dozens in 3,000. Fix them in the copy, rerun the test until all 20 rows match, then do the full import.

Mistakes that sink the move

Importing every record since the business started. For stock, an opening balance on the cutover date plus the current month's transactions is often enough. Keep the older data as an archive.

Running both systems for too long. When the old file and the app run side by side for weeks, the numbers drift apart and the team stops knowing which one to trust. Pick one cutover date, such as the start of the month right after a stock count, then lock the old file as a read-only archive.

Copying the spreadsheet exactly. A "Notes" column that used to hold everything from PO numbers to return reasons should be split into separate fields with clear purposes.

Leaving master data without an owner. Who is allowed to add a new item? If the answer is everyone, the item list will be full of duplicates again within a few months.

If you want to try this in Sora

If your stock file, expense requests, or order tracker has become hard to follow, Sora is one option. You can describe how your team works or upload a spreadsheet, and Sora builds the app with roles, branches, approvals, and reports. The preparation above still pays off, because separating master data, transactions, and reports makes the result much easier to check. For shops and service businesses there are also ready-made app templates whose fields and approval steps you can adjust to match the permissions table you have already sketched.

Something to do today

Open the spreadsheet your team argues about most, make a copy, and label every sheet as master data, transactions, or report. Then sort the key column in the master data and count how many codes appear twice. Both steps take less than an hour and show you right away how ready that file is to move.