Migrations

If we need to update a node in the standard library your existing copies of that node might need migrating. This is signaled by a colored icon above the node. The color and tooltip of the icon can give you more information about this migration.

To perform a migration right-click on the node and select Refactor -> Migrate node. This can update the configuration and ports of the node and even swap it for a completely different node. In all but a few rare corner cases this should leave the node working just as before.

Migration statuses

A green migration will never change what the node does and is applied automatically when executing the node. Configuring a node with a green migration status will also migrate it to the latest version.

A yellow migrations has to be triggered manually. It might change what the node does in a few rare corner cases, but for the most part the node should not change behavior.

A red migration status means that the node can not run without being migrated, but the migration can also not be performed without changing the node’s behavior. This could for example be the case if a node uses an option that has since been removed completely from the node. The node can still be migrated, but the behavior will have changed and the flow will need to be adapted to the new behavior. These situations should hopefully not be very common.

Migrations and overrides

Extra care has to be taken when migrating a node that is selected in subflow settings. The current overrides for the node will be migrated alongside the node, but any overrides for the node that exist in other syx-files will have to be migrated separately by right-clicking on the relevant subflow and selecting Refactor -> Migrate overrides.