Importing systems from another locksmith tool

Supported import formats

• InstaCode .ick — exported by ProMaster, InstaCode Live, anything that drives a Silca code-cutter.
• Genericode .gcd — Framon Genericode v18 and later, HPC CodeMax format.
• Silca .skd — Silca Triax, Silca Idea, and other Silca legacy bench machines.
• CSV key schedule — for systems exported as spreadsheet from any tool, or hand-typed.

Each format carries different metadata. .ick and .gcd preserve bittings, key labels, and the keyway/profile reference. .skd sometimes loses the master/change-key role distinction (the format is older); Keyzee infers it from the bitting structure where it can. CSV is most flexible but you'll do more cleanup post-import.

How to import

1. From any customer page, click + New system.
2. Pick Import existing instead of Design new.
3. Choose the file. Keyzee detects the format from the extension (and falls back to content sniffing for files with weird extensions).
4. Review the import preview: keyway, key count, what role Keyzee assigned each key (TMK, GMK, MK, SK, CK).
5. Click Import.

What happens behind the scenes

Keyzee parses the file, extracts the bittings + key labels, runs a profile match against the 35 supported lock profiles (using the keyway / card reference if present), then assembles a system with one door per cylinder.

After import, the system is in a "loaded" state — bittings are present but no engine validation has run. That means: no MACS check, no thin-pin check, no phantom scan. We do this on purpose: legacy systems sometimes have intentional violations the previous tool ignored, and we don't want to scare the user with 18 warnings on a system that's worked fine for 5 years.

To validate post-import: open the system, click Validate. The engine runs all 8 safety checks without re-allocating bittings. Warnings get classified the same way as a fresh build (critical / high / medium).

What to expect on the first validation

Real-world legacy systems imported into Keyzee almost always surface at least one warning. The most common are:

• Thin master pins. Older tools defaulted to a minimum of 1 instead of 2. The cylinders work — they were tolerated by the brand at the time — but Keyzee flags them because modern bench tolerances are tighter.
• Medium-severity phantoms on big systems with many master groups. These were undetectable with older tools; they've existed in your customer's building all along.
• MACS violations at one or two positions on systems built before the manufacturer published current MACS values. Usually fine on hardware that's already installed, but worth flagging for any expansion.

None of these block import. They're advisory. The "what do I do with this?" answer depends on the customer relationship — see phantom keys explained for the disclosure conversation.

Importing a system you'll then expand

The most common reason to import: you're adding new cylinders to an existing master-keyed building, and you need the engine to produce bittings that fit the existing TMK and master keys.

After import, click Expand. Tell the engine how many new cylinders you need and which master groups they go in. The engine produces fresh CK bittings that fit cleanly under the existing masters, never duplicating an existing key, and re-runs the phantom scan against the whole expanded system.

The expansion respects everything the original tool encoded: existing TMK + masters stay byte-for-byte identical. Only new change keys get freshly generated.

What if my format isn't supported?

Email sales@keyzee.app with a sample file. We've added formats based on user requests before — the import parser is modular. Common ones we'll probably add next: ProMaster Master-Keying 8 native format, MK Express CSV variant, MasterKing legacy .mks.