Do I need to do intermediate upgrading or not for upgrading a system platform 2014 to latest 2023 version ?

Dear Team,

I previously found the following statement in the official documentation:

Upgrade to System Platform 2023 R2 SP1: You can upgrade to System Platform 2023 R2 SP1 from System Platform 2017 or newer. If you are running a version older than System Platform 2017, you must first perform an intermediate upgrade to a version that supports a direct upgrade path, and then proceed to upgrade to System Platform 2023 R2 SP1.

However, I’ve spoken with some AVEVA experts who mentioned they were able to upgrade directly from System Platform 2014 to the latest version, which contradicts the documentation.

Could you please clarify what might happen if the intermediate upgrade step is skipped? Are there any known risks or limitations?

Thank you,

  • Hi, there are multiple ways to migrate/ upgrade to the latest version

    1) Migrating: Take the whole project backup, back it up in older version, get a new machine, install latest ( SP 2023 R2 SP1 P02 ) , open the legacy backup with this new system, it will automatically upgrade - Support from SP 2017

    2) Upgrading: Export all objects from legacy application, get a new machine, install latest ( SP 2023 R2 SP1 P02 ) , create a new project, import the objects  - Support from SP 2014

    Hope this answers your query Slight smile

  • Samer:

    Yes, you should do intermediate upgrades.  The recommended path is to upgrade first to version 2014 R2 SP1, which is the last stable version before the 2017 release.  From there, you CAN upgrade straight to 2023 R2.  The reason to move to 2014 R2 SP1 is to ensure that all of the galaxy optimizations and visual element fixes up to that version are included in your galaxy.  From there, move to 2017 Update 3 SP1, which will bring you within the upgrade window for 2023 R2.  

    Not following this path may ruin your ArchestrA graphics, mainly.  There are a lot of iterative additions and enhancements to A2 graphics through the 2014-2017 realm that could get broken.  

    You should also be aware of the version of your SQL database, as Microsoft limits how far back one can upgrade a database.  For example, a SQL 2022 instance cannot upgrade a SQL 2008 R2 database, so you need to move it to an intermediary database.  Fortunately, doing a galaxy migration in an intermediary step will do that for you.

    I would highly recommend upgrading with parallel VMs or hardware; an in-place upgrade can be dicey moving between a large version jump like that.  

    My path would be:

    1.) Create 2014 R2 SP1 VM.

    2.) Create 2017 Update 3 SP1 VM.

    3.) Install 2023 R2 SP1 P02 on your target system

    4) Using the Galaxy Database Manager's SMC on the GR, backup your galaxy database from 2014 (i.e. SystemBackup2014.cab)

    5) Copy cab file to 2014 R2 SP1 VM. Place in C:\Program Files (x86)\ArchestrA\Framework\Bin\BackupGalaxies\

    6.) Open IDE and create new Galaxy with database type of your backup name (it will show in the dropdown, ie.SystemBackup2014.cab).  Open the galaxy and it will upgrade.

    7). In the IDE, open galaxy.  Open each InTouch application to migrate to new InTouch version.  Make sure not to mess up your resolution on accident!

    8.) Close the IDE. in the Using the Galaxy Database Manager's SMC on the GR, backup your galaxy database from the new version.

    9.) Repeat steps 5-8 on the 2017 Update 3 SP1 VM, then the 2023 R2 VM.

    A couple tips:

    1) there is a stored procedure in the 2014 R2 SP1 SQL database called "internal_validate_integrity" - you can run this (it takes a while, start it before you leave for lunch and come back) to see if there are major issues with the database.  If things come up bad, call in to your support provider for help.

    2) You will ALSO want to do similar steps for your historian - back up the runtime database through SQL management studio, restore to each version, and use the configurator to upgrade.

    3) If you want to move your alarms to the history blocks, there is a utility you can use to do that in the Historian directory, so make a backup of your A2ALMDB. 

    4) You could also export all the objects and import them; however - you will not get anything that's not an object.  For example, security is not exported this way.  Language changing.  If you are using styles or status overrides, they are exported separately.  The best approach is to use the cab file as it gets you a full complete backup of your galaxy. 

    Other things to consider during an upgrade

    1) Removing Legacy Field attributes - while AVEVA is still supporting the field attributes, they are deprecated and should be migrated.  Read up on what you need to look out for (most commonly, its animations and scripts that use input.inputsource and output.outputdest as these are the major changed attributes) and see if making the migration is a good idea.

    2) utilizing the IO binding and attribute overrides vs. any autobind scripting - autobind scripting serves a purpose but if you can use a combination of the IO Device mapping and Overrides, it is a far more stable and robust IO assignment tool at runtime, and will decrease your deployment and onscan times. 

    3) be sure to look at new settings (like enabling the "warm restart" on redundant engines) that will improve performance. 

    Hope this helps!