Promoting Configuration Across PI System Environments - White Paper

Discussion created by rwilliams on Jan 6, 2020

In this white paper, we discuss, at a high-level, the implementation involved in the promotion of PI systems and configurations across system environments.  By promotion, we are considering the overall process of migrating PI configuration data from a lower level system to a higher level system. The source system is where the configuration originated, while the target system is the final system where the configuration is to ultimately be utilized. Typical reasons for promoting configurations from one system to another include:

  • Implementing test environment configurations into a production environment.
  • Standardizing a corporate approved configuration to individual sites.
  • Syncing centralized corporate system with required updates from individual sites.
  • Create consistency across broad systems.


A well-designed promotion process should:

  • Minimize custom configuration on different environments.
  • Automate repetitive steps when possible.
  • Identify potential variation between environments in order to achieve identical functionality, as needed.


In general there are many classes of configuration data which may need to be moved between environments:

  • PI Point database containing PI Tag configuration
  • PI Interfaces configuration
  • Customer-developed PI MDB (module database)
  • Customer-developed PI AF database hierarchy (including Asset Based Analytics)
  • PI ACE calculation code and context definitions
  • PI ProcessBook displays
  • PI DataLink spreadsheets
  • PI WebParts pages/sites
  • RtReports reports
  • PI Coresight displays 


This document assumes the use of the following PI component versions or later:

  • PI Data Archive 2012
  • PI AF Server 2014 R2
  • PI ACE 2010 R2
  • PI DataLink 2014
  • PI ProcessBook 2014
  • PI WebParts 2010 R2
  • RtReports 3.2
  • Coresight 2014


New versions of software may utilize different functionality that make any implementation processes described in this paper obsolete.  If there are any questions, please consult the applicable manual or administrator guide, as well as OSIsoft Tech Support.


Additional assumptions include:

  • Individual component promotion is only performed within the same PI Server and component version.
  • Reader is familiar with PI System Management and is a PI Administrator for their organization.


This document scope does not include testing/verifications of upgrades, patches, etc.  This type of information is described in the KB Article PI System in a Test Environment , listed in the References section of this document.


Customer Portal download: 


(OSIsoft Employees Click Here for List of White Papers)