Convert a SchDoc to KiCad — and verify the connectivity survived.
KiCad opens your Altium .SchDoc — and it looks wired. But net assignment, buses, harnesses and channel designators are exactly where a standard migration can quietly differ, with no error. .SchDoc conversion has not shipped — the service runs on a .PcbDoc today. When it does, Crosspad will convert the sheet and then check every net against your source, repair what it can prove safe, and flag the rest — so nothing disappears in silence.
At launch the migration service processes an Altium .PcbDoc; .SchDoc files are named as unsupported by the free analysis. This page documents how schematic findings are reported. The in-browser SchDoc viewer is live and opens a sheet locally; the migration-readiness inspector on it lands at launch.
A schematic that opens is not a schematic that's wired the same.
Converting a .SchDoc is the easy part — KiCad imports Altium schematics natively, and the symbols come across. What you don't get is proof that the connectivity means the same thing it did in Altium. A merged net, a bus member that arrived detached, a channel suffix that got stripped — each leaves a schematic that opens and passes a glance, while the netlist underneath is subtly different. Every failure below is documented in KiCad's own docs or public tracker. Crosspad exists to make each one visible before it reaches your board.
The symbols came across. The question is whether the wiring did.
Five ways your .SchDoc's connectivity can quietly shift — and what Crosspad does about each.
These are single-file failure modes — things that can change inside one schematic. Each is grounded in KiCad's public issue tracker or its own import documentation, cited as proof the failure is real. (For a multi-sheet project — hierarchy, cross-sheet ports — see the multi-sheet schematics page.)
- Net assignment & labelsDETECTED
The ratsnest looks clean, so the wiring feels safe. But connectivity is exactly what can shift: KiCad's own import docs record net-name and case edge cases in how Altium nets come across, so two labels that meant one net at the source — or one that meant two — can end up assigned differently after conversion. Nothing errors; the netlist just means something slightly different.
documented: KiCad import dev-docs (net-name / case)CROSSPADWhen .SchDoc conversion ships, Crosspad will rebuild the net list from your .SchDoc and compare it label by label and pin by pin against the source, so a net that was split, merged or renamed is caught — not trusted because the sheet opened.
- Buses within the sheetDETECTED
A single schematic can carry buses, and buses whose members share a name are where connectivity has silently broken before: on KiCad ≤10.0.4 those members could arrive unconnected — valid in Altium, disconnected after — documented in #20707 (fixed in 10.0.5). Proof the failure is real, and a reminder that behavior shifts release to release.
documented: KiCad #20707 (≤10.0.4)CROSSPADCrosspad expands every bus to its members and confirms each one keeps the connectivity it had at the source, flagging any member that arrived detached.
- Harness connectivityRECONSTRUCT
Harness objects — Altium's signal-harness connectors — are among the schematic constructs a standard migration handles least completely. They can come across only partially, and have been reported crashing the import outright (KiCad #8741, #16852). A harness that half-converted is a set of connections silently missing from the netlist.
documented: KiCad #8741 / #16852CROSSPADWhen .SchDoc conversion ships, Crosspad will reconstruct harness connectivity from your source and report every signal it could rebuild and every one that needs a human — a partially-converted harness becomes a finding, not a silent gap.
- Channel (repeated-sheet) designatorsAUTO-REPAIR
When one .SchDoc is reused as a channel in a repeated design, the channel suffix is what keeps C33A and C33B apart. A standard migration can strip that suffix (C33A / C33B → C33), collapsing distinct parts into duplicate references (KiCad #24861, #23709) — quietly breaking the BOM and the netlist that depend on unique designators.
documented: KiCad #24861 / #23709CROSSPADCrosspad detects colliding and stripped designators and, where the original channel mapping is recoverable, repairs them back to unique references, then re-validates. Anything it can't prove is flagged, never silently renumbered.
- Title-block variables & metadataDETECTED
The fields on the sheet that identify the design are easy to lose. A variable reference like ${PCB_REVISION} in a title block or label can render as literal text instead of its value (KiCad #24455), and KiCad's import docs list parameter sets among elements it does not import. The symbols are right; the revision on the sheet is wrong.
documented: KiCad #24455 + import dev-docsCROSSPADWhen .SchDoc conversion ships, Crosspad will account for sheet variables and title-block metadata against the source and flag any field that arrived unresolved.
Failure modes reflect a standard Altium → KiCad conversion of a single .SchDoc as of KiCad 10.0.6 (2026-08-29). Behavior changes most releases — the shared-member bus issue (#20707), for example, was fixed in 10.0.5 and is scoped ≤10.0.4. Version-specific modes are noted, and this page is updated per release.
Every net, bus and designator — accounted for.
Crosspad doesn't just hand you a converted sheet — the connectivity has to be proven. .SchDoc conversion is not live yet; when it ships, Crosspad will read your .SchDoc directly, convert it to KiCad, compare the result back semantically, and return a verdict for every net: verified, repaired, or flagged for a decision.
- 01ANALYZE
Read the .SchDoc directly — symbols, pins, nets, labels, buses, harnesses.
- 02COMPARE
Match the KiCad schematic back to the source, by meaning: every net, label and connection.
- 03REPAIR — OR ROLL BACK
Correct known breaks — stripped channel suffixes, detached bus members — then re-parse and re-validate. A repair that can't be proven safe is rolled back and flagged, never silently kept.
- 04EXPLAIN
Produce an evidence report: what's verified, what was repaired, and what still needs an engineering decision.
If Crosspad can't verify a critical part of the connectivity, it doesn't mark it safe.
Know exactly what your netlist did — not just that the sheet opened.
At launch the migration service processes an Altium .PcbDoc; .SchDoc files are named as unsupported by the free analysis. This page documents how schematic findings are reported. The in-browser SchDoc viewer is live and opens a sheet locally; the migration-readiness inspector on it lands at launch.
| FINDING | DETAIL | OUTCOME | REPORTED AS |
|---|---|---|---|
| Nets | every net read from source | all matched | VerifiedVERIFIED |
| Net labels | labels read from source | assigned as source | VerifiedVERIFIED |
| Bus SPI_DATA | shared-member connectivity | rebuilt from source, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Harness USB_IF | partial import | signals need a judgment — options described | Needs your callENGINEERING_DECISION_REQUIRED |
| Channel designators | R*_CH2 collided → R* | restored unique, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Title-block ${REVISION} | project variable | unresolved literal — supply the value | Needs your answerACTION_REQUIRED |
One .SchDoc, verified. A whole project is the next page.
This page is about converting and verifying a single Altium .SchDoc file and its connectivity. If you're moving a multi-sheet project — hierarchical sheets, cross-sheet ports, whole-project structure, where a standard migration hits a different class of problem (complex hierarchies can fail where simple ones succeed, KiCad #20936) — that's the multi-sheet schematics page. And converting is not the same as guaranteeing: where connectivity can't be proven equivalent, Crosspad marks a decision and hands it to you rather than quietly reducing it.
Frequently asked questions.
How do I convert a SchDoc to KiCad?
KiCad imports Altium .SchDoc schematics natively (since version 7), so the file itself comes across and the symbols appear. The harder question is whether the connectivity came across unchanged — net assignment, buses, harnesses and channel designators are where a standard migration can quietly differ. .SchDoc conversion is not live yet; when it ships, Crosspad will convert the sheet and then verify every net against your source.
Does a SchDoc lose connectivity when it's converted to KiCad?
It can, silently. Documented cases include shared-member buses arriving unconnected (KiCad #20707, ≤10.0.4, fixed in 10.0.5), harness objects importing only partially (#8741), and channel designators being stripped so distinct parts collide (#24861). The schematic opens either way — which is exactly why an independent check of the netlist matters.
Can I look at my SchDoc before I convert it?
Not in a Crosspad viewer yet — the in-browser SchDoc viewer ships at launch with the schematic parser. Our guide covers the honest ways to open a .SchDoc today without an Altium licence.
What's the difference between this and migrating a multi-sheet schematic?
This page is about a single .SchDoc file and its connectivity. For a multi-sheet project — hierarchy, cross-sheet ports, whole-project structure — see migrating multi-sheet Altium schematics.
Can Crosspad migrate my .SchDoc today?
Not at launch. The migration service processes an Altium .PcbDoc — on its own, or inside a .zip that holds exactly one board; .SchDoc schematics, .PrjPcb project files and libraries are outside the Supported Scope, and the free analysis names them as unsupported rather than attempting them. Zipping the project changes nothing about that: the archive is opened for the board, and the sheets that travelled with it are not migrated. The in-browser SchDoc viewer is live for READING a sheet — it renders it locally and uploads nothing — but reading is not migrating, and its readiness inspector lands at launch. This page documents the connectivity failure modes and the state each finding is reported in.
Does Crosspad guarantee my schematic converts perfectly?
No — and no honest tool can. What Crosspad guarantees is accountability: every net, bus and designator is checked against your source, repaired where it can be proven safe, or clearly flagged for a decision. Nothing disappears in silence.
Know what a SchDoc 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: what's verified, what it repairs, 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 opens a sheet locally — nothing is uploaded there.