Migration from PI Notifications 2012

PI Server 2016 R2 and later versions include a migration tool to enable migration of your 2012 notifications to notification rules based on event frames. The migration tool is run at the end of the PI Notifications Service install, and you may choose to migrate your legacy notifications at that time.

You may also run the migration again from PI System Explorer, after the installation is complete. To run the migration tool from PI System Explorer, make sure that all these conditions are true:

• PI Notifications Service is installed on your machine

• The migration tool executable file PINotificationsMigrationTool.exe is installed on your machine, typically in the PIPC\Notifications folder

The Notifications Migration Tool attempts to migrate all existing notifications by modifying the rule and if necessary prompting you to accept or reject the change if a feature is no longer supported. This section describes the types of notification features that are migrated and those that cannot be migrated.

The migration tool causes these object migrations:

• Legacy notification triggers are migrated as event frame generation analyses and are run in PI Analysis Service.

• Legacy notifications created in previous versions are migrated to notification rules, and they run in the PI Notifications Service.

• Legacy notifications history is fully migrated and created as event frames. History in PI points are migrated as annotations on event frames.

• Legacy notification template name, description and properties are mapped to the notification and target properties; a message is also logged in the migration report.

  Note: Properties of the notification rule template cannot be overridden on a notification rule based on the template with an exception of the description field.

  Due to this, if a legacy notification deviates from the legacy notification template, that information may be lost during migration. For example, if the legacy notification template is named "Notification for Pumps", but a legacy notification based on this template is named "Notification for Pumps - Houston", the migrated notification rule template and all notification rules based on this template will be named "Notification for Pumps". The description field of the migrated notification rule, however, will contain the name of the legacy notification. The migration report will contain the name changes and any other changes that have been made.

The migration tool does not migrate the following legacy notifications:

• Custom delivery channels

• Alarm functions

• Monthly and daily period time rules

• Notifications with the Notify only on change in status option unchecked.

• Notifications containing a nested escalation

• Notifications with multiple triggers:

  • If a legacy notification has multiple triggers and you have assigned states from different state groups, the legacy notification is not migrated.

  • If a legacy notification has multiple triggers and you have assigned the same state to more than one trigger, the legacy notification is not migrated.

    Note: For a list of legacy notifications that are not migrated or migrated with some loss of content, see the knowledge base article: Caveats in Migrating from Notifications 2012 to 2.x.

Training video

For more information on migration, watch the AVEVA PI System Learning channel video:

Running the migration tool

If you are running the migration from PI System Explorer, make a backup of the PIFD database before starting the migration. For instructions on how to perform a backup, see the PI Server Installation and Upgrade guide topic: Backup job. Note that you can also migrate notifications when you are upgrading PI Server.

Before you begin migration you must verify that you have read permissions on the Data Archive where the legacy notifications history is stored and read/write permissions on the PI AF database where the legacy notifications are configured.

You may need to back up the PIFD (SQL database) if you want to re-run the migration and avoid having duplicate notification rule and analysis objects created. If you re-run your migration and are warned that duplicates may be created during the re-migration, you can first restore your PIFD database from the backup and avoid the creation of duplicates.

You can re-run the migration tool by clicking Tools > Notifications Migration from PI System Explorer. The migration tool first determines and displays information on your state, which is one of:

• Not migrated

  Legacy notifications may be created and managed using the Notifications plug-in on the bottom left of the PI System Explorer window. You must use the 32-bit version of PI System Explorer to manage legacy notifications.

  You can choose to be in the "Not migrated" state by choosing the appropriate option while running the migration tool. In this state, you cannot create new notification rules.

• Migrating

  Legacy notifications are read-only; only new notification rules may be created. You can stop and start legacy notifications while in this state.

  In the migrating state, you may run and test legacy notifications and new notification rules side-by-side to ensure that the migration is successful and that the new analyses and notification rules are working as intended. You can check the migration report, fix the errors indicated on legacy notifications, and then choose to re-run migration for only those legacy notifications that encountered errors in the previous migration run.

  You may move to the migrated state when you have successfully tested that your migrated notification rules match your legacy notifications. Move to the migrated state only when the following are true:

  • You intend to continue to work only with the new notification rules

  • You will never need to revert to your legacy notifications

  • You have successfully migrated all the legacy notifications that you wanted to migrate

• Migrated

  When you move to this state, you can create only new notification rules in the system. Your legacy notifications are deleted and you cannot revert to your legacy notifications or create legacy notifications.

  From the migrated state, you may re-run the migration tool to revert to the "Not migrated" state; however, your legacy notifications cannot be recovered.

After all legacy notifications have been converted, you may want to run both versions of notifications in parallel for a while to ensure that the notification rules are functioning as expected. When you are satisfied with the migrated notifications, run the migration tool again and select Complete migration and delete all legacy notifications from server. After running the tool you can also uninstall PI Notifications 2012. It is strongly recommended that you uninstall legacy PI Notifications after any transition period.

If you do choose to run both versions of notifications simultaneously for a period of time, be aware that each notification may be sent twice, once from the PI Notifications Scheduler, which is part of the legacy PI Notifications, and once from the PI Notifications service. If you do not want to receive duplicates during this transitional period, you can disable the PI Notifications Scheduler.

You must manually create notification rules for any unsupported legacy notifications that were not migrated.

Note: The Notifications Migration Tool only needs to be run once against an AF Collective.

Migration report

The migration tool generates a report when it completes the migration process. The report includes information on whether legacy notifications are migrated successfully. The "Errors" section and the "Not Supported" sections indicate notifications that are not migrated. The "Warnings" section indicates notifications with changed functionality, and the report provides more information.

Note: Migration report can be found in %userprofile%\Documents folder of the person running the migration.

In addition to the summary, the report also contains information on legacy and migrated notification rules and templates, and specific information such as notification rules and analysis names, number of migrated event frames, and the number of processed history events.