Upgrade 8.0 to 8.10 Questions

bradbeckett1

Active Member
Hello all,

We’ve been trying to ascertain the issues and advantages of upgrading from 8.0 to 8.10.

1) Custom Coding: We have several custom applications (with lots of tables) and many custom financial reports (unorthodox COA prevented us from using most vanilla financial reports). It is my understanding that custom objects will upgrade from 8.0 to 8.10 without rewriting of code. I am aware that any JDE object that has been modified will need modified again, I’m more concerned with completely custom applications and reports. Our modifications to JDE objects is very limited.

2) Does anyone have or know of a documentation outlining the improvements in 8.10 vs 8.0. I have found documentation listing table upgrade etc, but not functionality change. I am specifically interested in 8.10 Job cost vs 8.0 Job cost.

3) Has anyone used the Z files for sales order importation or know if 8.10 differs from 8.0. We literally bring in 100s of sales order each day via custom code and the z files with the R4211Z

I’m not concerned with the CNC side of the upgrade, I’m sure I have a firm grasp on that portion including Unicode and it’s impact.

With it looking like Oracle is going to support XE/8.0 direct to Fusion finding reasons to upgrade are difficult, but the newer toolsets and sharing a common platform on the HTML code with the new releases semi interests us.

TIA
Brad Beckett
 
When you say "support xe/80 direct to fusion" I assume
you mean they will support the version until fusion is
fully available in 2013 not that there is a "direct"
upgrade path to fusion from xe/80 because there isn't.
 
[ QUOTE ]
When you say "support xe/80 direct to fusion" I assume<br>you mean they will support the version until fusion is<br>fully available in 2013 not that there is a "direct"<br>upgrade path to fusion from xe/80 because there isn't.<br><br><br>

[/ QUOTE ]

I have read differently, see this thread Intermediate upgrades won't be needed to move up to Fusion applications Are the details listed here inaccurate?

Oracle Lowers Upgrade Hurdle For Some PeopleSoft And J.D. Edwards App Users Sept. 21, 2005

Intermediate upgrades won't be needed to move up to Fusion applications.
By Charles Babcock
InformationWeek

Users of some PeopleSoft and J.D. Edwards applications will have a direct upgrade path to Oracle's future Fusion applications instead of having to upgrade to non-Fusion releases of Oracle applications first, according to John Wookey, Oracle senior VP for applications.
Wookey said users of PeopleSoft Enterprise 8.8 and users of J.D. Edwards EnterpriseOne XE 8.0 wouldn't need to make any intermediate upgrades, if they choose not to, to get to the Fusion Project's redesigned Java applications that Oracle is planning to issue in 2007 and 2008.
 
I think you are probably reading it correctly. However I don't take too much stock in the word upgrade. Realistically whatever Fusion becomes the move from EnterpriseOne, Enterprise and probably for that matter Oracle apps will be a migration and not an upgrade. My money is on a series of data conversion tools (similar to the World to E1 Direct Migration tools). There is simply no way that 3 different ERP systems can be upgraded into a new system. More precisely I don't think it is possible to create the tools necessary to allow for upgrades by 2007/2008. This won't be a process of retrofitting your customisations. If you want/need them you will need to develop them again using the Fusion toolset.

I say believe the hype in that Oracle is serious about retaining you as a customer. As such they are going to keep supporting you as long as it is profitable. I say don't believe the hype when it comes to the concept of an upgrade to Fusion or how the service oriented architecture is going to allow you to upgrade (migrate) to Fusion in pieces. Fusion will be a new product that you will ultimately need to migrate to, whether that migration be in pieces or big-bang.

Just my few cents ...
 
I 100% agree with you, it's going to be a migration not an upgrade.

But with that in mind I don't think a migration for 8.11/8.12 is going to be any easier than a migration from 8.0. You're still going to be 'converting' data from one ERP system to another. I am leaning towards staying on 8.0 now that Oracle has said they are going to create the upgrade/conversion/migration for 8.0 as well as 8.11/8.12.

If Oracle wasn't going to create the upgrade/conversion/migration for 8.0 then an upgrade from 8.0 to 8.1x would be 100% needed.

Which is why I was curious about the upgrade of custom code and batch version as well as what's new in Job Cost. Job cost is a big down fall for us in 8.0, if 8.10 is superior that alone might be worth the upgrade.
 
Brad

I worked on an XE to E810 upgrade for over a year. I had 95% of the custom modification re-coded when we decided to abandon our upgrade. The only reason we were upgrading in the first place was the sunset of support for XE. When it was announced that XE would be supported until 2013 we decided to stay on XE. We are a government entity and found no new functionality that would warrant the move to E810. Also there are many negative in our mind to E810.

1. Unicode. We were not going to upgrade our data so performance would most like take a hit.

2. Solution Explorer. We would have to re-train all users on this new front end.

3. Support ends in 2010, XE in 2013.

For us it was a no brainer to stop the upgrade. As for your upgrade new functionality would be the main reason to move forward. That's my two cents.

Patty
 
Hear, hear!

(for non-native english speakers this short phrase means: Yes, we agree, we approve, well said ...)
 
[ QUOTE ]
Brad

I worked on an XE to E810 upgrade for over a year. I had 95% of the custom modification re-coded when we decided to abandon our upgrade. The only reason we were upgrading in the first place was the sunset of support for XE. When it was announced that XE would be supported until 2013 we decided to stay on XE. We are a government entity and found no new functionality that would warrant the move to E810. Also there are many negative in our mind to E810.

1. Unicode. We were not going to upgrade our data so performance would most like take a hit.

2. Solution Explorer. We would have to re-train all users on this new front end.

3. Support ends in 2010, XE in 2013.

For us it was a no brainer to stop the upgrade. As for your upgrade new functionality would be the main reason to move forward. That's my two cents.

Patty

[/ QUOTE ]

I loaded standalone 8.10 to see how different Job Cost and Subcontractors are, I have people working on that now.

The remaining question I still have is about the upgrade process. Specifically how custom objects F55*, R55*, V55* and P55* are handled. I have never been involved in an upgrade so I don't know if these must be recoded, or if the objects will move over to the new version, and if so, how smoothly the move happens. <~ *** Can anyone please shed some light on this question?¿?

Unicode doesn’t scare me, I’ll have to add some hardware (drive space) for unicode but not a big deal. 8.0 included solution explorer and luckily we used it from day one. The support difference of 3 years matters, but I’m not sure how much. If fusion makes it out somewhere in 08, that gives them 2 years before we’d go live in 2010.

Thanks everyone...
Brad
 
System code 55 - 59 objects come through without alteration. Will you have to recode? Probably not for anything other than BSFN's, which will need to be looked at for unicode compatibility, and anything custom that might interact with other apps, etc. that might have changed in the upgrade. Just make sure all your merge flags are set correctly prior to running spec merge during the upgrade process. You'll be able to use the visual compare to compare your "55" objects to the out of box objects to see any new code or changes, if you've created custom objects from copies of the original.
 
[ QUOTE ]
System code 55 - 59 objects come through without alteration. Will you have to recode? Probably not for anything other than BSFN's, which will need to be looked at for unicode compatibility, and anything custom that might interact with other apps, etc. that might have changed in the upgrade. Just make sure all your merge flags are set correctly prior to running spec merge during the upgrade process. You'll be able to use the visual compare to compare your "55" objects to the out of box objects to see any new code or changes, if you've created custom objects from copies of the original.

[/ QUOTE ]

Thank you,
This is the specific answer I was seeking.
 
Hello there,

I've been working on the upgrade from Xe to 8.10 for almost a year now. The upgrade should have taken 3-4 months, however, it's more like an all-over upheaval than an upgrade.

I personally wish we had stayed with Xe as well, but we've come this far with the upgrade...no point in going back.
 
Back
Top