Move a defined set of spreadsheet records into a shared system with field mapping, a small pilot, clear checks, and an agreed cutover. Use this practical first week plan.
On this page
A team decides to move its inventory out of a spreadsheet. The import completes, but colleagues continue editing the old file. A week later, the new system has one quantity, the receiving desk has another, and nobody knows which changes were included in the move.
A migration needs an agreed starting point and a clear end to parallel editing. The first week should establish which records are moving, how their fields correspond, how the team will check the result, and where new work will be recorded afterward. A small, verified pilot makes those decisions visible before the full set moves.
Choose a manageable first set of records
Select one business process and a defined set of records. An inventory catalog for one location is easier to check than every customer, supplier, item, and historic transaction at once. Write down what belongs to this first move and what remains outside it.
Name the business owner who understands the source, the person preparing the import, and the colleague who will verify the result. Give them access appropriate to their task. The person who runs the import may need help determining whether an unusual quantity or inactive item is correct.
Follow a hypothetical service visit through customer booking, staffing, equipment, delivery, and follow up. See how named owners keep changes consistent across the work.
·7 min read
Operations Insights
Spreadsheet Data Migration Guide for a Small Team | Figena
Define success in operational terms. The receiving colleague should be able to find an item, understand its unit and location, and identify the starting quantity. A successful upload alone does not establish that the records are usable.
Use the destination's current template or supported import format. Identify each field's meaning before preparing the file. Similar column names can hide different meanings: a supplier's product code may not be the team's own item identifier.
Scrollable article table
Source question
Mapping decision
Check before importing
What identifies the record?
Use the supported identifier and preserve a source reference
Two rows do not unintentionally describe the same item
What does the quantity count?
Establish the destination unit
Boxes and individual pieces are not mixed
Where does the record belong?
Match the actual destination location or grouping
Similar names refer to the intended place
What does a date mean?
Define the event and required date format
Preparation dates are not mistaken for delivery dates
Is this record still active?
Decide whether it belongs in the first move
Old records do not become current merely by being imported
Keep mapping decisions in a short working note. If a field has no supported destination, decide whether it should remain in an approved reference record. Do not place unrelated information in another field simply to preserve every column.
Prepare a controlled source copy
Retain the original in its approved location and prepare a separate working copy. Record the source file, preparation date, included range, and person responsible. Restrict access when the file contains information beyond the pilot's purpose.
Review duplicate identifiers, blank required fields, inconsistent units, spelling variations, and formulas. Decide whether the import needs a calculated value or a different representation supported by the destination. Reopen the exact output file to inspect what the receiving system will read.
Resolve ambiguous records with the business owner. Two rows named “Cable” might be duplicates, different lengths, or different units. Deleting one without checking can hide real stock. Preserve the decision and a reference to the original rows.
Keep a list of records excluded from this move and the reason. An unresolved row needs an owner and a next step so it does not disappear from the migration merely because it was left out of the file.
Run a small pilot and examine the result
Choose a pilot that includes ordinary records and meaningful variations. Include a record with a longer name, an inactive item if supported, different locations, and the units the team actually uses. Avoid relying only on a few unusually clean examples.
Use an approved test area where available. If a pilot must use the destination workspace, define its scope, permissions, and cleanup or correction procedure before importing. Make sure colleagues understand which records are being checked and where operational work should continue.
Read the import's actual result. A rejected file, accepted records, validation warnings, and an interrupted request require different next steps. Reconcile what exists in the destination before retrying an uncertain attempt; a second upload could otherwise create duplicate work.
Keep the prepared file and result references together. Correct the source and mapping deliberately rather than making unexplained edits until the import happens to succeed.
Verify records and business totals
Compare the destination with the prepared source at the same agreed point in time. Check the number of included records, their identities, and relevant totals. Compare quantities for the same item, unit, and location; a combined total of boxes and individual pieces has no consistent meaning. Explain intentional exclusions or conversions so a difference can be evaluated.
Totals are useful but can conceal offsetting errors. Two items can have reversed quantities while the overall sum stays the same. Inspect individual records across the variations in the pilot, including every corrected exception.
Scrollable article table
Verification area
Evidence to record
Scope
Included and excluded record counts
Identity
Correct names, identifiers, and source references
Meaning
Units, locations, categories, and applicable statuses
Values
Expected quantities or other supported values
Usability
A permitted colleague can find and interpret the records
Exceptions
Each unresolved difference has an owner and decision
Ask the business owner to accept the result against these checks. If an important difference remains unexplained, resolve it before treating the pilot as permission to move the full set.
Agree on the cutover and later changes
Set a cutover point for the affected process. Tell colleagues when the prepared source was captured, where later changes will be tracked, and when the destination becomes the working record. Define who can authorize an exception to that plan.
If work continues during preparation, keep a controlled list of subsequent changes. Reconcile those changes using the supported process before acceptance. Otherwise, the import can be accurate to yesterday's file and still be wrong for today's operations.
After cutover, make the old file clearly identifiable as a reference. Follow the organization's retention rules. Continue correcting the maintained record through the owning process, with source references where needed.
Figena's Inventory workspace provides a CSV template for importing items and starting quantities. Use that supported format for the inventory pilot. Other record types need their own supported transfer method and verification plan.
A hypothetical first week migration
Consider a hypothetical workshop moving the item list for one storage room. It selects twenty representative records for a pilot from a larger spreadsheet. Preparation reveals that one quantity counts sealed boxes while the corresponding item is normally issued as individual pieces.
The stock owner confirms the unit and corrects the prepared record before the pilot runs. The reviewer then checks item identities, units, location, and quantities in the destination. A colleague also confirms they can find the right item during a simulated receiving task.
The team agrees on a Friday cutover for the remaining approved records. Deliveries received after the source snapshot stay on a controlled change list until reconciled. The old spreadsheet becomes a reference after acceptance. This hypothetical sequence establishes a usable working record without leaving two editing locations in operation.
Keep the migration acceptance note short: scope, source snapshot, mapping decisions, pilot result, verification, exceptions, cutover, and accepting owner. Those references explain what moved and where the team should record the next real change.
Separate decisions, actions, and open questions in meeting notes. Use a practical handoff template to confirm owners, define completion, manage dependencies, and review the result.
Decide which inquiries deserve the next sales step using evidence of need, fit, timing, and decision process. With a decision matrix, two hypothetical examples, and a reusable lead review.
