All posts

Importing SCOrch runbooks and reviewing the result

Existing automation is more than a row of boxes. An import also has to carry over the links and the data between them.

A mature SCOrch runbook holds a lot of work: the right order, error handling, conditions and data passed from one activity to the next. That is exactly what nobody should have to rebuild by hand during a migration.

Start from the existing export

NodePilot reads SCOrch exports in the .ois_export format. You can start the import from the web UI or the CLI:

np workflow import-scorch --file .\runbooks.ois_export

Supported activities are translated into matching NodePilot activities. Links, conditions, global variables and published data references are carried over as well. The folder structure can come along too.

The import report is part of the result

Not every activity and not every property translates without loss. An unsupported activity should therefore not simply disappear. NodePilot creates a disabled placeholder for it and lists the relevant details in the import report.

Incomplete target system settings, data references that cannot be translated and schedules that carry over only approximately need attention as well. The result is a starting point for a review, not a promise that every automation runs unchanged.

Review, test, enable deliberately

Imported workflows start out disabled. Credentials are not reconstructed from the encrypted SCOrch data. Before enabling a workflow, check the items named in the report, the target systems, permissions and error paths.

Then test it in a suitable test environment. Only when its behavior meets your requirements do you enable the workflow explicitly.

The migration decisions stay with you. What the import adds is the actual runbook and a report you can follow.

Background and current details: SCOrch import in the NodePilot README.

Back to the blogGo to the documentation