My boss is asking me if he can communicate with some folks from this blog who experienced a recent upgrade process to 10.2. This is our first upgrade and he wants to discuss about what went wrong, if it did, what pitfalls to avoid etc…
I mentionned him some issues reported on this blog. but he really wants to have a one on one. (via email or phone)
So who’s up to it?
Just PM me your coordonates so i can provide to him.
I had just done 2 Upgrades to 10.2.300 in the past couple of months, so I will say this:
1.) Not properly identifying all the Custom reports being used. To an end-user, they are used to just doing their job and seeing the same things day after day. For example, something like printing the A/R Invoice. It was asked by management to address ANY custom reports in-use and make sure EVERYONE do their testing in the TEST system, well since “A/R Invoice” was the default option seemed logical to the people printing invoices it didn’t occur to them that the “Standard SSRS” was really the un-modified version and “A/R Invoice” was in-fact customized. No one tested this in the Test system and only after the Upgrade that “A/R Invoice” was in-fact heavily modified! Quite a bit of this actually went on. Lack of testing and finding out there were other reports not fixed during the test upgrade.
2.) Not testing import/exporting of the data out of the system.
3.) In general, specific areas of the business simply not doing any “testing” in the Test system and only finding out things were not working AFTER Production was “live”.
Basically, end-users will put “testing” on their lowest priority since they are busy. They might even “fib” and say they did do testing just assuming everything has worked fine for years, so it will continue working the same.
Also, don’t assume *newer" is better. Epicor Development is notorious for fixing some things and breaking some other things that worked for years. So in reality, there will be unforeseen problems that won’t be uncovered until the users start using the system.
I tried… but management made the upgrade date too close to Insights…so I could not make myself (at least) available…because of the after upgrade issues where I would certainly be busy at repairing what is not working and we did not think of prior…
i guess it will be for next time…
Just a note:
I wonder if Epicor thought about it…if not (actually I do not know how those decisions are made…) I may suggest to change it’s venue to Montreal Canada, or even Quebec city where it would be probably much cheaper to attend (just because of conversion rate…to start… ) Food is great and there is lots to do as a nightlife if needed…
going through all (over 100 ) customizations and modify them in 10.2, save them into a folder ready to be imported back in on Dday.
test and modify reports and if needed modify them and save them.
involve all responsible peaple from all departments to test the 10.2, creating a test script representing 90% of their daily tasks. These scripts are run with a one of our IT guys, in a closed env. conference room) so they are not disturbed… making sure they do spent time on it.
So far so good…but some departments are not yet confirmed… but will be soon.
This week end we will make a try run on the upgrade to see if we are comfortable to proceed on Dday…
I’d be interested to see how you get on as we are on 10.0.7.4. Without knowing you business or processes and how many modifications/bpm’s/baqs/custom reports you have, thinking how I would do this and with the comments by Thomas you could you do the following
Get the required folks in a room and flow your end to end process through various real world scenarios in your current and your upgraded system (mini conference room pilot) including any reports/output and any bpm actions/stops
You or the IT function to document all bpm’s, baq’s, custom reports on the system if you do not already have formal change control processes/documentation and identify an owner (can be as simple as who originally requested)- check/convert each and every one of them and get the owner to sign off
Create a DR/contingency plan for what happens if the upgrade goes south either during the upgrade process or it becomes obvious something is wrong and the business is broken in the immediate aftermath.
This is important to you and the business. I don’t know your company culture but based on the many arrows I have in my back from ERP upgrades, it may be that the only way to guarantee that adequate testing is done is to make time and be a nuisance and actually work one on one with the end user/users to test their functions.