# Modified tags are moved within tag files after any change **URL:** \ **Category:** Ignition\ **Tags:** ignition83\ **Created:** [March 12, 2026, 12:27pm UTC](https://forum.inductiveautomation.com/t/modified-tags-are-moved-within-tag-files-after-any-change/114461 "2026-03-12T12:27:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Eduardo\_Alves](https://avatars.discourse-cdn.com/v4/letter/e/53a042/32.png) [@Eduardo\_Alves](https://forum.inductiveautomation.com/u/Eduardo_Alves)\ **Post date:** [March 12, 2026, 12:27pm UTC](https://forum.inductiveautomation.com/t/modified-tags-are-moved-within-tag-files-after-any-change/114461/1 "2026-03-12T12:27:23Z")
I am finally able to migrate our company’s project to **Ignition version 8.3**. However, even in the test environment, I encountered a major disappointment regarding the **versioning of tag files**. Our tag organization is based on **dozens of folders**. During the initial conversion, all tags remained properly organized, with no apparent issues. However, when I needed to apply a modification using **import with overwrite** , I noticed that the modified tags were **moved to the top of the file**. This behavior causes a significant displacement within the file, leading source control diff tools to interpret the change as **line removals in one section and additions in another** , rather than a simple modification. This greatly complicates version control and code review. In the image below, I modified only the `enabled` property of a single, simple tag, yet nearly the entire file is reported as changed. Is this behavior expected or known? If not (and I truly hope it is not), my suggestion would be to always rebuild or export tag files maintaining an order based on the **`name` attribute** , ensuring more stable and predictable versioning. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/1/a18874895f07eff0e351d0cbab4c3e3e322b7985.png) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 12, 2026, 12:38pm UTC](https://forum.inductiveautomation.com/t/modified-tags-are-moved-within-tag-files-after-any-change/114461/2 "2026-03-12T12:38:26Z")
Longstanding gripe. JSON is not specified to use ordering of any kind, so all of the common tooling produces non-deterministic output. ☹ More here: > [@Script JSON Format](https://forum.inductiveautomation.com/t/script-json-format/90434/5): > > I do think IA should route all JSONification through instances of TreeMap with a human- and source-control-friendly case-sensitive [alphanumeric comparator](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.38/com/inductiveautomation/ignition/common/util/Comparators.html) for the keys. Perhaps with an performance exception for payloads going straight to the browser. Especially including [system.util.jsonEncode()](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions/system-util/system-util-jsonEncode). So that all json that ends up on disk (including json from document or other tags) is deterministic. The JSON spec may not care about key order, but lots of other dependent functionality does. and here: > [@Json Diffing Discussion](https://forum.inductiveautomation.com/t/json-diffing-discussion/96800): > > FWIW, I made a script recently that achieves this with JSON tag exports, and could be tweaked for many other cases (currently uses the "name" key for sorting lists of dictionaries). # Functions designed to be called via objectScript() in UI expressions. from java.io import File from java.lang import System, Throwable from java.util import TreeMap from com.inductiveautomation.ignition.common.util import Comparators logger = system.util.getLogger(system.util.getProjectName() + '.' + system.ref… JSON is not compatible with source control/diff without deliberate effort, that IA is failing at. ---
**Author:** ![Eduardo\_Alves](https://avatars.discourse-cdn.com/v4/letter/e/53a042/32.png) [@Eduardo\_Alves](https://forum.inductiveautomation.com/u/Eduardo_Alves)\ **Post date:** [March 12, 2026, 12:53pm UTC](https://forum.inductiveautomation.com/t/modified-tags-are-moved-within-tag-files-after-any-change/114461/3 "2026-03-12T12:53:13Z")
For this project, I needed to migrate tags from a legacy system. To support this, I built a **Python script repository** and decided to keep the generated **JSON output versioned within the same project**. This approach made it easy to clearly see exactly what changed with each modification to the code. The project contains **approximately 500,000 tags** , so I organized them by **UDT types** and applied a simple and consistent rule set: - Tags are ordered by the `name` attribute. - Within each tag object, all attributes are ordered **alphabetically**. This structure was implemented **prior to Ignition 8.3** and worked extremely well. Version control diffs were always clean, predictable, and easy to review — it truly felt like a _“put words together and make it fun”_ experience. I honestly don’t understand the difficulty of implementing something like this. I am **extremely disappointed**. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [March 12, 2026, 12:56pm UTC](https://forum.inductiveautomation.com/t/modified-tags-are-moved-within-tag-files-after-any-change/114461/4 "2026-03-12T12:56:38Z")
> [@Eduardo\_Alves](#): > > a simple and consistent rule set Yes, I've been advocating for that rule set (tweaked to use human-style alphanumeric sorting of dictionary keys). v8.3's tag storage by folders is better than v8.1's json exports, but still doesn't hit the mark.