• Not Answered

DeltaV upgrade from v7.4 to v14.3

Hello everyone,

I have the following systems:

1. DeltaV v14.3 consisting of 4 controller nodes, licensed for 10 operators, 1 engineering station, 1 server station and 4000 DSTs. Around 1500 DSTs and 1 Operator Station is free at the moment, everything else is in use.

2. DeltaV v7.4 consisting of 1 controller node, licensed for 1 engineering station, 1 operator station, and 375 DSTs.

I want to migrate v7.4 to the existing v14.3. I have 2 MD+ controllers in hand and sufficient licensing for the 375 DSTs.

Please help in how I can migrate everything to v14.3. A step by step procedure would greatly help.

Thank you!

• DeltaV migration
• deltaV upgrade

Kamil Raza

• 2 Oct 2025 2:27 AM
• Cancel

4 Replies

• Robert Rijnders

  

  • 23 Dec 2025 7:42 PM

  Mind the DST licenses are depended on I/O type (i.e. AI/AO/DI/DO) Also licenses are linked to the unique dongle and can't be merged or migrated to another system. Contact Emerson if you want to merge the system licenses.
  
  Always make a full backup of both systems before startng.
  Export the 7.4 configuration. Deselect license information and data for upgrade.
  On the 14.3 system use 'Migrate configuration' in Database Adminstrator to update the 7.4 FHX to v14.3. Tool will fix most common issues like empty expressions.
  Import the migrated file and decide what to do with duplicate items. Check import log for errors.
  Make sure the MD+ controllers are decommissoned before connecting them to the 14.3 system
  Connect and commission controllers to database placeholders.
  Flash controller firmware to 14.3.

  • Cancel
• Andre Dicaire

  

  • 24 Dec 2025 1:28 AM

  In reply to Robert Rijnders:

  Robert's sequence of steps is good. But I'll flesh out a few items:
  
  First, when consolidating two systems, you should work with your local Impact Partner or Emerson Office to see if you should consolidate the licenses from one system into the other. Your v7.4 system has a Pro Plus, a Pro Station (or is this the Pro Plus Engineering station), and operator station. A redundant controller will have a Redundancy license. A consolidation of licenses will preserve the value of the v7.4 system, increasing the system and IO DST licensing for you to use in the future. You don't need to consolidate the two systems. The license agreement does not allow you to resell the software, not without Emerson's approval. If you don't consolidate, you could stand up a new system in the future by renewing the Guardian support and getting access to install the latest version of DeltaV, certainly at a lower cost than purchasing new. If you consolidate, and receive a scale up license for the System, you can choose not to install this until you are ready. Increasing the Pro Plus system DST will trigger an adjustment in the Guardian support annual cost. Be sure you know what you want to do. I think you could do the license consolidation later as well. However, the cost may be different later. So you have to run the scenarios with your support company.
  
  Combining two systems means one will go offline as you have to decommission the controllers to add them to the new one. How long do you have for this outage? If you run into some complicated consequences of duplicate items, you could end up with a longer outage. Worse, if you overwrite an item in the v14 database that is disruptive to that system, you could trigger an unexpected outage. It is highly recommended to verify the global items for duplicates such as Named Sets, Alarm Names, Priority names, etc and align this. For instance, you may have the same Named Set created in both databases but one has an extra Named State, or the states are in a different order. By default, the import will look at modify dates and defers to the latest date item when duplicates are found.
  
  The name space in DeltaV includes Module names, DST's, Node Names. You should confirm no duplicates exist. Address these in the v7.4 ProPlus database before export for consolidation.
  
  Your export will include your v7.4 Pro Plus, which cannot import even if it has a different name. There can only be one Pro Plus.
  
  The v7 controllers can be pre-commissioned in the v14 system with the same node name as in the v7. This will create these place holders with valid IP addresses in the v14 system, and you can upgrade these controllers, so they are ready to receive their configuration to be downloaded. One less activity to do while the v7.4 system is offline. If time is not an issue, you can import the migrated FHX and let this create the controller place holders. You will typically see warnings as the IP addresses of the v7.4 controllers are likely already in use. The System will reassign new addresses. Which is why you need to decommission these controllers so they can be recommissioned to the new system IP addresses. A clear execution plan should be written up that provides all the details and the chosen activities for the migration.
  
  All the v7.4 nodes must be disconnected from the network before connecting the v7.4 DeltaV networks into the v14.3 system. The Workstations especially must remain disconnected until you have run Workstation configuration so that their NIC IP addresses have been set to valid addresses on the v14 system. If you are not retiring the workstations, you can just disconnect them. I suggest you manually change the IP addresses to unused addresses, such as 10.4.0.2, or even 10.20.0.2. That way if someone incorrectly reconnects these network cards, you don't create a duplicate address issue. this could disable the Pro Plus or a controller. Detail this in your execution plan.
  
  Migrating a v7.4 to v14 is a significant jump and there have been many changes. Each version introduces some new or modified features. Emerson tests the migration utility for supported migration paths, typically two previous versions. So v12 would be supported. v12 would support v10, v10 utility would support v8, and that supports v7.4. You could throw caution to the wind and migrate v7.4 to v14 and see what happens. Especially if you don't have to migrate licensing. The challenge is you have to have a proplus of each interim version to use that versions migration utility. That may be problematic.
  
  You can certainly start with a direct migration and see what comes up. If successful, you can then do some checking on what changed. When we help our customers migrate, we setup a target version of the Pro Plus and if consolidating, we load the target existing configuration. Then we are able to import the FHX file and review all the issues. This will find duplicate items, incomplete items, and modified items. Which brings up a structural change that is enforced in v14 (started in v12). Prior to v12, including v7.4, copied modules could contain the same embedded block. This is was not expected and not possible if creating embedded blocks. On a copied module, the embedded block has the same name in the copy, but as soon as the block is edited in Control Studio, it's hidden name changes. When your migrated v7.4 FHX imports, a duplicated use of an embedded block will cause the second instance to be replaced with a new version of the embedded block so that each embedded block in the database is referenced by one and only one module. An issue however may exist where the Embedded block parameters are modified/different at the host module level. Under normal circumstances, this module level "override" takes precedence over the value of the parameter in the embedded block. But this newly minted copy carries a date stamp of the day it will be created, and that means the controller will use the default value in the block at runtime. At least that was the issue in v12. I don't know if the issue created by the import has been addressed.
  
  My point is, I know this is a long post, is you should check for duplicate use of embedded blocks so you know to check these at runtime. If no new embedded blocks were created, this issue is not a concern. Importing your migrated FHX into a new v14 database before importing into your production system will allow you to export this v14 config and compare it to the migrated source FHX to find any differences the import process created. There will be some, but minimal. A pre import is highly recommended to check for these and other migration issues, especially from v7 to v14
  
  Do you have any FF IO on v7.4. These will need to be carefully managed, and I'm not sure if they need to be decommissioned and recommissioned into the v14 system. If they are not decommissioned off the v7 H1 cards, this may be one of those unexpected issues that delays restart of v7.4 process. You have to evaluate all the IO connected to ensure you know how to migrate the connected instrumentation. Conventional IO cards and bus cards like DeviceNet and Profibus are entirely configured in DeltaV so these should migrate well.
  
  Note that in addition to FHX import, you will also be copying your displays. You will need to careful not to overwrite any faceplates and detail displays as well as process displays or support displays that might have the same names. The migration utility does not migrate Operate GRF files and such.
  
  Finally, we have to look at your History. Are you using DVCH or ACH and is it the same in both systems? There is no utility to merge the history files. If the history is important for the v7.4 system and you need to have this available in DeltaV, you should force a new primary archive/dataset on your continuous historian and the Even Chronicle just before you bring the new configuration on line in v14. This will give you a known starting point for combined history collection. To restore history, you will need someone that can extract the history data from the two history server archives or data sets and merge them together. The only way I know this can be done is in the PI Archives, using PI archive tools and PI Databases. When Emerson released ACH, they provided a utility to convert DVCH to PI archives. With all the data converted to PI archives, the Archive tools would be able to extract a time frame from both sets of archives and merge them into a new archive and database for that data. If the v14 system uses ACH, we may be able to simply install these new archives. Note that the PI Database in the v14 system would need to be used so the indexes of the v7.4 tags in these converted archives match the downloaded system. I have no idea if anyone has done this. If the v14 system is using DVCH, a utility released in v7.4 allowed PI Archives to be converted to DVCH. Running this utility on the converged/complete PI archives would all these datasets to be converted to extended and replace the datasets in the v14 DVCH. This is a major effort.
  
  An alternative approach is to maintain a second Historian for the v7.4 tags. This would allow the history for the v7.4 modules to be migrated into the v14 system. The Operators would need to set PHV to this server to view this history. Overtime, all the history would be in the main historian. This is another reason you may want to consolidate the systems so that you have the extra App station license and history tags. If the v7.4 process can do without History prior to the migration date, that saves you a lot of misery.
  
  Emerson offers migration services, with engineers that have done many migrations covering all versions of DeltaV. version updates like this from v7 to v14 are perfect for unforeseen issues. It all depends on your risk tolerance and financial consequences caused by process disruption. I recommend you seriously recommend you involve someone with experience in migrations. You will do this once with very much effort, and unpredictable outcome. At least get a consult with assistance to review your execution plan. above all, you want to protect the V14 system. Maybe all you need is some testing ahead of time so you know what to expect and how to address it at crunch time.
  
  Robert's steps are correct, but the devil is in the details, especially merging into a functioning system.
  
  Good luck.

  Andre Dicaire

  • Cancel
• Robert Rijnders

  

  • 24 Dec 2025 3:03 PM

  In reply to Andre Dicaire:

  Wow, Andre's thorough post indeed covers most of the aspects of migrating and merging 2 systems. I didn't have time to write such a lengthy reply as I was looking for other information myself.
  To add to the story. With every system upgrade Emerson offers to 'upgrade' the GRF files for a hefty fee. In practice all they do is open a picture, compile the VBA script and close the picture. During closing the picture is scanned for common configuration errors like empty VB events. When asked to save the display, select yes and the display is 'upgraded' to v14. This is an easy job that you can do by yourself. Running the DumpDataSources tool will also scan for these problems and more issues like unbound animations and duplicate object names.
  
  I assumed VCAT wasn't used and as far as I know VCAT databases cannot be merged.
  
  If historian data is important. Years ago we merged 2 systems where we converted the legacy archives to DVCH. Now on the network we have 1 historian collecting new data and 1 inactive historian used for accessing old data (for gmp purposes.) Not ideal but it works.
  In your case you could keep your v7 system running to access old trend data and collect new data on the v14 system. Or export all raw data to text files to have a readable backup.

  • Cancel
• Robert Rijnders

  

  • 24 Dec 2025 3:16 PM

  In reply to Robert Rijnders:

  Since v16 release is around the corner, v14 will become unsupported soon. Consider merging and upgrading both systems to v16 and migrate all displays to DeltaV Live.

  • Cancel