Migrations

You will most often need a migration when, as a developer, you modify a Petriflow process and want to apply the changes to existing cases. Select what changed between the original and new process versions.

I changed a Petriflow process

Was a field added, removed, or renamed? Did its type, value, or field metadata change?

1. Update the runtime dataSet of every existing case; importing a new version alone does not change it.
2. For a new field, copy metadata from the exact target PetriNet and calculate the business value separately.
3. When changing the type, convert the value and verify invalid and empty input.
4. This area also includes choices, options, allowedNets, validations, and the field's global immediate flag.

View procedure and code →

Importing a new process version does not automatically update existing cases. After selecting a recipe, continue with the procedure for migrating existing cases, where you will find the order of operations, an Admin script template, and result verification steps.

I am upgrading Netgrif Platform

Platform release migrations are prepared and published by Netgrif. The recipes above are intended for migrations caused by changes to Petriflow processes and do not apply to Platform upgrades.

If you are upgrading a deployed Platform instance, open the migration catalog, select the source and target versions, and run the published tasks with the ready status in the specified order.

View migrations for a Platform upgrade →

I already have a migration script

If you already have an approved script and only need to run it, go directly to the Admin execution procedure. Read the technical helper API only if you are modifying or writing the script.

Before every production migration

Create a restorable and verified backup of the affected systems, and first run the migration on an up-to-date copy of production data. MongoDB, Elasticsearch, and storage do not share a single transaction.