Another article on our upgrade

After writing the two articles for OAUG Insight about our upgrade to release 12 I was contacted by SearchOracle.com to see if I would be willing to write a similar high level summary for their website. Well, that summary is finished and can be found HERE. It is basically just the process we went through to upgrade our system to release 12. If you have any specific questions about that process feel free to contact me (I'll respond to any comments I see on this post).

Our Upgrade Story

This past year I was contacted by the publisher of OAUG Insight magazine and was asked if I would be willing to write an article about our experience upgrading from 11.5.10 to R12. My original article was to long and so the editor asked if we could split it into two parts. Part one covers how USANA went about upgrading to Release12 and part two details some of the functional issues to watch out for after migrating.

Part One: Page 18

Part Two: Page 15

(Upgrade + Interfaces) = (Potato Chips + Bubble Gum)

Well, we have been live on R12.1 for a full month now. We made it through our first month end and now we are days away from closing out the year. While no upgrade is void of significant issues I would have to say ours has played out better than I could have hoped. Really, from an operations standpoint, the only major issues we had were getting our custom interfaces to work properly (which brings me to the topic of this post).

My new personal opinion is that (Upgrade + Interfaces) = (Potato Chips + Bubble Gum). What I mean is that the upgrade by itself is a very good thing and our custom interfaces by themselves really are superb but when you combine them together its like chewing bubble gum while eating potato chips, they just don't go well together.

We have three major interfaces that we maintain, all on the operations side. Two of the three interfaces were created to link a third party solution into oracle applications. In those two cases we were only able to test that information was put into and taken out of the interface tables the same way it was before the migration. As much as you try and replicate these interfaces without being able to test the process all the way through from beginning to end it becomes very difficult to verify that your solution will process correctly post upgrade. To complicate matters even more, our two third parties didn't have test instances available in which we could validate our code pre migraiton.

Here we are now, four weeks later and we are hoping that we've gotten the last 'glitch' resolved with our interfaces. It's been a hectic and very busy month essentially 'testing' our updated code in our production instance but we might finally be on our way to wrapping things up.

The lesson learned: things are sure easier when you don't have custom interfaces. To me it drives home the idea that its better to have a single fully integrated ERP system then it is to have a multiple systems trying to interface with each other. Granted, the price is very different between the cost of those two solutions unless you add in the cost of hiring developers to maintain and constantly monitor your code. For me, I'm taking the integrated system any day of the week.

The Calm Before the Storm

We are officially two weeks away from taking our production instance down and migrating from 11.5.10 to 12.1. You'd think I'd be swamped with problems and issues from every which department, but as of today the only thing I have to work on is documentation (training and validation), and rewriting reports. --Sadly our discoverer reports aren't going to migrate so well since they were built on OPM inventory views.

My mind is going about 2,000 mph trying to see if I've missed any testing or any possible business process that might be affected by the upgrade but so far things look good. I wish I had a little more 'stress free' free time so I could update this blog with things I've learned during the upgrade but I think those entries are going to have to come later.

I will however make a small list of things to consider during your upgrade

• Discoverer reports/workbooks don't migrate, at least that is what Oracle consulting told us. If you are using discoverer before the migration you're going to have to recreate your workbooks after the migration (assuming those workbooks are built on views that get changed during upgrade)
  
• In OPM users are forced to choose an existing lot number when performing move immediates and adjust immediates. In 12.1 users are not forced to choose existing lots. They can enter a new lot any time (subinventory transfers, account alias transactions, inter-org transfers)
  
• This one is random but in 11.5.10 we had routings setup which had resources with a usage of 0. In 12.1 if you have a primary resource assigned to a routing and that primary resource has a usage of 0 then when you run collections, the Recipe which uses that routing will not be collected and it will not show demand for that product/raw materials
  

Those are just a few thoughts, hopefully they might help you out during your upgrade. Well, I have more reports to rewrite, wish me luck.