We need better SysAdmin documentation (ECM idea)

I created an idea because last night we had to surprise upgrade our ECM instance after support told us months ago it would work with the Kinetic version we were targeting and it ended up it did NOT work. Beyond the frustration of having to upgrade ECM so our AP team could get back up and running when we never intended to do such a thing, I had a heck of a time getting information about how to upgrade ECM at all. Support basically said “run the exe, it’ll be fine” but we are a med tech company - we have a few more change management requirements than that.

Anyway, I hope I’m not the only SysAdmin out there who would love to see ECM and IDC end up with better documentation. Kinetic has fanastic information regarding how and when to upgrade and what needs to be checked before and after to confirm things are good to go. They even have a full “sysadmin tech reference” for Kinetic, something I use often in support of our environment. ECM needs the same treatment. We shouldn’t have to open a ticket just to find out how to upgrade or what the system requirements are for the new version of ECM.

If I’m not a lone duck on this one, I hope you will all consider voting for this.

https://epicor-manufacturing.ideas.aha.io/ideas/ECM-I-1277

3 Likes

Voted and Agree. The current docs - there are some good ones out there, but they need updating for sure.

I can tell you that a group of us has been working with the product management team over the last couple of years and have brought this up before. the biggest distraction for them lately has been getting the code base to a consistent level with Kinetic and the integrations into other Epicor products. But they promised they’d work on the docs.

Interestingly enough, I tried an upgrade on Tuesday in my Dev system and got a new error that got passed the Dev team during QA. I’m working with them now to see if any correction could be done, but it stems from starting at a version back at 17.x and moving forward. Seems some legacy stuff get’s left behind and the 24.1 installed chokes all over it.

Would’ve been nice to read somewhere that “the new installer aggressively attempts to remove all legacy items not branded ‘Epicor’ to complete the transition to ‘ECM’”. That’s exactly how the support team put it.

2 Likes

@MikeGross Were you trying to go from 17 to 24? Or you originally were installed at 17 and are now going to 24?

There are some notes about going from Solr 7 to Solr 9 and needing a reindex after you click the download link.

the odd thing with the notes that you don’t see until you click the download is just those alone would be a good start to an install doc.

@pbrandvold Not that it helps you now since you have already done the impromptu upgrade, but I was able to continue using APv1 by installing another app server just for processing ECM with SOAP from 22.1.75 to Epicor 2021.2

I had a case and sent the notes on how to support when they asked for them.

1 Like

No, but yes. We started back at 17 and have progressed and are now trying to install 24.

Since we were Docstar customers from before Epicor bought them, we had stuff installed from way back when. It seems that the old “Imaging Support” files for the two OCR engines were never ‘dealt with’ in subsequent updates, and they were still branded under the Astria/Docstar names.

The current 24.1 install tries to remove them, but WinServer wants the original install files. I could get a few of the old installs, but then had to forcibly remove a few using a 3rd party uninstall utility. Once it’s all cleaned up, the 24.1 install works fine.

2 Likes