A Protel board rarely fails on the day someone opens it in Altium Designer. The failure usually shows up later, when a footprint no longer matches the approved library, an old polygon reconnects differently, or the released Gerbers stop matching the build that has been shipping for years. Legacy PCB migration is less about opening a file and more about preserving design intent that was never written down clearly.
If the board still matters to production, service, or certification, the migration has to protect more than geometry. It has to protect library links, design rules, stackup assumptions, assembly outputs, and the small process notes that keep a repeat order from turning into a costly debug cycle.
Why a legacy Protel design can look correct and still be wrong
Altium inherited the Protel line, so teams often expect a clean handoff. In practice, the visual conversion is only one layer of the problem. A board outline may open, tracks may render, and the BOM may still export, yet the migrated project can already be drifting away from the released product.
The hidden risks usually sit in places that production notices before engineering does: obsolete footprint names, inconsistent hole definitions, broken net classes, outdated layer usage, and output containers that no longer match the current fabrication or assembly package. If the product is a field replacement board, even silkscreen reference movement or drill table changes can slow service and inspection.
Audit the release package before you import anything
Before touching the design database, collect the last known-good manufacturing set. That means Gerbers or ODB++, drill files, IPC netlist if available, pick-and-place, assembly drawing, stackup notes, and the approved BOM revision. A converted PCB without this reference package is difficult to verify because you have nothing trustworthy to compare against.
The archive should also include the approved schematic release, because migration defects often start as library or net-name drift before they are visible in layout. A disciplined PCB schematic design review gives the imported project an electrical baseline as well as a geometric one.
This is also the moment to capture what the factory had to compensate for manually. If the assembler edited centroid rotation, adjusted solder paste apertures, or maintained a private stencil note outside the CAD file, those details need to be pulled back into the migration plan. Otherwise the new Altium project may be technically cleaner but operationally less accurate.
Check the libraries as a controlled data set
Treat symbol and footprint migration as a data-management task, not a cosmetic cleanup. Legacy Protel libraries often contain duplicated footprints, silent pin-swaps, or naming that made sense to one designer but not to purchasing or assembly. Bring each critical component package back to the manufacturer drawing, especially connectors, BGAs, QFNs, fine-pitch leaded packages, and power parts that rely on exposed-pad solder volume.
If the product is still being bought in volume, align the migrated library with the current sourcing plan at the same time. That is where a disciplined PCB BOM structure matters. A footprint migration that ignores approved alternates, lifecycle flags, and package-level sourcing constraints only pushes the inconsistency downstream.
Build the Altium project around verification checkpoints
The safest migration path is staged. Import the schematic and PCB, resolve broken library links, recompile, then compare rule behavior and outputs in small checkpoints. Do not wait until the end to regenerate everything and hope the deltas are acceptable.
On the PCB side, inspect layer mapping, via types, keepouts, room definitions, split planes, and copper pours first. Then move to net classes, width rules, clearance rules, differential-pair constraints, and length targets. Old rules sometimes migrate as broad defaults even when the original board relied on narrower local exceptions. High-current power sections, impedance-controlled nets, and test-point access are where this drift becomes expensive.
Manufacturing outputs deserve a line-by-line comparison
Once the imported design compiles cleanly, generate the same release outputs the old board used. Compare drill counts, aperture usage, silkscreen content, solder mask openings, paste layers, and centroid orientation. If the migrated board will feed a new SMT line or a different CAM workflow, confirm that the output package is still practical for the assembler rather than merely CAD-valid.
This step is easy to underestimate. A board can pass design-rule checking and still fail in fabrication because the new output container changed layer polarity, removed mechanical detail, or renamed files in a way that breaks the shop’s automated intake. The safest teams compare the new package against the last proven one the way a factory would compare incoming data, not the way a designer eyeballs a layout.
Where assembly files and centroid conventions have changed, review them with the same rigor used in a PCB assembly process flow. That keeps a successful CAD import from becoming a manufacturing handoff problem.
Know when migration should become redesign
Some Protel projects should not be preserved exactly. If the board already needs new components, revised impedance targets, updated creepage spacing, or a different fabrication stack, conversion may only be the first step before a controlled redesign. In those cases, engineering time is better spent separating reusable intent from legacy clutter.
A good rule is this: if your verification effort is already exposing undocumented workarounds, undocumented DFM exceptions, and outdated libraries, the board is telling you it was never truly under configuration control. Conversion alone will not fix that. A partial redraw with cleaner libraries and modern outputs may be lower risk for the next production cycle.
A practical migration checklist for production boards
- Freeze the last approved manufacturing package before importing the design.
- Resolve symbol and footprint libraries against current approved parts, not only legacy names.
- Rebuild or verify net classes, differential-pair rules, and special clearance exceptions.
- Inspect polygons, plane connections, thermal relief settings, and keepout behavior after import.
- Regenerate fabrication, assembly, and test outputs and compare them with the historical release package.
- Run a pilot review with fabrication or assembly stakeholders before using the migrated project for a respin.
Conclusion
Protel to Altium Designer migration is successful only when the new project can reproduce the board your factory knows how to build. That means library control, rule translation, output comparison, and manufacturing reality all need to agree. If your team treats the job as a structured engineering release rather than a software conversion, the migrated design becomes useful. If not, the first board spin becomes the audit you should have done before pressing import.
Can Altium Designer open old Protel files directly?
Often yes, but opening the file is only the start. You still need to verify libraries, design rules, polygons, layer mappings, and every manufacturing output before trusting the migrated project.
What usually breaks first in a Protel to Altium migration?
Footprint links, custom rules, copper pours, net classes, and output jobs are the common failure points because legacy data structures rarely map one-to-one.
Should you migrate the libraries before releasing a board respin?
Yes. Clean symbol and footprint libraries first or in parallel with the design import. Otherwise each schematic or layout correction becomes a one-off patch that is hard to control later.
When is redraw safer than conversion?
Redraw is often safer when the original files are incomplete, the legacy rules are undocumented, or the product already needs stackup, footprint, or BOM modernization.
