BOMdocumentationworkflow

From Excel to LibreOffice: Migrating Your BOM, Gerbers and Documentation Without Losing Your Macros

UUnknown

2026-03-01

11 min read

Step-by-step guide for hardware teams moving from Microsoft 365 to LibreOffice—convert BOMs, preserve macros, and automate KiCad/Altium exports.

Stop losing nights to broken spreadsheets: a pragmatic migration path from Microsoft 365 to LibreOffice for hardware teams

Hardware teams juggling BOMs, Gerbers and assembly docs face a specific set of migration risks when moving off Microsoft 365: broken formulas, dead macros, and disrupted EDA automation. This guide gives you a step‑by‑step, practical route to migrate your spreadsheets, preserve or replace macros, and maintain automated exports from KiCad and Altium — without slowing down production or losing auditability.

Why migrate in 2026 — and what’s changed since 2024

Two trends make a LibreOffice migration realistic and attractive for engineering organizations in 2026:

Improved compatibility and automation — LibreOffice’s headless mode, UNO/Python macro support and compatibility layer for VBA have matured since 2023. This makes scripted conversions and macro-porting far less manual than before.
EDA and standards convergence — open-source EDA tools like KiCad now offer more robust CLI and Python APIs; supply-chain tools increasingly accept BOMs in standard CSV/JSON/IPC formats, reducing the need for opaque Excel-only pipelines.

“Move the logic out of fragile Excel-only workflows and into source-controlled scripts and standardized BOM outputs.”

High-level migration plan (90-day playbook)

Follow this 8‑step plan. The first two weeks are discovery and stabilization; the rest is conversion, validation, and rollout.

Inventory & risk classification (Days 1–7)
Establish canonical BOM formats (CSV/JSON/ODS) (Days 8–14)
Automate exports from EDA (KiCad/Altium) into canonical formats (Days 15–30)
Convert spreadsheets with headless tools and preserve formulas where possible (Days 30–45)
Extract & triage macros (Days 45–60)
Port critical logic to Python/UNO or controlled LibreOffice Basic (Days 60–80)
Validation, regression tests & pilot (Days 80–88)
Team rollout, docs & CI integration (Days 89–90)

Step 1 — Inventory: map your spreadsheets, macros and automation points

Before converting anything, build a clear picture of what you have.

Identify every workbook used in manufacturing, procurement and test. Tag each with owners, frequency (daily, weekly, one-off), and business impact.
Document automated flows: where KiCad/Altium exports feed those workbooks, where scripts read or write files, and any PLM/ERP integration points.
Mark complex features: pivot tables, data model/Power Query, external data connections, macros (VBA), and nonstandard formulas.

Deliverable

Create a spreadsheet or JSON file listing each workbook, its macros, and its export/ingest points. This file becomes your migration spec.

Step 2 — Canonicalize the BOM: adopt resilient formats

Relying on a single Excel file as the canonical BOM is high risk. Instead, publish canonical BOMs in one or more stable, machine‑readable formats:

CSV — simplest, universally accepted by vendors and assembly houses.
JSON — good for structured data (parts with attributes, alternate manufacturers, lifecycle states).
ODS — LibreOffice’s native workbook when a human-editable sheet is needed.

Tip: store canonical BOMs in Git or a company artifact store. Use semantic versioning for BOM releases (v1.0.0, v1.0.1).

Step 3 — Automate KiCad and Altium exports into canonical formats

Make your EDA tools publish canonical BOMs and Gerbers automatically. That reduces dependence on manual Excel edits.

KiCad (recommended approach)

Use KiCad’s Python scripting and the built-in BOM generator scripts to produce CSV/JSON BOMs and pick-and-place files.

Example workflow (high level):

Commit your board files (.kicad_pcb, .kicad_sch) to Git.
Create a Python script that imports the BOM generator from KiCad and writes CSV/JSON.
Run it from CI or a build server: it generates bom.csv, fab.zip (Gerbers), and pick-and-place CSV.

Example (conceptual) KiCad Python snippet:

#!/usr/bin/env python3
import pcbnew
# load board and call your BOM script to write CSV/JSON
board = pcbnew.LoadBoard('my_board.kicad_pcb')
# call a BOM plugin or custom logic to export BOM
# write bom.csv and placement.csv

Notes: exact APIs vary by KiCad version. In 2026, kicad-cli and pcbnew Python bindings are the standard automation paths.

Altium (recommended approach)

Automate Altium using its scripting interface or the Altium CLI if available. Export BOM to CSV and ODB++/IPC formats for fab.

Use Altium’s scripting engine (DelphiScript/JavaScript/TypeScript) to programmatic export.
For CI, run Altium Designer in a build node or use a licensed headless exporter if your procurement allows it.

Step 4 — Convert workbooks: tools and best practices

Use automated, repeatable conversions. Manual Save As each workbook will lead to drift.

Preferred tools

soffice (LibreOffice headless) — stable, scriptable office conversion. Example: soffice --headless --convert-to ods *.xlsx.
unoconv — wrapper that uses UNO; useful in scripts.
odfpy / ezodf — Python libs to manipulate ODS programmatically.
oletools (olevba) — extract embedded VBA modules from XLS/XLSM for analysis.

Example: batch convert XLSX -> ODS with headless LibreOffice

# convert all Excel files in a directory
soffice --headless --convert-to ods --outdir converted *.xlsx

This step preserves cell values and many formulas. Complex Excel functions or Power Query results may not survive unchanged.

Validating conversions

Automated diff: convert both Excel and ODS to CSV and run row/column diffs for critical sheets.
Unit test the BOM: compare quantities, reference designators, and part numbers programmatically.

Step 5 — Preserve macros: options and decision matrix

Macros are the hardest part of migration. Excel uses VBA; LibreOffice supports LibreOffice Basic and a VBA compatibility layer. Treat macros like code: test, extract, refactor, and put under source control.

Options

Use LibreOffice’s VBA interoperability — quick wins for simple macros. LibreOffice can run many VBA modules, but behavior is not guaranteed.
Port to LibreOffice Basic (StarBasic) — feasible for small macros. Similar syntax but different APIs.
Rewrite as Python scripts (recommended) — more robust, better for automation, and easier to test and integrate into CI/CD.
Externalize logic — move heavy logic out of spreadsheets into external services or scripts that read/write canonical CSV/JSON.

Extraction & triage

Extract VBA modules from XLS/XLSM with olevba (oletools).
Classify macros: UI-only (buttons, formatting), data transformations (BOM cleaning), or automation (export generation, calls to EDA tools).
For UI-only macros, consider converting to LibreOffice Basic or replacing with user instructions in a template.

Example: extract VBA to plain files

# Using olevba (install via pip install oletools)
olevba my_workbook.xlsm > extracted_vba.txt

Store extracted modules in Git. That makes porting and code review straightforward.

Step 6 — Porting macros: practical strategies and code examples

For durability and automation, we recommend porting critical macro logic to Python using LibreOffice UNO or to a standalone Python script that consumes the canonical BOM CSV/JSON.

Why Python?

Readable, testable, and easy to run on CI.
LibreOffice supports Python macros and UNO bindings; Python can also call KiCad/Altium scripts and REST APIs for part data.

Example: Python script to read BOM CSV, normalize fields, and write an ODS

import pandas as pd
from odf.opendocument import OpenDocumentSpreadsheet
from odf.table import Table, TableRow, TableCell

# read canonical CSV
bom = pd.read_csv('bom.csv')
# simple normalization
bom['MPN'] = bom['MPN'].str.strip()

# write a new CSV and let headless LibreOffice create human readable ODS later
bom.to_csv('bom_normalized.csv', index=False)

For direct ODS creation, use odfpy or ezodf. For interacting with an open Calc instance and running embedded formulas, use python-uno.

Example: invoke a LibreOffice macro from the command line

LibreOffice supports macro calls via the soffice CLI. This is useful for headless automation that still uses a small macro inside an ODS template.

soffice --headless "macro:///Standard.Module1.RunExportMacro('input.csv','output.ods')"

Replace Standard.Module1.RunExportMacro with your macro path. Use this only where rewriting is impractical.

Step 7 — Validation and tests: verify data integrity before cutover

Automate verification so human testers don’t have to manually check thousands of rows.

Write unit tests that assert totals, counts, and unique reference designators between old and new pipelines.
Run integration tests where BOMs generated from KiCad/Altium feed into downstream scripts and compare assembly outputs.
Keep a “golden board” — a single, representative design you use to test every change in the export/conversion pipeline.

Step 8 — Rollout, training and long‑term maintenance

A migration is as much organizational as technical. Plan for training, documentation, and change control.

Create a migration wiki with step‑by‑step how‑tos for common tasks (update BOM, run export, fix macro failures).
Train owners to use the new canonical workflows and scripts rather than ad‑hoc Excel edits.
Introduce PR/merge review for changes to scripts, not direct edits to canonical BOMs. Treat BOM changes like code.

Troubleshooting common migration pitfalls

Broken formulas

If a formula fails after conversion, identify whether it uses Excel‑only functions (e.g., LET, XLOOKUP, FILTER, Power Query). Replace those with:

standard LibreOffice Calc equivalents (INDEX/MATCH, VLOOKUP), or
external Python preprocessing that writes normalized columns back into CSV/ODS.

Pivot tables and data models

Pivots and Power Query transforms rarely survive direct conversion. Replace them with reproducible scripts that produce pivot-like summaries from canonical CSV/JSON.

VBA that calls external Windows COM objects or proprietary drivers

These macros must be rewritten. If the logic talks to a Windows-only API (ERP or vendor tools), keep that functionality on a Windows build agent and expose an API that your cross‑platform scripts can call.

Advanced strategies for enterprise hardware teams

Shift-left logic — move BOM validation and DRC earlier into EDA export scripts. That reduces spreadsheet complexity.
Single source of truth — use a Git repo for BOM CSVs, and require CI pipelines to run tests before merging BOM updates.
Use standardized interchange formats — where possible, adopt IPC‑2581, ODB++, or vendor-supported CSV schemas to reduce fragile custom parsing.
Component metadata — store part attributes (lifecycle, alternate MPNs, footprints) in JSON to decouple from presentation layer.

Case study: small hardware team migration (realistic example)

Acme Labs (12 engineers) ran a two-month migration in 2025. Their pain points:

20+ XLSM templates for BOMs and assembly checklists
Two VBA macros that ran daily to create pick-and-place files
KiCad designs with custom BOM generator scripts

Their approach:

Created a canonical bom.csv exported by KiCad and Altium automation scripts.
Extracted VBA modules with oletools and prioritized logic to port to Python.
Rewrote the macro that created pick-and-place files as a small Python CLI that called KiCad’s Python API and normalized fields.
Ran a one‑month pilot on three boards; validated outputs and trained the team.

Outcome: Less manual editing, reproducible BOMs in Git, and a 30% faster handoff to assembly. They kept one legacy macro inside LibreOffice’s VBA compatibility mode for a month, then retired it after porting.

Actionable checklist (copy this into your project plan)

Inventory all workbooks and macros (owners, usage frequency).
Define canonical BOM format(s): CSV + JSON + ODS for humans.
Create/commit KiCad/Altium export scripts to Git.
Batch-convert workbooks using soffice --headless --convert-to ods.
Extract VBA with olevba and store in version control.
Port critical macros to Python and add unit tests.
Run automated diff checks between old Excel outputs and new pipeline outputs.
Pilot with a golden board and finalize rollout docs.

Future-proofing: what to watch for in 2026 and beyond

Expect these trends to continue:

Better cross‑platform automation for LibreOffice and EDA tools, with more robust CLI tooling in KiCad and vendor tools.
Stronger adoption of standardized BOM schemas and PLM integrations, making spreadsheets less central to the manufacturing flow.
Increased government and enterprise migrations to open‑source office suites for cost and privacy reasons — which drives improved interoperability.

Key takeaways

Don’t treat macros as documents — treat them as code. Extract, version and test them.
Make EDA tooling produce canonical BOMs. Automate exports from KiCad and Altium into CSV/JSON so the spreadsheet becomes a view, not the source.
Prefer Python/UNO for durable automation. It’s more testable, CI‑friendly and cross‑platform than relying on VBA compatibility layers.
Validate with automated diffs and a golden board. Make data integrity checks part of your CI pipeline before cutover.

Resources & next steps

Start with these practical actions this week:

Run a quick inventory and tag the top 5 mission‑critical spreadsheets.
Use soffice --headless --convert-to ods on a non‑critical workbook and compare results.
Extract VBA from one XLSM with olevba and open the code in your editor — treat it like a refactor candidate.

Call to action

If you’re planning a migration and want reproducible scripts or a hands‑on workshop for your hardware team, start with a pilot project: pick one board, one BOM, and one macro. Convert them, automate the EDA export, and run the pipeline in CI. If you’d like, reach out to our team for a migration checklist, sample conversion scripts and a two‑day remote workshop tailored to your toolchain.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.