We upgraded our ERP system about six weeks ago. This was one of the worst upgrades that we have ever went through. During the testing we didn’t uncover any real problems; however once we went live everything went to hell. The upgrade was from Fourth Shift 7.4 running on MS SQL Server 2000 to Fourth Shift 7.5 running on MS SQL 2005.
The first main part of the upgrade was the installation of MS SQL 2005. This part went pretty quick and easy. After uninstalling SQL 2000 and installing SQL 2005 sp2; we reattached all our databases and tested the applications that were attaching to them. There were some problems with security setting not coming back correctly, but they were fixed without any trouble. I really feel that SQL 2005 is a step back from SQL 2000. In our sandbox we are using SQL 2008 which is much better than 2000 or 2005. I can’t wait for our ERP system to start supporting SQL 2008.
Next came the meat and potatoes of the upgrade, and that was Fourth Shift. The installation was very easy and well documented. It took about three hours from start to finish and we had a running system. We upgraded a couple of workstations after to make sure that the client would also install and run. We left the rest of the clients to be updated for the next day. We only have twenty users on the system and them come in in the morning over a two hour period, so we can pretty much update the clients as the users are coming in.
The first two days after the upgrade it seemed that everything was running good. It took a couple of days to start seeing that some of the reports were not working correctly. The sales reports were not updating correctly. After digging around in the logs we couldn’t find anything. There were no error and the process that updates the sales reports was reporting that it was finishing without any errors. This is where SQL 2000 was much nicer. There is no EASY was to look at the steps is a SSIS package. It ended up being a problem with the upgrade problem. The report update package was installed on the server and was running fine, except for the part were none of the steps for the package were installed. We were issued a new licenses key file and had to reinstalled the upgrade over our current installation to get the reports working right. This ended up taking a week to get resolved.
Next came the first end of month. None of our data extracts that used the general ledger would run. It turns out that there was a problem with extracting GL data in the new version so they stopped supporting that feature of the program. They just didn’t bother to include that little nugget in the upgrade documentation. This works fine in a small databases, but once the extract gets over 750,000 records it quits working. Our sandbox was only a subset of our full production database. That may have to change going forward. The really cool part of all this is that they have a service to convert your extracts to DTS packages that can be run directly form SQL Server. The DTS packages run much faster then using the extract function within the ERP system. The only problem with it is that they charge $3500 for the first extract and $200 for each additional extract. We have 225 extracts that are used by the accounting department. That works out to over $48,000 for them to fix something that they broke. Not a bad racket if you can get it. It took almost three weeks for us to recreate the primary extracts to DTS packages. We still have a canned report that Fourth Shift generates that is not working. We have had a open case on this item for six weeks now. (Update) On July 14 we received a fix for one of the open issues. It was eight weeks to fix a sorting problem in a report.
Last night was the second end of month since the system went in. Everything seems to have run fine so I guess we are getting all the kinks worked out. The other thing that has happen during all of this is that our ERP vendor, was purchased by a second software company and a holding company. That is usually not a good sign and may explain why we have had a outstanding action with them for six weeks on a report that they can reproduce the error on.