You Can Import Excel. Why You Should Leave Excel Habits Behind.

The most dangerous request in a PLM implementation is not “can we import our Excel files?” Of course you can. Almost every company I’ve worked with started with product information in spreadsheets, and importing that information is practical, fast, and usually the right first move. In this article I want to talk about the danger of keeping “Excel habits” 

Excel BOM habits are the conventions engineers develop to manage product structure inside a spreadsheet, such as storing revision in a filename or column, marking approval with cell color, and duplicating supplier data across workbooks. These are good practice within Excel’s constraints. They fail at organizational scale because they encode meaning that only the author knows. The clearest example is revision: Excel represents a change by copying the entire spreadsheet, because it cannot express that one line changed while forty others did not. Importing that convention into PLM preserves the data but leaves the organization unable to answer where a part is used, what changed between revisions, and which revision was released.

The dangerous request is the one that follows a week later: “can you make the new system work exactly like our Excel files?”

It sounds reasonable. The spreadsheets already exist. People know how to use them. The columns evolved over years, the naming conventions are understood, the colors mean something to everyone in the room. Why change any of it?

Because those conventions are not sloppy work. They are good practice, developed by capable engineers who found the best available way to manage product structure inside a tool that was never built for it. That is exactly what makes them dangerous to scale. A convention that works beautifully for one person, who knows what every column and color means, becomes an organizational liability the moment forty people have to interpret it without that person in the room.

Excel Does Not Just Store Your Data. It Teaches Your Team a Process.

A spreadsheet is a document. It captures a snapshot of information in a fixed grid at a fixed moment. Everything Excel cannot represent directly gets compensated for by people, and those compensations harden into habits over time. Revision information ends up in the filename. Approval becomes a green cell. Supplier details get copied into every workbook because there is nowhere else to put them. Two departments maintain two part number columns because neither will give up their convention. One person understands the formulas.

None of that is careless. It is a skilled adaptation to a constraint. But when a company imports those spreadsheets into a PLM system and asks for everything to behave the same way, it is not importing data. It is importing the workarounds and promoting them to requirements, which is how a personal best practice quietly becomes a company standard nobody ever agreed to.

Revision Is Where the Habit Shows Up First

Here is the pattern I see more than any other, and it is worth walking through carefully because it illustrates the whole problem in one place.

The team maintains a BOM in a spreadsheet. There is a revision column, usually next to the part number, holding values like A, B, C or 1, 2, 3. When something meaningful changes, someone duplicates the entire worksheet into a new tab, names it “Rev B” or “BOM_2026_03_14,” and continues working there. The old tab stays as the record. Over a year, the workbook accumulates eight tabs, and the file becomes both the current BOM and its own archive.

This works, in the sense that nothing is lost. It is a genuinely sensible thing to do in Excel. It also encodes two assumptions that are simply wrong outside of Excel.

The first assumption is that revision is a property you write next to a part. It is not. A revision is a controlled state of an item, with its own identity, its own approval, and its own point in time. Writing “B” in a cell does not create anything. It describes something that has to exist somewhere else, and in the spreadsheet, it does not exist anywhere else.

The second assumption is that revising a BOM means copying the whole BOM. This is the expensive one. In reality, revision is granular. A single component changed from one manufacturer part to another. The quantity went from four to six. One subassembly was replaced while the other forty lines stayed exactly as they were. Excel cannot express “this line changed and these did not,” so it flattens the entire question into a full-document copy. Every part in that BOM now carries an implied revision it never actually underwent.

A Copy of the Spreadsheet Is Not a Change Record

The cost of that flattening is invisible right up until the moment somebody needs an answer.

Which revision of this part was released, and where is it used? The tabs cannot tell you, because the part has no independent identity across them. What changed between Rev B and Rev C? Someone opens both tabs side by side and reads. On a forty line BOM that takes ten minutes. On a four hundred line BOM with a reordered structure, it takes an afternoon and produces a result nobody fully trusts. Why was that component replaced? That answer lives in an email thread, if it survived at all.

Now scale it. One engineer maintaining one workbook absorbs that cost quietly. Multiply the same practice across forty products, six departments, and a supply chain that receives exported copies, and the manual comparison becomes the actual change process. Nobody decided that. It arrived by import.

This is what I mean about the habit being more damaging than the data. The part numbers, descriptions, quantities, and supplier names in that workbook are genuinely valuable and should be preserved. The convention that a change is represented by a full copy of a document should not survive the import, because reproducing it inside a PLM system gives you the same blindness with a better interface and a monthly bill.

Restructuring Is Not a One-Way Door

There is a reasonable objection here, and it is usually the real reason teams ask for an exact replica of their spreadsheets. Excel is not just familiar. It is the format everyone downstream can open. Purchasing wants a spreadsheet. The contract manufacturer wants a spreadsheet. The quote request goes out as a spreadsheet.

That concern is solved separately from the modeling question. OpenBOM imports Excel out of the box and exports back to Excel just as fast, on demand, with the columns you choose. Nobody has to give up spreadsheets as a working format or a delivery format. What changes is where the authoritative structure lives.

That round trip matters more than it first appears, because it lowers the stakes of every decision I am about to ask you to make. Separating item properties from relationship properties, collapsing duplicate columns, and moving revision out of a cell are not irreversible commitments made under pressure at import time. The data goes back to a spreadsheet whenever you need it to.

Easy Import Is an Advantage That Comes With a Responsibility

Traditional PLM systems handle all of this by refusing to start. They demand a data model, object types, lifecycle definitions, and process rules before anyone can load a single BOM. That rigidity is why so many implementations stall in the modeling phase and never reach production.

OpenBOM takes the opposite approach deliberately. OpenBOM’s flexible and dynamic data model is created instantly when you import Excel (of course, an administrator can control it). Excel import works immediately, the grid is familiar, and a team can have a real BOM in the system on the first afternoon rather than the second quarter. I believe that is the correct trade. Getting your data in early is what makes every subsequent decision concrete instead of theoretical.

But an easy start puts the modeling decision back where it belongs, with you, and it does not make that decision disappear. Because OpenBOM will not punish a weak model immediately, it is entirely possible to import the workbook, keep the revision column, recreate the tabs as separate BOMs, and feel like the project succeeded. Everything works. Nothing is connected. The questions above still have no answers.

The fix is not a long modeling exercise. It is a short conversation held at import time rather than a year later, about which information identifies an item, which information describes how that item is used in a specific assembly, and which columns exist only because Excel could not represent a relationship. It is a conversation you can have with our team responsible for the onboarding training process helping you to understand how to go beyond a simple Excel import. 

Your Team Can Read Between the Cells. Software Cannot.

There is a newer reason this matters, and it is the one I’d weigh most heavily right now.

Your team compensates for spreadsheet conventions automatically. They know the green cell means approved, that the suffix in the filename is the real revision, that the two part number columns are redundant and the left one is authoritative. That knowledge is real, and it is entirely undocumented. It lives in the people who have been there long enough.

Software has no access to it. When you point an automated check or an AI agent at a BOM, it can only work with what the model actually states. OpenBOM’s BOM Review Agent today checks your BOM – part number, identity, properties, quantities, and structure. Every one of those checks depends on the data meaning and structure model OpenBOM creates and this is a big value down the road of your implementation. If the same physical part appears under three descriptions across three imported tabs, structure checks see three parts. The BOM Health AI algorithm will be confused by the wrong structure driven by old Excel formatting and this is an example of how bad data can lead to bad decisions, especially in the new AI world.

Undocumented convention was survivable when only humans read the BOM. It becomes a hard limit the moment you want anything else to read it – algorithms, AI, agents, etc.

Start With One Product, Not a Data Model Committee

None of this requires a multi year program. The practical sequence I’d suggest:

1. Import one real BOM for one real product. Not a cleaned sample.
2. Separate item properties from BOM relationship properties. Quantity, reference designator, and find number describe how a component is used in that assembly. They are not attributes of the part itself.
3. Collapse the obvious duplicate columns, the ones where two departments named the same thing differently.
4. Establish revision as a controlled state of the item rather than a column value, and stop creating a new tab per save.
5. Connect the CAD files and documents that currently sit in a folder referenced by a filename in a cell.
6. Name an owner for the information.
7. Export the result back to Excel and confirm the people downstream still get what they need.

Then take what you learned and do the next product. The point is not to arrive at a perfect model on day one. The point is to make sure the old spreadsheet does not quietly become the permanent architecture of the new system.

Once you import your Excel spreadsheet, make an assessment how much of this data can be automatically imported using OpenBOM Integrations from CAD systems. In fact, your manual Excel spreadsheet was possible a workaround and OpenBOM CAD Add-in can capture the data and files in a much more efficient way. 

Excel Is Where You Start, Not What You Rebuild

Import your BOMs. Keep the knowledge your teams accumulated. Keep exporting to Excel for everyone who needs it, because that never has to stop. Keep the parts of the existing process that still hold up when someone asks why they exist.

But when a spreadsheet habit comes up for import, ask whether it represents how your product is actually structured or how Excel forced you to describe it. Revision by full-document copy is the clearest case, and once you see it there, you will see it in the supplier columns and the approval colors too.

The practice was right for the tool. The tool is no longer the constraint.

REGISTER FOR FREE and check how OpenBOM can help you. 

Best, Oleg