Upgrading form 8.10 to 9.1


We are planning an upgrade from 8.10 to 9.1 as well as upgrading our servers and SQL. Currently we are running on Server 2000 and SQL 2000. Oracle is recommending we use a product called Goldengate to keep our new SQL 2014 database in Sync with with our production SQL 2000 database, so that we can attempt a zero downtime upgrade.

Just wondering if anyone has tried this, and if there are any alternatives to Oracle's Goldengate product?
Oracle does like to sell their software - and it sounds like they have an upgrade methodology that supports Goldengate. If so, then that IS one way to upgrade - but its not going to be cheap.

Theres quite a bit of information you left out in your request (ie, what tools release you're on, etc etc). And the following is a little open to lots of interpretation by peers about whether its "safe" or not. The thing is, you're on "ancient" software already - and you're trying to jump a bunch of versions with this upgrade - which is exactly why its always recommended to be no more than 5 years behind versions on your ERP system ! (sorry for the little dig there - but you DID save a ton of cash by NOT going through upgrades over the past 10 years !)

SO, your alternative would be to upgrade the OS and SQL Server to the most recently supported versions for your 8.10 install and THEN upgrade it to 9.1 and THEN perform a second OS and SQL Server upgrade to get current.

I was looking at the MTR document (Minimum Technical Requirements have been superseded with "certifications" for newer versions) - but there are historical documents out there that will help.

I checked some of the older documentation - and TECHNICALLY the last supported Tools Release for 8.10 is 8.98.1

According to Document ID 705411.1 - support for SQL 2008 x64 (not R2) began with JD Edwards EnterpriseOne 8.98.1 (Note that you will also have to implement a planner ESU to achieve this.)

According to the certification, 9.1.2 supports SQL 2008 x64 as well - so you have a path !

Theoretically, a tools release is not a big impact on an E1 system - but in reality it can dramatically change certain aspects of your functional code and integrations - so you WILL need to VERY THOROUGHLY test.

IF you manage to get 8.10 with 8.98.1 up and running, then upgrading the OS and database should not be too difficult (but might be time consuming - again, backup and test !)

Now, once you're running 8.10 on 8.98.1 tools against Win/SQL 2008 x64 - you're in a very good position, since 9.1 will support Microsoft SQL Server 2008 R2 and Windows 2008. You'll do your 8.10 to 9.1 upgrade on SQL 2008 and then some time later you can later upgrade your database to SQL 2014 and whatever OS version you want too.

You could try this on a simple sandbox environment (grab three workstations with some decent storage and make them a deployment server, enterprise server and development workstation). Install your 8.10 code onto it with your current TR, and then attempt the 8.98.1 Tools installation (should take a couple of days or so). If that works, then you've got over the "difficult" bit. You can then perform a Windows 2008/SQL 2008 upgrade (relatively simple), then perform the 9.1.2 upgrade (difficult), then when you've ensured everything is running, perform a Windows 2014/SQL 2014 upgrade. The entire process shouldn't take more than a week or two to test out on a sandbox.

NOW - my disclaimer is that the above doesn't help you with any custom code, external interfaces and all the other gubbins that the average implementation has. You might be able to upgrade E1 in that manner, but you might have issues with other software that E1 talks to.

Good luck to you ! I'll be very interested to hear if you manage to pull it off.
Last edited:
How are you planning to achieve a zero downtime upgrade? Are you intending to run Goldengate while you're running the upgrade scripts against your 8.10 database?

In response to your question about anyone trying, I seriously doubt it but like Jon I have a morbid curiosity to see what the outcome is.
To answer your question, this has been done before with one of our customers and it worked good. Replicating using GG will help you reduce your downtime.

was that a customer using finance modules only? No customizations? Hard to imagine this going smoothly for a large implementation.
I have heard of customers using Golden Gate to perform an upgrade. It sits between the versions and the database to allow each of the versions some sort of "co-existence". Having to go through and map every data-point in the system is just a huge task especially with very modified customers, and then trying to push the users off the old system results in huge resistance. Some of the big consulting organizations offer this and promise "zero downtime" - but the reality is that either you go through a traditional upgrade (and use a weekends worth of downtime to switch users across in a big-bang) - or you spend many factors more trying to get this "co-existence" working over a MUCH longer time period.

Personally, I don't know any company that can't survive a 48 or 24 hour downtime for their ERP system. I don't believe that you'd be able to HONESTLY sell a customer the justification based on the cost difference between the two upgrade types.

If I am wrong, then please, disclose more information - but the GG 8.10 and 8.11 upgrades I've heard of are in the millions of dollars, and require the customer to implement NO changes while the "co-existence" occurs - which results in negative ROI.
Negative on that Larry. They were not just using Financials and there were customization's too. This was done about 2 years back. I do not think customization plays a role here (Unless I understood you wrong). Remember - in most cases we are just bringing the data and control tables during the go live weekend.

Jon - Its not really co-existence. The customer wanted minimal downtime and there were no two ways around it.
"Having to go through and map every data-point in the system is just a huge task especially with very modified customers"

Well, actually it wasn't that bad (although it's a big task indeed)

First you run standard Table conversion on a sandbox and identify list of modified (converted) tables between releases that are applicable to your specific install.

In reality there probably will be couple hundred tables (with data) that changed between 8.10>9.1 and that are actually used. Absolutely vast majority of them will only have extra fields. (its very easy to accommodate)
Next step is to modify Golden Gate replication script so they change data in modified tables (popilate new fields essentially) "on-the-fly" during data replication.
Once that is in place and you establish real-time synchronization between 8.10 and 9.1 DBs (it may take few days to catch up for big Database), you have two different JDE releases running on two different databases with current data in both.

You still may need to run few manual steps (including integrity check) during actual cut-over (and i guess there could be some table conversions that are not easily scripted in Golden Gate) , but essentially goLive consist of flipping JDE URL to point to new 9.1 Web Servers

Its not "Absolute Zero" Downtime", but about 2-3 hours even for heavily customized client with terabytes of PD data and all modules used (that's actual real life info)
Last edited:

was that a customer using finance modules only? No customizations? Hard to imagine this going smoothly for a large implementation.

practically all modules and heavy customization. there were issues of course, but goldengate part was relatively smooth..