Eagle to KiCad Conversion: Legacy ULPs and KiCad 9 Import Compared

Two conversion routes with different guarantees

Moving a design from Eagle to KiCad can involve two different mechanisms that are often discussed as if they were interchangeable. One is a legacy set of Eagle user language programs (ULPs) that generate KiCad files from inside Eagle. The other is the import path built into KiCad, which reads Eagle 6.x or newer XML project files directly. They assume different versions, fail in different ways, and rest on different documentation. This article keeps the two separate and describes what a reader should verify after either route. No conversion was performed for this analysis; the description is documentary.

What the legacy ULP route covered

The eagle-to-kicad project README describes five ULPs and one include file that work together or stand alone to convert Eagle 6.xx schematic and PCB files, with 7.xx and 8.xx marked as a maybe rather than a supported range. That distinction matters: 6.xx is the stated basis, while later versions are left open in the source itself.

The workflow is staged rather than single-shot. run-me-first-from-eagle-sch.ulp begins by filling in missing part-prefix numbers; fix_via_hack.ulp converts unconnected vias to pads; eagle6xx-sch-to-kicad-sch.ulp builds the schematic and project files; exp-lbrs.ulp extracts libraries; and eagle-lbr2kicad-1.0.ulp converts Eagle libraries to KiCad library and module files. The README warns that these ULP filenames collide with Eagle’s own and should not be installed in Eagle’s ULP directory, and it asks users to back up their Eagle schematics and boards before starting.

The same document is explicit about the limits. It states that the scripts only work correctly for KiCad 4.7 or 5.1.x and may not work on other versions, a narrow window that says nothing about KiCad 9. It also records a PCB-level defect: on Eagle PCB import, vias and tracks that are not connected to a pad with a track do not retain their net information, so KiCad’s flood fill will not connect to them. The project’s workaround is the via-to-pad conversion step, plus documentation of unconnected vias and tracks on Eagle layers 150, 152, 153 and 154.

Other losses are documented in the same README. Eagle oval pads come through as round pads, and Eagle PCB design rules are not imported into Pcbnew. The README also warns that schematic connectivity is interpreted differently: wires that terminate on a bus, another wire or a pad without an actual connection in Eagle become connected in KiCad when they end at the same location. These are not cosmetic differences, because they change what the netlist means.

What KiCad 9 documents for direct import

The KiCad 9.0 manual lists Eagle *.sch and *.brd files in XML format from version 6.x or newer among the project types that can be imported as complete projects. The procedure starts from File > Import > Non-KiCad Project, and the schematic and board files should share a base file name, such as project.sch and project.brd. Standalone schematic and board files can instead be imported from the Schematic Editor or PCB Editor through File > Import > Non-KiCad Schematic or Non-KiCad Board File, but those imports must then be linked together into a KiCad project manually. That last point is the practical difference between a project import and two files that merely load.

Library handling is a separate operation. The PCB Editor documentation lists Eagle footprint libraries with the .lbr extension among readable formats and states that non-KiCad footprint libraries can be migrated to KiCad’s .pretty format with the Migrate Libraries button. It also states that KiCad writes only its native format and treats other library formats as read-only, so an Eagle library must be migrated before it can be edited as a KiCad library. Importing a board does not perform that step.

The manual’s scope statement names Eagle 6.x or newer in XML format. It makes no claim about earlier binary-format Eagle files, and a format appearing in the support list is not a statement that every object inside a supported file converts cleanly.

Why equal net counts prove nothing

A frequent shortcut is to compare the number of nets before and after import. As a conditional example, a design with 12 expected nets and 12 imported nets shows matching totals. That result does not establish equal connectivity. Twelve nets can be renamed, merged, split or attached to different pads while the total remains twelve, so the count is a coarse sanity signal rather than evidence of equivalence.

Checks that carry real information include:

• Net membership per pad. Compare which pads belong to each net, not just how many nets exist.
• Pad mapping and geometry. Confirm pad numbers, shapes and sizes survived; the legacy README’s round-pad note shows that shape information can be lost.
• Copper zones. Refill zones and inspect them. The PCB Editor documentation notes that disabling the refill option before DRC can produce incorrect results if zones were not refilled manually.
• Disconnected vias and track segments. Look specifically for items with no net assignment, the failure the legacy README describes.
• Layer mapping. Verify that silkscreen, mask, paste, mechanical and copper layers landed where intended rather than being stacked onto a default layer.
• Schematic-to-board consistency. Run the Design Rules Checker with the schematic parity test enabled; the manual describes DRC as verifying that all pads are connected according to the netlist or schematic.

DRC is a check, not a repair. A clean report means the board agrees with the netlist and the board setup. It does not mean the imported schematic preserves the original Eagle intent, so labels, multi-part gates and bus entries need their own review, all of which the legacy project treats as difficult cases.

A defensible evaluation sequence

For a real migration, a practical order is to back up the Eagle source, import into a scratch KiCad project rather than over an existing one, compare net membership and pad assignment against the Eagle source, refill zones and run DRC with schematic parity enabled, then inspect the schematic for label and gate-level differences. The legacy ULP route remains relevant mainly as a historical or narrow-version option, since its own README limits it to KiCad 4.7 or 5.1.x. The built-in importer is the documented path for Eagle 6.x and newer XML projects in KiCad 9.

Related reading on this site: PcbDraw – KiCAD board into a nice looking 2D drawing for documentation output after a board is verified, and Creating footprints in KiCad using a scanner for rebuilding library parts that did not migrate cleanly.