Panel members included Sandra Vucinic, Vlad Group, Inc., John Stouffer, Independent Consultant, Floyd Teter, JPL, Stephen Horgan, Oracle Corporation, Kyle Harris, Oracle Corporation, Mike Swing, TruTek, and Alyssa Johnson, Solution Beacon.

The Questions and Answers

What are the main decision points for upgrading versus reimplementing?

• If you are thinking of changing your accounting structure, you may have to reimplement. Reimplementing can offer a good opportunity to make changes to the accounting setup manager, subledger accounting, and the chart of accounts, and implement additional ledgers. Other reasons that might drive a reimplementation include if there is significant bad data in the existing environment, if the customer has lost their customization history, or company wide consolidations, mergers and acquisitions.
• The biggest issue with reimplementing is money. When you upgrade, you can expect to spend 20-25% of your original implementation costs. Reimplementation costs go way up; close to the original implementation costs. Floyd Teter suggested that if you can squeeze by with an upgrade, do the upgrade. If something dramatic has changed with the way you model your business, then reimplement. Floyd said that reimplementing versus upgrading was strictly a cost/benefit tradeoff. 

Do reimplementations take longer than upgrades?

Floyd said that reimplementation is always going to take longer. He suggested tacking on 40% to the schedule in terms of effort, but it could be even more, depending on your implementation.

If you haven't archived or purged your data in a very long time, and have a lot of historical data, how does that drive the implement versus upgrade decision? Can you update selected data?

• You should archive as much data as you can before your upgrade process starts.
• You can also bring over only the data you want, and use your Release 11i instance to reference historical data.
• You can use Oracle's Upgrade by Request process to pick and choose how much data to bring over. Oracle provides a lot of flexibility, but you have to time it and make sure it makes sense. With SLA there is a pre-upgrade patch that lets you control how much of the data you upgrade. If you have 10 million debits and credits, they will all get updated, but you can use Upgrade by Request to update some now and the rest later. You can upgrade the last fiscal year of your data, and it will ensure you have at least 6 months worth of data when you go live.  

Are there any lessons learned from upgrading?

• The technological architecture changes, along with E-Business Tax, SLA and TCA caused a big increase in size with Release 12. TCA alone went from 30 tables to 300. You should expect to need an additional 20-25% of disk space for Release 12.
• With the original upgrade to Release 12, AP changed considerably and there were a number of functionality issues that came up. AP is in much better shape since Release 12.0.4, although 12.0.6, the most current release, is also the terminal release for 12.0.x. Performance has improved and there are less errors. Oracle has a proactive information center on My Oracle Support that has information about AP. In many cases, you can find solutions without even logging an SR. AP in Release 12.1.2 is as stable as the other subledger modules.   

How does customization impact the decision to reimplement or upgrade?

The consensus was that customization impacts need to be dealt with for both reimplementing and upgrading, and that customizations shouldn't have more impact on one method over another. For both reimplementing and upgrading, customers should consider the following:

• No matter what you decide, those customizations are in your business now because they serve a purpose and are addressing business needs. From that point of view, you need to decide whether the business process gap is still there or not. You need to figure this out whether you plan to upgrade or reimplement. The good news is that sometimes customers have been able to eliminate customizations thanks to new features in Release 12.
• You should catalog your customizations. You should know why you put those customizations in and map it to Release 12 functionality to see which customizations you can retire, and then retire what you can. By doing this groundwork, your upgrade or reimplementation will be that much easier.
• Oracle Consulting offers in its Advanced Customer Services a CEMLI Catalog Service that provides an inventory of your CEMLIs (Configuration/Customization, Extension, Modification, Localization, and Integration). These are scripts, and don't appear to be generally available except through Oracle Consulting. But they sounded like they would be quite handy. You can read more about them at http://www.oracle.com/support/advanced-customer-services/cemli-services.html - They are available as part of a "free" Oracle Insight engagement. 

The Gorilla in the Room: We're thinking about reimplementing next year. Should we do that or wait for the Fusion Applications?

These were the pearls of wisdom from our experts:

Sandra - Consider Release 12 as a milestone in your journey. It is stable. There are live customers on it. It is a known animal. Doing nothing leaves you with less options. R12 is your milestone to get to Fusion. A lot of great business functionality is available now. With desupport for Release 11i coming in December, 2010, you need to get to Release 12, rather than wait for Fusion.

Mike Swing - If you wait to upgrade to R12, you are putting your production system at risk of being forced to upgrade in a hurry to resolve an issue that can't be resolved in R11i.  

Alyssa - Don't wait, you won't regret it.  

Floyd - Reimplementing is like getting a root canal without anesthetic in the lobby of the IRS while you're waiting for the audit. Upgrading is always the better choice if you can. 

Kyle Harris, from Oracle, pointed out that you may not have a path from Release 11i directly to Fusion. Floyd explained that there's no guarantee that Oracle will offer a direct path from Release 11.5.10 to Fusion 2 or 3. The current direct path offering is for Release 11.5.10.2 to Fusion 1. So if you think you're going to sit on Release 11.5.10 and wait for a fully functional Fusion Application, don't.  80% of E-Business Suite Release 11.5.10 customers are probably not good candidates for Fusion Release 1. Fusion Release 1 will not include manufacturing, for example.  

Stephen - Oracle Support will support the upgrade and not the reimplementation. Customers need to really make sure they can't upgrade before considering reimplementation. This point was made at other conference presentations as well - Oracle has limited resources for testing and must focus on what the vast majority of customers will be doing, which is upgrading. Reimplementation issues will vary by customer, depending on their situation, so Oracle Support will certainly try to help with issues, but the more thoroughly tested path will always be the upgrade path. 

In the past, when we went from Release 10.7 to Release 11i, Oracle had good numbers on the expected downtime window given certain factors. What is a typical idea of what you can expect for the downtime window? 

Mike Swing suggested that the upgrade from RDBMS Version 10.2.0.3 to 11.2.0.1 could take 8-12 hours, with the applications upgrade taking 12-15 hours, plus 1 day of testing; so about 3 days. To get that 3 day downtime window, the other panelists suggested you would need to consider the following:    Test your hardware environment. In most cases you will bring in new servers. Do as much as you can ahead of time. Consider adding CPUs that you might not use moving forward. Can you lease additional CPUs for the upgrade period? Can you borrow CPUs from other hardware?

• Brainstorm ways to improve performance with your third party vendors and consultants.
• Use Upgrade by Request to process the most necessary data during the upgrade, and then complete processing the rest of the data after go-live. 
• Consider taking the database upgrade off the table. All new releases of the database have been certified. Mitigate the risk. While you do have to test twice if you do the database upgrade separately from the applications upgrade, the testing is different for the database upgrade, where performance considerations are the main issue, and the Applications upgrade testing for R12 is largely functionality testing. 
• You won't know until you test it, then, after you test it, try to figure out how much time it will take and what you can do to reduce the time. There are lots of documents about how to reduce the downtime on My Oracle Support. 

Summary

All in all, the consensus from the panel was that if you can avoid doing a reimplementation, you should, due to issues with cost, support, and time. For those customers who are waiting for Fusion, the panel concluded that if the functionality provided in Fusion Release 1 doesn't match your business needs, then you should move to Release 12 first, and wait for Fusion to catch up with your requirements in a future release.

At the end of the Reimplement vs. Upgrade Panel at Collaborate 10, someone asked the panel "Do third party products that claim to fix the issues that might make you decide to reimplement actually work?"  The issues include changing the chart of accounts, calendar, and organization structures, or consolidating multiple instances to a single global instance with a shared service center. 

The question went unanswered, because no one on the panel had firsthand experience. Since Floyd Teter said "Reimplementing is like getting a root canal without anesthetic in the lobby of the IRS while you're waiting for the audit," and others on the panel agreed, I decided to do a little digging around.  If you can avoid reimplementing the full E-Business Suite and migrating your 11i data, based on everything that was said by the panel, then it would be worthwhile to do so.

So I searched for a software vendor and came across eprentise. I started with Skip Straus, an ex-Oracle Consulting Practice Manager and now an eprentise salesman, and asked him lots of questions.  Then I read a paper that he wrote called Why Reimplement?  I really wanted to attend the eprentise presentations at Collaborate on global instance consolidation and upgrade vs. reimplement, but that didn't work out. I spoke to Skip again over the phone, asked more questions, and finished up by looking at the eprentise website.

I also asked around to see if my consulting colleagues had any opinions.

The biggest concern raised by consultants was whether Oracle would support a customer that used eprentise transformation software to change Oracle EBS's "implementation-time configurations."  According to Skip, Oracle does not support third party tools, nor does it support the conversion scripts that you would write yourself to extract and transform the data.  The assorted eprentise solutions change the data content or format (such as numeric to alpha), but not the database structure.  The result is consistent and correct.  He said that eprentise has lots of customers who have made the move, and they haven't had any customer report that Oracle wouldn't support them.  The eprentise software changes and converts the data; the company supports the conversion and will address any issues.  That does not violate any Oracle support agreement.

Also, if you're going to reimplement because your data is bad, your choice is to clean up your data anyway, or abandon it since it's untrustworthy. If you are reimplementing because you want to change your chart of accounts, well, you'll still be changing your chart of accounts as part of the reimplementation. So it would seem like fixing the data over on your Release 11i side, making the changes to base setups in the E-Business Suite that are not easily changed, would be a good way to go. I also like the idea of changing your data first, and upgrading second, rather than trying to do both at the same time as part of a reimplementation.

Migrating all your data manually seems like a painful way to go rather than using Oracle's well-tested upgrade path. I understand the panelists who said it would take a lot more time and money to reimplement and migrate your data.

I'll leave you with these questions: 

1) If you've used a third party vendor's software to avoid reimplementing, whose product did you use?

2) Did it work?

3) Were the tools easy to use?

4) Would you recommend this path to others?

5) Do you have any caveats?

6) Did you run into any issues with Oracle Support?