Migrating multi-sheet Altium schematics to KiCad.
A real schematic isn't one page — it's a hierarchy of sheets, hierarchical ports, repeated channels and cross-sheet nets. A standard Altium → KiCad migration can open the schematic and quietly reshape that structure: a flattened hierarchy, collided designators, a harness that came across half-formed. Schematic migration has not shipped: the service runs on a .PcbDoc today. When it does, Crosspad will read your schematic structure directly, compare it back sheet by sheet, reconstruct the hierarchy where it can prove the mapping, and flag the rest — so no sheet, port or connection goes missing in silence.
At launch the migration service processes an Altium .PcbDoc; .SchDoc schematics and .PrjPcb projects are named as unsupported by the free analysis. This page documents how schematic-structure findings are reported. The in-browser SchDoc viewer is live: it opens a .SchDoc and draws it in your browser, and nothing you drop into it is uploaded.
A schematic that opens isn't a schematic that still connects.
The pages render. The symbols are there. The wires look wired. That's exactly why schematic structure is dangerous to migrate: the parts most likely to break are the ones you can't see on a single page — how the sheets nest, which hierarchical ports carry which nets between them, how a channel keeps R1 on channel one distinct from R1 on channel two. KiCad's project importer has handled flat multi-sheet in one pass since 9.0.3 and improved every release since — but its own docs and issue tracker record where a complex hierarchy still fails to import, where channel suffixes get stripped, and where a harness object comes across only partially. A schematic that opens can still be one section short, or two parts collided into one. Crosspad exists to make that visible before it reaches layout.
The pages rendered. The structure didn't survive.
Why are multi-sheet Altium schematics so hard to migrate?
A single-sheet schematic is almost a picture — symbols, wires, labels. A multi-sheet project is a data structure. Each sheet symbol points at a child sheet; each hierarchical port and sheet entry is a named contract for a net crossing between them; repeated channels instantiate the same sheet many times, and a channel-scoped suffix is the only thing keeping their designators apart. Nets travel between sheets through ports, global labels and buses — not through visible wires. Migrating that means preserving a graph, not copying pages: get one port name, one channel suffix, or one sheet-instance link wrong and the schematic still opens, still looks complete, and quietly means something different. Reading that structure directly from your Altium source — every sheet, port, sheet entry, channel and cross-sheet net — is what will let Crosspad check the migration as a connected hierarchy rather than as a stack of pages that happen to render.
Schematic migration will model the schematic as the graph Altium actually stores — sheets, hierarchical ports and entries, channel instances and cross-sheet nets — so a reshaped hierarchy or a collided designator becomes a difference Crosspad can measure, not a surprise you find at layout.
- The hierarchy
Sheet symbols nest child sheets into a tree. A complex tree can fail to import where a simple one succeeds — flattened, re-shaped, or one branch missing.
documented: KiCad #20936 - The cross-sheet connections
Hierarchical ports, sheet entries, global labels and buses carry nets between sheets with no visible wire. A renamed or dropped port silently changes what connects to what.
documented: KiCad import dev-docs - The repeated channels
Multi-channel designs instantiate one sheet many times; the channel suffix is what keeps C33A and C33B distinct. Strip it and two parts collapse into one reference.
documented: KiCad #24861 / #23709
What a standard Altium → KiCad migration quietly does to your schematic structure.
These aren't hypotheticals — each is grounded in KiCad's own import documentation or its public issue tracker, as of KiCad 10.0.6 (2026-08-29), cited as proof the failure is real and reproducible. Several are version-specific and get fixed over releases, which is exactly why the check has to be per-project and per-version. Crosspad checks for every one against your source.
- Complex hierarchies fail to import
A complex hierarchical project can fail to import where a simple, toy project succeeds — leaving a flattened or re-shaped tree, or one branch missing.
documented: KiCad #20936 - Harness objects come across partially — or crash the import
Signal-harness objects can migrate only partially, and in some projects can crash the import outright — so a harness-heavy schematic arrives incomplete or not at all.
documented: KiCad #16852 / #8741 - Channel suffixes are stripped into duplicate references
In multi-channel designs the channel suffix that keeps C33A and C33B apart can be dropped (C33A / C33B → C33), collapsing distinct parts into duplicate designators that break the BOM and the netlist.
documented: KiCad #24861 / #23709 - Hierarchical designators reset or collide
Importing a hierarchy can reset reference designators, and duplicate hierarchical sheet names can arrive that annotation then can't tell apart.
documented: KiCad #11412 / #19281 - An imported schematic can fail to save
A schematic that imported and opened has been reported failing to save at all — the structure is there on screen but won't persist.
documented: KiCad #11236 - Symbol rotation can arrive wrong
A symbol's rotation can be reported as 0° after import, mispositioning it on the sheet even when the connection is intact.
documented: KiCad #19630 - Cross-sheet net & bus connectivity is version-sensitive
Nets that cross sheets through shared-name buses could arrive with members unconnected — valid at the source, disconnected after — on affected versions.
documented: KiCad #20707 (≤10.0.4; fixed 10.0.5) - Annotation elements aren't imported
KiCad's import docs list elements it does not import — IEEE standard symbols, parameter sets, and SPICE model data (parsed but not simulated) — and older files whose code-page/encoding isn't preserved can arrive with mangled text.
documented: KiCad import dev-docs
Multi-sheet import behavior is version-specific. The .PrjPcb project importer arrived in 9.0.3; complex hierarchies can still fail as of 10.0.6. This page is dated and refreshed per KiCad point release.
How does a clean import quietly break the BOM on a multi-channel board?
- 01
Your design has four identical channels — the same sheet, instantiated four times. In Altium, the channel suffix keeps every part distinct: C33A, C33B, C33C, C33D.
- 02
A standard migration imports the project. Every sheet renders; the schematic opens and looks complete.
- 03
But the channel suffix was stripped on the way over — a documented import fault (KiCad #24861). All four collapse to a single C33.
- 04
Now four different resistors share one reference. The netlist can't tell them apart; the BOM counts one where there are four; annotation and layout inherit the collision.
- 05
Nothing warned you, because the import “succeeded” and the pages all opened.
This is the exact class of failure Crosspad exists to catch: it compares your designators back to your Altium source, detects the collision, and — where the original channel mapping is recoverable — restores unique references and re-validates, instead of trusting that a schematic that opened is a schematic that still means the same thing.
documented: KiCad #24861Every sheet, port and designator — accounted for.
Schematic migration has not shipped. The migration service runs on a .PcbDoc; the steps below are the process it will follow when .SchDoc and .PrjPcb enter the Supported Scope.
- 01ANALYZE SOURCE
Read the schematic structure directly from your Altium project — sheets, hierarchical ports and entries, channel instances, cross-sheet nets and buses, designators.
- 02COMPARE
Match the migrated result back to the source as a graph, by meaning: is every sheet present, every hierarchical port still carrying the same net, every designator still unique?
- 03RECONSTRUCT — WHERE PROVABLE
Where the hierarchy was flattened or a designator collided, rebuild the sheet tree and restore unique references from the original mapping, then re-parse and re-validate. A reconstruction that can't be proven safe is rolled back and flagged, never silently kept.
- 04FLAG
Where equivalence can't be proven — a partial harness object, a branch that failed to import, a port whose meaning can't be matched — surface it as a review or an engineering decision instead of accepting the pages as correct.
- 05EXPLAIN
Report every sheet, port and designator's status: verified, reconstructed, repaired, or left for a decision.
If Crosspad can't prove a sheet, port or net still means the same thing, it doesn't mark it safe.
Crosspad's structure checks are stress-tested by mutation — deliberately reshaping hierarchies and colliding designators in known-good projects and confirming each change is caught — so a flattened tree or a duplicated reference isn't allowed to pass as fine.
Know exactly what happened to the structure.
At launch the migration service processes an Altium .PcbDoc; .SchDoc schematics and .PrjPcb projects are named as unsupported by the free analysis. This page documents how schematic-structure findings are reported. The in-browser SchDoc viewer is live: it opens a .SchDoc and draws it in your browser, and nothing you drop into it is uploaded.
| OBJECT | SOURCE | TARGET | REPORTED AS |
|---|---|---|---|
| Schematic sheets | multi-level sheet tree | hierarchy reconstructed, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Hierarchical ports & entries | cross-sheet nets | matched to source | VerifiedVERIFIED |
| Channel designators | R*_CH2 collided → R* | restored unique, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Global net labels | nets across sheets | ambiguous labels need a judgment | Needs your callENGINEERING_DECISION_REQUIRED |
| Signal-harness object | present in source | partial on import — confirm the mapping | Needs your answerACTION_REQUIRED |
| SPICE model data | present in source | not carried to simulation — named | Out of scopeUNSUPPORTED |
| Legacy / pre-V6 SchDoc | pre-V6 / ASCII | cannot import — named, not skipped | Out of scopeUNSUPPORTED |
Schematic-structure behavior reflects a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). The .PrjPcb project importer arrived in 9.0.3; behavior changes most releases, version-specific families are noted (e.g. bus connectivity #20707 fixed in 10.0.5), and this page is updated per release.
What we reconstruct where provable — and what even we can only report.
The migration service does not read schematic structure at launch: it takes an Altium .PcbDoc, and .SchDoc and .PrjPcb are named as unsupported by the free analysis rather than billed for. What follows is the scope schematic migration will ship with. It will read structure from modern binary Altium projects (.PrjPcb / .SchDoc), and reconstruction will be scoped, not universal: where the original hierarchy or channel mapping is recoverable, Crosspad will rebuild it and re-validate — and where it can't be proven, it will flag a review or an engineering decision rather than guessing. Legacy ASCII and pre-V6 schematics are named as unsupported, not silently skipped. Some things a standard migration simply cannot carry — SPICE model data is parsed but not simulated, IEEE symbols and parameter sets are not imported (KiCad's own import docs) — and Crosspad reports those as explicit, named gaps, not as a completed migration. Migrating a single .SchDoc rather than a whole project? See the file-level page.
Frequently asked questions.
Does a multi-sheet Altium schematic import into KiCad?
Since KiCad 9.0.3 the project importer brings a multi-sheet schematic across in one pass, and it improves most releases. What a standard migration can lose is the structure around the pages: a complex hierarchy can fail to import where a simple one succeeds (KiCad #20936), channel suffixes can be stripped into duplicate designators (KiCad #24861), and harness objects can come across only partially (KiCad #8741). Schematic migration has not shipped — the service runs on a .PcbDoc today. When it does, Crosspad will read your schematic structure directly and check it back sheet by sheet.
Why do I have duplicate reference designators after migrating a multi-channel design?
A common cause is that the channel suffix that keeps C33A and C33B apart was stripped on import (KiCad #24861), collapsing distinct parts to a single C33. That breaks the netlist and the BOM. When schematic migration ships, Crosspad will detect the collision and, where the original channel mapping is recoverable, restore unique references and re-validate.
Does KiCad preserve schematic hierarchy from Altium?
Flat multi-sheet, generally yes since 9.0.3; deep or complex hierarchies are where it can break — a complex hierarchical project can fail to import where a toy one succeeds (KiCad #20936), and importing a hierarchy can reset or duplicate designators (KiCad #11412, #19281). When schematic migration ships, Crosspad will reconstruct the sheet tree where it can prove the mapping and flag the branches it can't.
Are these KiCad bugs?
Some are tracked issues with GitLab IDs; some are documented limits in KiCad's own import documentation (IEEE symbols, parameter sets and SPICE model data are not imported). Several are version-specific and get fixed over releases — which is why the check has to be per-project and per-version.
Can Crosspad guarantee it rebuilds my hierarchy perfectly?
No — and no honest tool can. Schematic migration has not shipped yet; when it does, Crosspad will reconstruct the structure where it can prove the mapping, repair collided designators it can recover, and clearly flag everything it can't. What it will never do is guess: no sheet, port or designator goes missing in silence.
I only need to migrate one .SchDoc, not a project.
Then the single-file page is the right scope. Neither is live yet — .SchDoc and .PrjPcb are both outside the launch scope — and this page is the multi-sheet, whole-project story: hierarchy, channels and cross-sheet connectivity.
Know what a multi-sheet migration would have to account for.
Migration at launch runs on a .PcbDoc — run the free analysis on a board today. When schematic migration ships, this is the evidence it will produce: which sheets and ports verified, which designators were repaired, what was reconstructed, and what it flags for you.
The free analysis runs on a .PcbDoc; files sent to it are processed as described in our Security policy. The in-browser SchDoc viewer reads a .SchDoc without uploading it.