Migrating Existing Libraries to Your Connected Workspace

Altium Designer, in conjunction with your managed content server, provides a streamlined and highly automated process to quickly migrate your existing libraries to that server. The interface to this process – the Library Migrator – presents a one-click solution that automatically analyses the selected libraries and migrates them to the managed content server to which you are actively signed in.

Catering for all types of libraries, relating to older component management methodologies (SCHLIB, PCBLIB, INTLIB, DBLIB, SVNDBLIB), the Library Migrator is a dedicated solution for quickly building your company's set of managed components so you can benefit from their many advantages – high-integrity, lifecycle management, centralized storage and management, where-used functionality, manufacturer part choices and ease of design reuse.

The Library Migrator offers a minimalist Simple interface mode where the selected file-based component libraries are migrated to managed server components through a single step, while the migrator automatically takes care of type classification, the target source folder, parameter inclusion and value type, and the transfer of all relevant data. The interface is also available in an Advanced mode that provides a full preview of the proposed library migration, and access to its related data and settings. And while the migration is a single-click process by default, the migrator also offers advanced configuration options through the Properties panel for enhanced control over exactly how that migration is performed.

What gets Migrated?

All information that is present in an original source library is migrated to the server-based managed components, including all referenced domain models (schematic symbols, PCB footprints, Simulation Models), parametric information, assigned part choices, datasheet files, etc. Component Templates are also created where necessary, and may then be refined and used for subsequent library migrations.

If your original components have multiple PCB footprints defined, the Library Migrator will bring those models across and keep the current default footprint. And if you only work with PCB libraries – your only concern is PCB layout – then the Library Migrator supports migration of just those libraries, or it can be switched to a models-only migration mode where specified models types are migrated from Integrated or Database libraries. Libraries that include multiple component types (monolithic libraries) are automatically detected and processed as well.

While library migration process needs to deal with file-based library sources that may use a range of formatting standards, its automated analysis processes detect the types of components in the source library (resistor, capacitor, etc) and also the parameters names and their value types (Volts, Ohms, etc). The system conducts and handles a number of validations, for example to ensure no duplicate IDs for the resulting managed components, or to ensure no duplicate models or component templates are created, and that such entities are reused across (linked to) components where needed. And if issues do arise, the system flags them, with suggestions on how to resolve those issues, aiming to get the migration back on track as quickly, and as smoothly as possible.

Library types that can be migrated are:

• Schematic Library (*.SchLib).
• PCB Footprint Library (*.PcbLib).
• Integrated Library (*.IntLib)
• Database Library (*.DBLib).
• SVN Database Library (*.SVNDBLib).

Accessing the Library Migrator

The Library Migrator is available when you are signed in to an Altium server. To access the migrator in its Simple (easy) mode:

• Select a file-based library in the Components panel Categories column, and then choose the Migrate Library option from the menu.

  The file-based libraries that are currently available to the software can be viewed and managed in the Available File-based Libraries dialog, which is accessed from the File-based Libraries Preferences option on the button menu in the Components panel.

  You can also view and manage the currently installed file-based libraries in the Data Management – File-based Libraries page of the Preferences dialog.

  You can view and manage the currently installed file-based libraries in the Data Management – File-based Libraries page of the Preferences dialog.

  If you wish to access file-based unmanaged libraries in the Components panel, they can be enabled in Advanced Settings dialog available from the button on the System – General page of the Preferences dialog. Check the Legacy.UnManagedLibraries option to enable access to file-based (unmanaged) library components in the panel, and to also enable access to the Available File-based Libraries dialog from the File-based Libraries Preferences option on the panel's button menu. You will need to restart Altium NEXUS for the setting change to take effect.

• Right click on a library file in the Projects panel and select Migrate Library from the context menu.
• Select Tools » Migrate Library in the Schematic/PCB Library editor.
• Drag and drop a library file from a Windows folder onto the Explorer panel.

The Simple mode provides options to immediately migrate the selected library () or open the Library Migrator in its full GUI mode ().

The Library Migrator when accessed in its Simple one-click migration mode.

To directly access the Library Migrator in its Advanced interface mode, along with its associated Properties panel, select File » Library Migrator from the main menu.

The Library Migrator when accessed in its full Advanced interface mode, which also supports a one-click migration process.

Simple Mode

The Library Migrator's Simple mode preselects all aspects of the migration process based on its analysis of the source library and the connected server. The dialog then presents a summary of the migration structure, including a total number count for each item type. The library migration is performed as a single step from the command.

This Simple interface mode will suit most common source library formats, which tend to contain common component types (resistors, capacitors, integrated circuits, etc) and standardized parameter values. During the initial analysis process the system deduces the type of components within the library based on Designator or parameter key words (LD?, LED, etc) and then locates a corresponding Component Template in the target server (LED). This Template is applied to the migration of those components, which then specifies the migration settings such as target folder (Components/LED), parameter mapping, parameter value units, and so on – suitable templates are available in the server if the Install sample data option was selected during installation.

The results of the library migration, as newly created managed components, can be seen in both the Explorer and Components panels. Migrated components include all models, parameters as interpreted by the applied Component Template(s), Part Choices derived from Supplier Link source data, and any reference links or files.

Notable points regarding the library migration process are:

• Monolithic libraries (those that contain multiple types of components) are automatically split into sub groups, where each group represents a type of component found in that library. The groups are processed as individual libraries.
  
• A source library with an unrecognizable (undetected) component type will be migrated without interpretation, as unassigned component types in a Components/Uncategorized server folder. Before the migration is run, this can be resolved by applying Designator Mapping or Parameter Grouping in the Advanced (full UI) mode. Alternatively, you can proceed with the migration and then modify the component's settings and folder at a later time, through the Explorer panel.
• The library migration process includes an automatic component Validation stage. Components that trigger a validation error will be skipped.
• Any errors the process has encountered can be viewed in the Migration Report, available from the button when the migration has completed.

Advanced Mode

The Library Migrator's full GUI is presented when in Advanced mode, which offers detailed control over the management of libraries, component types and component parameters. When combined with the Properties panel, the migration of component libraries to the server can be configured to your specific needs. Note that the migrator's settings can be saved and restored by exporting/importing configuration files. 

Advanced mode is enabled when the Library Migrator is opened from the File » Library Migrator command, or when the button is selected while in Simple mode. Libraries are added to the migrator's SOURCE LIBRARIES section (if not already populated) from the button, or by dragging and dropping a library file onto the area. Use the right-click option to exclude a selected library or extracted sub library from the migration.

The MIGRATION PREVIEW section lists component type groups identified from the source libraries – as Component Types () or the proposed Folder Structure () – and includes a parameter-based grid view of those components (Components). Parameter values in the grid can be edited on-the-fly, which avoids the need to open and edit the source library. The lower Details area includes additional information sourced from the currently selected component – Part Choices, Models and Datasheets.

Regardless of the detailed options and data presented in the interface, the migrator's Advanced view can be used in the same manner as the Simple view – just click the button to invoke the migration process, without intervention. As in the Simple view process, the migrator has analyzed the library, deduced the type of components it contains, and applied the correct Component Template. In turn, the template determines the server target folder, the applied Naming Schemes and Lifecycle Definitions, and parameter mapping/interpretation.

Monolithic Libraries

Source libraries that contain multiple component types are detected by the migrator's analysis routines and segregated into sub-library groups, where they can be processed as individual type libraries. The component type detection is based on the source component Designators (R?, C?, etc) and also key words (Resistor, Res, etc) contained in the other main component parameters (Description, ID, etc).

In the example shown below, the source library (ProjectABC.IntLib) has been 'split' automatically according to the detected component types (Capacitors, Resistors, etc), which can be selected in the Component Types column to preview their constituent component entries in the Components grid.

Note that the presentation of the Components listing may be changed in several ways:

• Click on a column header entry to reorder the list by that parameter column, and then click again to reverse the order.
• From the header right-click context menu:
  • Choose Clear Sorting to revert the listing order to its default setting.
  • Choose Best Fit to match a particular column width to its contents.
  • Choose Select Best Fit All Columns to match all available columns to the width of their content.
  • Choose Select Columns to access a Select Columns dialog, where parameter columns can be enabled, disabled and their list positions reordered.
• Click on the Filter icon () within a header entry to restrict the listing to an available parameter column value, blank/non-blank values, or a Custom filter setting. The applied filter is shown at the bottom of the listing where it can be enabled/disabled (using its associated checkbox), modified in the Filter Editor, or deleted. Selecting All via the header filter icon () will also remove the applied filter.

Uncategorized Components

In the monolithic library shown above, one library sub-group entry is named Uncategorized (and listed as Uncategorized under Component Types), which indicates that the migrator could not detect and assign a type to that group of components – the Component Type is effectively set to None. In this example case, the undetected components (Inverter logic ICs) use an unrecognized Designator prefix (U?) and their parameters do not contain detected key words such as IC, logic, etc.

This issue can be addressed by manually mapping the designators used for those components to the desired component type in the Library Splitting dialog, which is accessed from the button – available when the source library (ProjectABC.IntLib) is selected.

With the dialog's Custom Designator Mapping option selected, click the button to create a new mapping entry, choose the designator string option that applies to the uncategorized components from the Designator drop-down list (all available designators are included), and then the desired component type option from the Component Type drop-down menu. Confirm the completed type-designator mapping (U? designators to the Logic component type) with the button. Note that if needed, multiple comma-separated designator types can be entered manually.

With the component type now specified by the applied mapping, the migrator will use the matching Component Template (Logic) to configure the library migration as defined by the template settings (folder, naming, etc).

Note that thanks to the flexibility of the Library Migrator settings, a new (uncategorized) type of component library can be migrated with the entire infrastructure required for future migrations of that library type. By choosing a suitable migration configuration – new Component Type, Component Template, target folder, parameter mapping and parameter Value unit types – the only requirement for the next migration of that library type is to select the previously defined Component Type. The selected Component Type will then determine all other aspects of the migration.

Validation Errors and Warnings

Components that will not be migrated to the server correctly, or not at all, are indicated by warning or error tags in the Advanced UI when the Library Migrator is run (), or a migration Validation is performed (). A Fatal error will block the migration.

When attempting to perform the migration, the Messages panel is populated with the detected violation issues, and a dialog will offer the choice of abandoning or proceeding with the current migration configuration. In the latter case, invalid components are not migrated or the migration process will fail.

In the case of a canceled migration or when the manual Validation is run, any components that fail the migration checks are then associated with error/warning icons plus further information in the lower Details area. Icons in the preview Status column indicate the specific component entries that are in violation of the migration rule checks.

Resolving Errors and Warnings

Parameters errors, such as in the example shown here where the component's Forward Voltage value cannot be interpreted to a valid voltage, can be resolved by:

• Removing the component from the migration process – right click on its entry and choose the Exclude from Migration option.
• Editing the offending parameter Value – locate and edit its cell to a compliant format.
• Changing the mapped parameter unit Type, as determined by the applied Component Template, from Voltage to uninterpreted Text – select the Source Library in the migrator UI, and then change the Forward Voltage Type in the Properties panel Parameter Mapping list (under the General tab).

A missing file error, such as the unlocatable Datasheet file shown here, can be resolved by:

• The obvious solution of locating and restoring the missing file to the expected location.
• Excluding the component from the library migration process – as described above.
• Disabling the migration of datasheet files – change the Migrate option in the Properties panel Datasheet section (under the Advanced tab).

Use the Search field (upper right) if you wish to find particular component entries. The search filters the item listing by matched parameter value(s) for the currently selected component type – select All under Component Types for the search to apply to all components in the available source libraries.

Schematic Library Migration

If you encounter a 'model not found' error (such as Footprint <footprint name> not found in available libraries) when attempting to migrate a schematic library, it means that the Library Migrator cannot locate the models that are linked to components within the SCHLIB.

In Simple Mode such errors will be shown in the HTML-based Migration Report, accessed from the button that is available when the migration has been run. In Advanced Mode, the errors are indicated by Status icons in the main interface () and as entries in the Messages panel – this occurs when performing a validation check () or when attempting to migrate the library ().

The simplest way to resolve (or avoid) this issue is to ensure that the required model library files are available from within Altium Designer. Libraries are installed through the Data Management - File-based Libraries page of the Preferences dialog.

Alternatively, if you do not wish to install multiple model libraries, you will need to locate them in the software's default library path (or edit the path), and check that the model source library is specified for the Schematic Library components:

• Include the model library in the software's default search path location. Add the model library, such as a corresponding PCB Library, to the location specified by the system's default library path. To check this location, see the Library Path entry on the System - Default Locations page of the Preferences dialog. If a library file has been added/copied to that path location, you may need to restart Altium Designer to register the change.
• Specify the target model library name for Schematic Library components. So that the model library linked to by a schematic library component will be known to the Library Migrator, specify its name in the library PCB Model dialog.

Duplicates Detection

The Library Migrator also includes mechanisms to avoid duplicate components being created in the target server. This is achieved during validation by comparing the source library's component identifier parameters and Part Choices with those of components in the target server.

With the migrator's default settings, a Validation step () will flag a Warning message when the same component Name or Part Choices entry (indicating a potential component duplicate) is detected in the target server. The displayed warning/error message includes the type of duplication violation (parameter or Part Choice), the violating library component name and the server component (by ID) it is in violation with.

Two potential duplications detected by the Validate process, where the component's Name (top image) or its Part Choice (lower image) already exist in server components.

The parameter name-value pair used to detect duplicate violations is specified in the Duplicates Detection region of Properties panel, under the Advanced tab. Use the Unique Field drop-down menu (set to Name by default) to select from the Parameters available in the source library. This selection is particularly useful for company library configurations that use a proprietary identifier field that ties into the broader enterprise system.

A duplication violation detected where the value of a specified parameter (ERP-REF) is the same for a local library component and a server component.

A different type of status flag can be set for the duplication violations by selecting an alternative Report Mode in the Migration Checks region under the General tab of the Properties panel.

Single Model Libraries

Automated duplicate detection also is used to process source libraries that use a common symbol model for all components. Such libraries tend to be composed of a single component type with differing styles and values, such as resistors of a particular package format, where the symbol for each is a standard model graphic.

This single, common model condition is detected by the Library Migrator, which then configures the migration to transfer one symbol model that applies to all migrated components – rather than a corresponding, individually named symbol for each component. The symbol to be migrated adopts a generic Symbol name, and all component parameters remain unchanged.

The migrated library symbol (which has the name Symbol and a blank Description field) can be edited to suit your needs. In the Explorer panel, use the right-click Edit option to invoke the action. During the process, select the Update items related to <symbol ID> option in the Create Revisions for Item dialog to ensure that the migrated components use the new symbol revision.

Merge Component Types

The range of Component Types registered with the system – or in practice, in the connected server – can be viewed and managed in the Data Management – Component Types page of the Preferences dialog. Types are listed with their associated component Template and server Folder, and will include any new types created when the Library Migrator has migrated library files to the server.

The creation of multiple new Component Types might typically occur when a Library Migration configuration has used Parameter Grouping (a nominated component parameter value) to determine the Type for each migrated component. For example, the Categories parameter might be Resistor-0608 for one collection of migrated components and Resistor-0402 for another, and so on. Here, all would be best grouped under the single Resistors Component Type for future use.

Rather than manually changing all the Component Types in these circumstances, the Component Types page in Preferences allows selected Type entries to be merged into a specified single entry. To do so, select all Type entries to be merged, including the target Type, right-click on the highlighted entries and choose the Merge option from the context menu. In the following Merging dialog, select the target Component Type from the Merge to drop-down menu and click the dialog's button to confirm. The below image illustrates this for a range of migrated Resistor component types.

The process changes the Component Type for components of the merged type (such as Resistor-0402, Resistor-0603, etc) to that of the merge target Type – Resistors in this example. One of the practical outcomes is that all components of a particular type will now be available when that type is selected under Categories in the Components panel. Note that the component entries are not affected in any other way. They remain in their existing folders, which are associated with the Component Template created during migration, and the templates themselves remain available.

Following the merge, the Data Management – Component Types page now indicates that the Resistors component type is the default for multiple Templates – namely, the Resistors Template and all those associated with the newly merged component types (the Resistor_0402 Template, and so on). The Folder entry for the Resistors component type corresponds to the target folders of those multiple templates.

The result of such a merge is that when Resistors is chosen as the migrated component type in the Library Migrator, it will be applied if you select any of the merged Templates (Resistor_0402 etc) as an alternative. When a new component is being created (File » New » Component), those Templates are offered as sub entries for the Resistors Component Type in the Create new Component dialog.

Template Assignments

The Edit Templates dialog, accessed from the button, allows you to update the Template to Component Type mapping from that indicated in the Data Management – Component Types page. The mapping, as shown in the dialog's column entries, represents which Component Type be will applied when the associated Template is used – or conversely, which Template is used when a Component Type is chosen (such as when creating a new component).

For a selected Template entry in the dialog, the association is changed by choosing an alternative Component Type from the entry's drop-down menu. When the dialog and page are then closed, the template's ComponentType parameter value and its Default Folder setting will be changed to correspond with the newly specified type. This is equivalent to editing the Template manually.

The result of the updated template-type mapping is shown in the Data Management – Components Types page, which has a Name orientated listing – where Name represents Component Type. This indicates that a number of different templates (Resistor_0402, Resistor_0603, etc) are associated with and will apply the Resistor_LibMigrate Component Type.

Models Only Migration

The Library Migrator may be switched to a special Models Only migration mode that detects and processes the available component models in a source library. To change to this migrator mode, check the LibraryMigrator.ModelsOnlyMode option in the Advanced Setting dialog, available from the System – General page of the Preferences dialog.

In the Models Only mode, the migrator's analysis process will detect all Symbol, Footprint and Simulation models that are available in a source library (IntLib, SchLib, PcbLib, etc), then migrate those models to the server using the system's default locations, naming schemes and lifecycle definitions.

When the Library Migrator is switched to its Advanced mode () or opened in its Advanced mode (File » Library Migrator), full details of the proposed model migration are available. The Migration Preview area shows the Folder Structure that will be used in the target server, which may be modified from the default settings in the Folder field for each model type in the Properties panel. The applied naming schemes and Lifecycle definition for each model can be selected from the available system types (see Properties panel, below).

The migration of component models to the server can be limited by type if desired, by disabling (or enabling) specific model types in the Properties panel using their associated buttons.

Once the Library Migrator is configured, select the button to complete the migration of the listed component models. The results can be reviewed in the migration log file, as offered by the Library Migrator progress dialog (), or by viewing the migrated models in the Explorer panel.

Properties Panel

The Library Migrator's associated Properties panel settings provide advanced control over the migration configuration for the selected library (or sub library group). The panel's option settings are defined by the default system settings or those specified by the applied Component Template, which in turn is set by the library's detected component type – LED in the example shown here. The settings are also user editable, allowing you to tailor the migration process as required, and may be restored with the Reset to Default link (top right).

The panel's General tab sections are as follows:

• General:
  • Component Type – The type of component detected by the migrator for the selected library, and by association, the template that is applied (see Component Template below). Overrule this setting by editing the field, which will create a new component type, or by selecting an alternative type using the drop-down menu options (or via the button) – this is another way to address an uncategorized component issue. Choose the [LibraryName] option to set the type to be the name of the selected library.
  • Component Template – The server-based Component Template that will be applied to the migrated components, and by association, their Component Type setting. Overrule this setting by selecting an alternative template using the drop-down menu options (or via the button). Set this option to [Create new] for the automatic creation of a template derived from the source library parameters and the Library Migrator's current settings, or choose [No Template] to prevent a template from being applied or created.
    Note that the Component Type and Component Template settings are effectively bound together when set to an available Type/Template – for example, if either is set to Capacitors the other is automatically set to Capacitors. However, if in this case the Component Template setting is changed to [Create New], another Capacitors template (named with an appropriate version/revision suffix) will be created to comply with the current settings. Existing Component Templates are not altered by the migration process.
• Parameter Mapping – The parameter matching between the library parameters and those in the applied component template (or the default settings where no template is available), and also the Type of value for each parameter (Text or a unit-aware type). Use the Source Library Parameter column drop-down menu options to change the mapping, and the Type column menu options to overrule the existing setting determined by the template or defaults. Choose the <Skip> option to not include a parameter. Any parameter that has not automatically been matched to a source library parameter (is set to <Skip> by the system) can be manually mapped to a suitable Template parameter – for example, the source parameter ROHS might be selected to match the RoHS Compliant parameter defined by the server template.  Parameter names can be edited, and Parameter sets can be added, edited and removed. The base component parameters (ID, Name, Description) may be remapped, but are otherwise read-only.
  For the Server Parameter ID, the Source Library Parameter is set to <Auto>. This results in component IDs automatically created based on the Naming Template specified in the panel's Component section, found under the panel's Advanced tab. The ID mapping can be changed to use any parameter in the source library (that is unique for each component entry) by choosing an alternative from the Source Library Parameter drop-down menu. Note that the base component parameters (ID, Name, Description) may be remapped, but are otherwise read-only.
• Part Choice Mapping – The list of manufacturer part or supplier link parameters recognized by the migrator, which will be used to derive Part Choices entries for migrated components. Use the drop-down menu options to redefined the mapping, or add and delete mapping sets. Note that by default, manufacturer part and supplier link parameters are not included (are skipped) in the migration process. Where multiple supplier links are included with a library component, the primary supplier reference (Supplier 1 / Supplier Part Number 1) is used for the Part Choices field entries.
• Migration Checks – View or set the migrator's error/warning response to violations of the migration validation rules. Use the Report Mode drop-down menu to change the response and icon for a Violation Type entry. Note that if the Fatal Error report mode is selected, it will block the migration process when this violation is detected.

The panel's Advanced tab offers settings for all migrated data object items, as set by the system defaults or the applied Component Template. These include component Models, Datasheet files, and any created Component Templates. With the exception of the Datasheet option (an enable/disable toggle) the settings for each migration object include:

• Folder – The target server folder for the migrated object, which may be manually edited (say, to create a new target folder) or selected via the browse button ().
• Naming Scheme – The object's server naming specification as defined by the Component Template, or in the absence of an active template, the scheme set for the target folder (or as manually entered). Use the drop-down menu to choose from the available Naming Schemes. Note that a change in target folder path (Folder) may be accompanied by change in the applied Naming Scheme, as set by the folder itself or by an applied/associated Component Template.
• Revision Naming Scheme – The naming arrangement used for the object's server revisions, as set by the applied template or selected from the entry's drop-down menu options. Only those schemes enabled by the system will be available as an option.
• Lifecycle Definition – The Lifecycle system that is used for the object, as set by the applied template or selected from the entry's drop-down menu options. Only those definitions enabled by the system will be available as an option.

Export-Import Configuration

The Library Migrator features the ability to export a detailed text-based file that captures the current configuration setup, which includes all configurable migration settings such as target paths, parameter mapping, naming scheme, lifecycles definitions, target component types, and so on.

The Migration Configuration file is saved from the File » Export » Migration Config command as a *.lmcfg file type, and may be restored at any time through the File » Import » Migration menu option.

The ability to restore a configuration is particularly useful when the source file-based library has been updated and those changes need to be migrated to the server. If the configuration was exported when the library was first migrated, the restored (imported) configuration will re-establish the exact configuration settings that were used, which guarantees a consistent data transfer scheme for that library (or libraries).