Greetings. I'll start by saying that my responses to posts have been delayed recently. Not sure if it's something about being a new user, but they have to be approved by the moderator before they can post. So please be patient if I don't appear to respond to you right away.
The question is whether anyone out there has upgraded an old ERP (we have a very customized SXe from 30 years ago) from an old version of Progress (we have 10.0B) to a newer version?
If so, what was your ERP, what version did you go from and to, what hardware did you have before, and how did it go?
We're not in a position right now for an ERP upgrade or transition, but completing a database upgrade will get us off some aging hardware. Before we pull the trigger on that I'm interested in knowing whether there are things I should watch out for.
Thanks!
10.0B is old, but not 30 years old ;)
We have helped a bunch of customers upgrade SXe from older releases than that. The Progress & Database upgrade is relatively easy and straight-forward. The adventures along the way are all application related although with SXe they aren't too bad because you can compile the code and that gives you a lot of flexibility.
We see a lot of people moving from older HP, Solaris and AIX platforms to Linux and sometimes Windows. Basically, unless you have a very, very large system the case for "big iron" is getting very difficult to justify. HP and Solaris are pretty much dead ends. AIX is still viable and has a future but is hard to justify if you are not a bank or a multi-thousand user entity.
I don't want to turn this into a sales pitch but the biggest mistake that we see most people make is waiting too long to get help planning the migration. We end up fixing or working around a lot of problems that would have been completely avoided if the customer had involved us (or another qualified firm) to help in the planning and provisioning of a new system. So it is good that you are asking!
Your best friend in this process is to have a good history of the performance of your existing system. You can get that from us via ProTop http://protop.wss.com, free download here: demo.wss.com/download.php or from Progress' MDBA team and probably a few other places too. Such a history is invaluable in feeding a proper sizing exercise.
The number one thing to avoid is: vendor hype -- anything that sounds too good to be true probably is. "Hyper converged" is the snake-oil du jour. And, as always, storage and virtualization vendors are lying whenever their lips move.
If top-notch performance is your goal avoid virtualization and shared infrastructure (SAN or NAS). If you aren't focused on the ultimate in performance you can relax about that a bit but you still need to be careful. It is really easy to spend a ton of money on a SAN or VM solution and get really bad results.
There were some good talks on these topics at EMEA PUG Challenge last week and there will be more at the PUG Challenge Americas next week: pugchallenge.org/index.html Plus you get to talk to a bunch of people who have done these sorts of things and know all about them. I'd drop everything and get to Nashua next week if I wanted to get the best info hot off the presses :)
And, you could meet Tom as well!
Hi,
In may this year, one of our customers was 6 openedge updates, and 5 major versions of our sottware, after not having changed anything on their system for 10 years (perhaps a bit longer even).
Even the monitors where the same rectangle ones.
They have upgraded from on-premise installation of our ERP, to a Citrix published app hosted in a datacentre off-premise.
We have automated our entire build-street; every commit is incorporated automatically in daily "trunk"-builds. We release patch-versions every week, major versions every year (before every 2 or 3 years).
Installation is done automatically, so all we needed to do was type: install and a version-number. After an 4 - 6 hours or so the update was completed.
The biggest part was planning the down time. Finding out which "functional" conversions needed to be done. And we also ran into a few "bugs" which where introduced years ago but never reported :-)
We also did a "dry run" of the installation to flush out any problems, and measure all steps; around the moving of the database and setting up the new envrionment.
Planning = key
Hi,
In may this year, one of our customers was 6 openedge updates, and 5 major versions of our sottware, after not having changed anything on their system for 10 years (perhaps a bit longer even).
Even the monitors where the same rectangle ones.
They have upgraded from on-premise installation of our ERP, to a Citrix published app hosted in a datacentre off-premise.
We have automated our entire build-street; every commit is incorporated automatically in daily "trunk"-builds. We release patch-versions every week, major versions every year (before every 2 or 3 years).
Installation is done automatically, so all we needed to do was type: install and a version-number. After an 4 - 6 hours or so the update was completed.
The biggest part was planning the down time. Finding out which "functional" conversions needed to be done. And we also ran into a few "bugs" which where introduced years ago but never reported :-)
We also did a "dry run" of the installation to flush out any problems, and measure all steps; around the moving of the database and setting up the new envrionment.
Planning = key
Thanks [mention:dc2ff39fa15940708b78017f1194db6a:e9ed411860ed4f2ba0265705b8793d05] (love the username!) and [mention:ce4312d1e00542be918fe616c695a5de:e9ed411860ed4f2ba0265705b8793d05].
Currently we've got a vendor who's able to do the transition, who's been monitoring our performance for a while. They've put us in touch with a client who's undergone a transition kind-of like ours. But they also mentioned that a TUG post might elicit some more examples.
It sounds like a transition is possible, and that spending some time making sure that the folks who do the transition understand our performance and development history is the key. Is that accurate?
Yes I'm aware that 10.0B isn't 30 years old. Nobody is around who remembers, but it seems likely to me that the original SXe was transitioned from an even-older version of Progress at some point to 10.0B.
Yes, that is accurate. Making sure you have a good plan is key -- and the foundation for a good plan is a clear understanding of your baseline.
10.0B smells like something that was upgraded from v9. Just guessing but... are you currently on AIX? As I recall 10.0B was the first release of OpenEdge on AIX that supported 64 bits and quite a few SXe customers upgraded at that point. (Some apparently never upgraded again...)