In short: Eagle keeps a design as separate XML files (.sch, .brd, .lbr, .dru) linked by name, while Fusion Electronics keeps schematic, board and libraries inside one cloud-managed design, so migrating means converting libraries and design rules carefully rather than just opening old files.
Why Eagle's file model still matters
Eagle (Easily Applicable Graphical Layout Editor) was created by CadSoft, bought by Autodesk in 2016, and then folded into Fusion 360 as Fusion Electronics. Autodesk stopped selling standalone Eagle in 2023 and ended support in 2026, so a large archive of hobbyist, startup and teaching projects now has to move. Understanding how Eagle structured its files is the fastest way to predict what breaks during that move. It also makes a good interview topic, because it forces you to explain how a schematic, a layout and a part library stay consistent. For the broader sequence these files belong to, see our guide to the PCB design flow.
Eagle's file structure: separate files, one name
Since version 6, Eagle files are plain XML, which means they diff cleanly in Git and can be scripted. A project is typically three kinds of file:
- .sch holds the schematic: sheets, nets, instances of gates and attributes.
- .brd holds the board: placed packages, copper, signal polygons, the Dimension outline and the design rules in effect.
- .lbr holds a library; .dru holds a design-rule set; .cam holds CAM-processor output jobs.
The link between schematic and board is nothing more than a shared basename. If power_amp.sch and power_amp.brd sit in the same folder, Eagle keeps them synchronized through forward and back annotation. Rename one without the other and the consistency check complains. This is simple and robust but fragile: there is no database enforcing it.
Library handling: symbol, package, device
An Eagle library separates three things that beginners often merge. A symbol is the schematic drawing with pins. A package is the physical footprint with pads, silkscreen and keep-out. A device set binds them: gates (symbols) are mapped to package pads through a connect table, and variants allow one symbol to offer SOIC-8 or DIP-8 packages. That mapping is where most real-world errors live. Swap pin 3 and pin 4 in the connect table and the schematic still looks perfect while the board is wrong.
Key fact: Eagle's schematic is only correct if the device's connect table is correct. ERC checks nets, not whether pin names match the datasheet.
Eagle libraries are loaded per project through the Library Manager, and a part placed from a library stays in sync only while that library is "in use." A frequent surprise is a schematic that shows a stale footprint because an old copy of a library was loaded first. Fusion Electronics improves on this: libraries are cloud documents with versions, and the package can reference a Fusion 3D model, so mechanical and electrical teams share one source. Reusing a packaging convention such as IPC-7351 naming across the library is what keeps either tool manageable.
Forward and back annotation in motion
The synchronization guarantee is the heart of Eagle's design. Edit the schematic and the board receives new airwires (forward annotation); swap a gate or rename a net on the board and the change returns to the schematic (back annotation). In Eagle this is live only while both files are open together, which is why editing a .brd alone and then losing the .sch is a classic way to corrupt a project. Fusion Electronics makes that coupling structural: the two views are tabs of one design and cannot drift apart.
Design rules: the .dru file versus rules inside the design
Eagle's design rules live in a .dru file edited through tabs: Layers, Clearance, Distance, Sizes, Restring, Shapes, Supply, Masks and Misc. A rule set is a text file you can keep per fabricator. The shipped default is conservative; a typical default uses roughly 8 mil clearance, while many low-cost fabs quote 5 mil trace and space capability or better. Loading the fab's .dru before routing is therefore one of the most valuable habits you can teach a junior engineer. We cover the theory behind these numbers in PCB design rules, and the fab-side limits in PCB design for manufacturing.
In Fusion Electronics, rules are stored with the board design and exposed through a Design Rules dialog, with rule categories for clearance, width, vias and manufacturing checks. Fusion also supports rule sets you can reuse, but the separate-file portability of a .dru is less obvious. In both tools, DRC measures the board against the rules; it will not tell you the rules were wrong for your stackup.
Key fact: A passing DRC only proves the board obeys the rule set you loaded. It says nothing about whether that rule set matches your fabricator.
Eagle versus Fusion Electronics at a glance
| Topic | Eagle | Fusion Electronics |
|---|---|---|
| Storage | Local XML files | Cloud project, versioned |
| Link between sch and brd | Matching filename | One design, two tabs |
| Libraries | .lbr files, per-project loading | Cloud library with 3D model references |
| Rules | Portable .dru file | Stored in design, reusable sets |
| Output | CAM processor .cam jobs | Manufacturing output jobs |
| Mechanical link | Export outline (DXF/IDF) | Direct sync with Fusion 3D |
Migration checklist that avoids surprises
Treat migration as a small verification project, not a file open. Work through these steps in order:
- Freeze the source. Run ERC and DRC in Eagle first and record the warnings, so you can distinguish old issues from new ones.
- Import libraries before designs. Check each device set's connect table against the datasheet for one connector and one multi-gate IC.
- Re-verify design rules. Confirm minimum clearance, drill and restring values survived the import; reload the fab rule set if not.
- Compare outputs. Generate Gerber and drill files from both versions and overlay them in a viewer; copper should be identical. See Gerber files explained for what to inspect.
- Audit layers. Eagle's numbering (1 Top, 16 Bottom, 20 Dimension, 21 tPlace) maps to named layers in Fusion; custom layers above 100 are where mapping errors appear.
An example: a four-layer sensor board with a 0.5 mm pitch QFN should show the same pad count, same paste aperture and same via drill in both exports. If the overlay shows a 0.05 mm shift on that QFN, your package was altered in conversion. Teams that move to Cadence Allegro, Siemens PADS or Altium later face the same library-first lesson, which is also why many choose open tools such as KiCad for archival projects.
What to learn next
Tool names change; the discipline of controlling libraries, rules and outputs does not. Practise on a small board, then scale up with stackup and layer planning from PCB stackup design. Our sister training brand ChipXpert runs hands-on VLSI and board-design programmes if you want mentored practice.
Ready to build real boards? Explore the PCB design tracks in our CourseTron courses and go from schematic to fabrication files with confidence.
FAQ
Can Fusion Electronics open my old Eagle .sch and .brd files?
Yes, Autodesk provides import for Eagle schematics, boards and libraries, but you should verify library connect tables, design rules and layer mapping afterwards, because the import is a translation, not a guarantee.
Why do Eagle projects need the same filename for schematic and board?
Eagle links the two by name so forward and back annotation can find the partner file. Renaming one file without the other breaks that link and triggers consistency errors.
Is the Eagle .dru file the same as Fusion's design rules?
They cover similar categories such as clearance, width, restring and masks, but Fusion stores rules with the design. Re-enter or re-check critical values against your fabricator after migration.
Should I keep using Eagle for existing designs?
For archival edits it still works, but with support ended you should plan a migration, and keep exported Gerbers alongside the source files as a safety copy.