TN - HC - 26050802 Repairing Migrated aaTrend Files
Last updated: May 18th, 2026Description
- Author: James Rochester
- Published: May 18th, 2026
Details:
- Document Version: 001
- Applies to Version(s): 2023 +
Description
This Technote discusses the necessary steps to repair Trend files migrated from older versions of Historian to 2023+ Historian versions. There is a new field “TypeAsTagType” in the aaTrend file in the 2023 version of Historian. Since this field did not exist previously it does not get auto populated and leads to the Trend files failing to load the data.
Solution Details
Solution Steps:
In order to avoid having to manually correct the tag type for each individual tag saved in the aaTrend file you must perform the following:
1. Back up and remove Servers.xml in file C:\Users\<Loginuser>\AppData\Local\Wonderware\ActiveFactory.
2. Open a older version aaTrend file on the 2023 Historian Server using notepad and update the Historian Server name with the name of the newly migrated to Historian Server using Find and Replace All.
3. Launch Historian Trend and open the modified Trend file. After this a new Server.xml file will be generated with the correct TagType designation and the Trend will display the data successfully.
______________________________________________________________________________________________
Give feedback about this article
Recommended articles
[ISS Support Case] Missing Historian Data after Migration
Running TN1047 caused some issues. I suspect it's because I moved history blocks around while migrating. I have a flatline in InSight during the time I had the Historian down, and now I have an unstoppable flood of warnings in the OCMC on the Historian. Any idea how I can fix that?
Read More[ISS Support Case] Historian 2020 Data Gaps Post Migration
Historian 2014 R2 SP1 got a new server Historian 2020 R2 P01 everything is talking to the tag server used tag import export to import tags to new historian updated IDAS moved circular files there are data gaps of a day here and there but on the 2017 system they are not present.
Read More[ISS Support Case] Log storage
We are requesting support for an issue encountered after upgrading our AVEVA Plant SCADA system from version 7.5 to 8.5 (Update 10). In our current Citect 7.5 environment, we have alarms and logs configured in the devices.dbf file (configured in Plant SCADA Studio ? Setup ? Devices tab). For example, we have a log set to generate a text file whenever a user acknowledges all alarms by pressing a button on a screen. In version 7.5, these alarm and log files are successfully written to a single server file location, allowing all user actions from any client or server machine to be consolidated in one place. After the upgrade to Plant SCADA 8.5 Update 10, the behavior has changed: each machine (server or client) now stores changes made by users locally, rather than writing to a centralized server location. This requires setting up log and alarm folders on each client and server individually, then periodically backing them up or merging the files manually. This process is inefficient and time-consuming compared to our previous centralized setup. Request: Is there a workaround or configuration option that would allow devices.dbf to function in the same way it did in Citect 7.5logging user actions from all machines into a single server-based file locationrather than maintaining separate local copies on each machine?
Read More