I must admit that even though I’m not the biggest fan when it comes to upgrading to the latest and greatest versions out there (we typically advise our clients to hold off on upgrading until both Esri and Schneider Electric have released at least one service pack to their initial release), I would strongly recommend to our clients to avoid getting sentimentally attached to their current version and ignore upgrades for too long, for the following reasons:
- If there are any major issues in your current version and your version is obsolete, you will not get the appropriate support from the vendors
- Your end users will have a harder time adjusting to a greater number of changes. Rather than seeing those changes gradually, they will see them all suddenly.
- When you do finally upgrade, the process will take longer as you’ll likely need to hop couple of versions before you get to the desired one (i.e. From 9.2 you need to hop to 9.3 and then to 10.x). Effectively, you have to upgrade to each version incrementally anyway.
Recently we were lucky enough to work on an upgrade from 9.2 to 10.1 and I thought I would share the good, bad an ugly about our experience.
- We got our client on a more up-to-date version where they can benefit from new functionality, or even existing functionality where additional licensing are no longer required (an example of this is the Advanced Maplex labeling capabilities which are now included at all ArcGIS for Desktop license levels).
- They will get better support from Esri and Schneider Electric as their version is no longer obsolete.
I wouldn’t say “bad” but it certainly gave us some challenges in the following areas:
- Custom Code- Our client had a fairly decent amount of custom code (25 solutions, 69 projects, 924 classes, 12 installers) and with the COM registration changes at 10.x, this presented a challenge:
- For each co-class that implemented an Esri or Schneider Electric interface, we added the new .Net attribute ([ComponentCategory(ComCategory.X)]) to the top of the class (there were about 175 classes touched)
- Updated/modified code where the interfaces were marked as obsolete. In some cases it required to re-write certain functions.
- Updated installers accordingly so that dlls can get the customization registered with ArcMap.
- Testing - When doing such a big jump (9.2 to 10.1) I would recommend allocating a fairly decent amount of time for testing, especially when there is a large amount of customizations. I could not emphasize this enough. Take the time to test as thoroughly as you possibly can; this will minimize any bugs/defects once you roll out to production.
- User Experience - The user experience is always 50/50, some users love it and others hate it.
The lovers will immediately provide feedback about the application; we will hear the good, the bad and their wish list as well. They start to see ways to improve current workflows and even the possibility of adding new functionality right away. Sometimes we have to slow down their horses a bit as we want to roll out the upgrade first and then we can work on their “wish list”.
The haters…well…some will just hate the application from the moment they heard a “change is on the way”. These users are hard to please because they are so used to doing things in a certain way that any sort of change will affect their daily routines. They may not like the new layout, the buttons, the font - you name it - but with proper training and patience, most users come around eventually and join the lovers group.
Well…partially at least.
- Performance - Most clients that have upgraded to 10.x have noticed a significant drop in performance, unfortunately. The Esri user forums include a lot of posting on the general concern “Desktop ArcGIS 10 Really Slow”. We are as frustrated as our customers are and there is not much that can be done to address these concerns except hope that our partners at Esri and Schneider Electric will focus on performance more when releasing new versions.
As much as Esri and Schneider Electric test their software before they release a new version, there will always be some sort of exception that they didn’t account for which will result in a bug/defect. After all, not all utilities have the same data model. We have run across few defects in our upgrade and wanted to share those with you.
- Bugs - These are the following defects we encountered during the upgrade:
- Multiversion Views – For some odd reason, when a version posted its edits to default, the multiversion views did not display the new edits right away. We ended up dropping the “Multiversion Views” (i.e. Table_MV) and created what is now called “Versioned Views” (i.e. Table_VW).
After doing this, everything worked as it expected. We of course had to update any references in the code to the multiversion views and replace it with the versioned views, as the suffix had changed.
- Abandon Settings – If you use abandon functionality from Schneider Electric, you will notice that the Abandon Settings are not persisted on the Abandon Info tab. Do not panic, the settings are saved correctly and they just don’t display correctly. Schneider Electric released a patch for 10.1 (ArcFM™ Solution 10.1 Patch #330)
- Geodatabase Manager™ – We found out that Geodatabase Manager™ was allowing posts of versions with QAQC errors. The client had a validation rule configured on their Network Junction feature that was never being executed.
The first assessment was that GDBM did not appear to detect validation rules for feature classes without a subtype; the problem did not appear specific to the Network Junctions. Schneider Electric released what appeared to be a related patch at 10.1 (ArcFM™ Solution 10.1 Patch # 334), but that was not it. The client continued to have sessions with errors posted to default.
The second assessment was that the Network Junctions were excluded from running validation rules due to potential performance implications. A second patch was released (ArcFM™ Solution 10.1 Patch #335) that addressed this problem.
- Hard-coding – This is probably more of a less-than-ideal coding practice, but we ran across many hard-coded connection strings in the code, among other things. Typically, we think anything that can change and is used in the code should be placed in a config file. Perhaps more frequent code reviews could minimize these sorts of issues.
We hope you find this article helpful and that will minimize the headaches we went through. If you have any questions or need assistance do not hesitate to contact us. Good luck with your upgrades!