Altium → KiCad, accounted for line by line.
What a standard migration silently leaves behind — and what Crosspad detects, repairs or flags instead. Every failure mode below is documented in KiCad's own docs and issue tracker, and this page is updated each release.
How to read this
What a typical Altium → KiCad migration does — documented in KiCad's own docs and issue tracker (linked on every row).
What Crosspad does instead — detect, repair where provable, or clearly flag. A capability, not a score.
Verified against your source, independently.
Detected and, where the fix can be proven safe, repaired — then re-validated. Unsafe fixes roll back.
Equivalence can't be proven automatically; surfaced for a human decision instead of silently reduced.
Read from a form KiCad cannot read, converted, and the conversion then counted independently against your source. Disagreement makes it unsupported, never a silent pass.
Named as not migratable, rather than passed silently.
Object by object, as of KiCad 10.0.6.
The matrix covers the whole Altium → KiCad move. At launch the migration service runs on one .PcbDoc board file, binary or ASCII text — sent on its own, or inside a .zip that holds exactly one board and is opened for that board alone. Schematic, project and library rows describe how those findings will be reported when those migrations ship, and are marked NOT YET IN SCOPE: zipping those files in beside your board does not migrate them.
| OBJECT CLASS | STANDARD MIGRATION | WITH CROSSPAD |
|---|---|---|
| Components / footprints | Migrated. documented: KiCad dev-docs | CHECKED |
| Nets & connectivity | Migrated; documented net-name / case edge cases. documented: KiCad dev-docs | CHECKED |
| Net class membership | Classes survive, but membership is dropped — rules constrain nothing. documented: KiCad #15584 | CHECKED |
| Design rules | Present, but bindings depend on net-class membership (above). documented: KiCad #15584 | CHECKED |
| Differential pairs | Rules carry; pair definitions do not. documented: KiCad dev-docs | ENGINEERING DECISION |
| Buses | Fixed in 10.0.5; ≤10.0.4 could drop shared-member bus connectivity. documented: KiCad #20707 | NOT YET IN SCOPEwhen it ships: CHECKED |
| Multi-channel designators | Channel suffixes stripped (C33A / C33B → C33), producing duplicate references. documented: KiCad #24861 | ENGINEERING DECISION |
| Project variables / revision | Not reliably carried; ${…} can render literally (open in 10.0.0). documented: KiCad #24455 | CHECKED |
| Copper fills / zones | Soldermask relief lost; zone clearances wrong — a refill can disconnect copper. documented: KiCad #13750 / #18408 | CHECKED + AUTO-REPAIR |
| Copper / soldermask text | Can arrive mispositioned (10.0.3). documented: KiCad #24504 | CHECKED + AUTO-REPAIR |
| Keepouts | Polygon cutouts can become over-broad keepouts, causing false DRC errors. documented: KiCad #15587 | CHECKED |
| Layers / stackup | Stackup carries; no-equivalent or oddly-named layers can be remapped or drop the outline. documented: KiCad #17351 / #18756 | CHECKED |
| Schematic hierarchy (multi-sheet) | Flat since 9.0.3; complex hierarchical projects can fail. documented: KiCad #20936 | NOT YET IN SCOPEwhen it ships: CHECKED + RECONSTRUCT |
| Custom / complex pad stacks | Not supported. documented: KiCad #8182 | FLAGGED |
| 3D models | Refs carry; placement data read but not applied. documented: KiCad dev-docs | CHECKED (accounting) |
| SPICE / simulation | Parsed but not carried into simulation. documented: KiCad dev-docs | NOT YET IN SCOPEwhen it ships: FLAGGED |
| Legacy ASCII .PcbDoc | Silently ignored — no error. documented: KiCad #18467 | CONVERTED + CHECKED |
States reflect the standard migration path as of KiCad 10.0.6 (2026-08-29). It changes most releases; this page is updated per release. Version-specific states are noted. Pre-Version-6 (Protel) boards have no row here because we have no public source for what a standard migration does with one; what we can state is our own behaviour — Crosspad names that format unsupported with its reason, and the remedy is to re-save the board from a current Altium Designer.
A standard migration produces a file. Crosspad accounts for the design.
The failure modes above happen silently — the board opens, and you find out later, or not at all. Crosspad reads your Altium board directly, migrates it, compares the result back, repairs what it can prove safe, and hands you an evidence report of what's verified, repaired, or left for a decision.
How we verify every migrationWhat we accept today
At launch the migration service processes one Altium .PcbDoc board file, version 6 or later — either form Altium writes: the binary file, or the ASCII text form, which is converted and checked against an independent count of your board before anything is migrated. A zipped project is accepted too, but only as a container for that one board: the .PcbDoc inside it is migrated, and the schematics, the project file and the libraries that came in the archive are not — they are listed in the report, not converted. .SchDoc schematics, .PrjPcb project files and libraries sent on their own are named as unsupported by the free analysis rather than silently skipped — the rows above marked NOT YET IN SCOPE describe how those findings will be reported when those migrations ship. Pre-Version-6 (Protel) boards are named as unsupported; where an ASCII conversion cannot be reconciled the board is named unsupported too, rather than migrated on a conversion we cannot vouch for. Where target equivalence can't be proven — high-speed rule intent, for example — Crosspad marks an engineering decision rather than quietly reducing it.