1 WHITE PAPER Ready, Set, Go Upgrade to ERP Cloud Release 10
2 INTRODUCTION It s time to upgrade our ERP. For many, those words often trigger thoughts of projects past where countless hours are spent bringing your current applications to the latest version. Avoiding costly upgrades is one of the primary reasons why organizations select Oracle s Cloud ERP. Upgrading can be a challenging process because it often entails a fair amount of investigation, planning, testing, and technical processes that must be well executed. For many Oracle Cloud customers, Cloud Release 10 will be their first upgrade on their new Oracle platform. Although less complex than upgrades to Oracle s on-premise application (with PeopleSoft, EBS or JDE), there are still a number of considerations and steps required in order to execute a successful upgrade. Oracle requires customers to be on the current release or the prior release. New releases have been issued twice per year, so expect to upgrade at least once every year, maybe twice. As you work with Oracle to plan your upgrade timing, there is a lot of coordination required with the Oracle Support team. Be sure to understand all of the steps and timing required to execute a successful upgrade. Emtec has considerable experience with Cloud Release 10 upgrades and has put this report together to share some of the knowledge developed in the process. Some of these lessons learned and guidelines can be found below, but remember that each upgrade can present unique challenges because each instance reflects a specific configuration, unique business processes and personalizations that apply to your environment alone. It is our hope that this report will help educate, guide and support your upgrade to Cloud Release 10. DO YOUR HOMEWORK Oracle provides overview documentation that lays out the upgrade process, sets expectations for their Cloud clients and provides information on new features and functionality that are included in the new release. We suggest you start by looking at the Oracle ERP Release Readiness online site at the following link: Pay particular attention to : R10 Upgrade Planning Document R10 Financials What s New R10 Business Intelligence for Financials R10 Oracle Common Tech UX What s New We also recommend that you review Functional and Technical Known Issues documentation for R10 at:
3 Other documentation that you may want to review includes: Release content documents (RCDs) Spotlight videos What s New guides for other applications Product documentation BEFORE YOU START Four things you should do before starting the upgrade process: Preserve all custom Business Intelligence (BI) and Financial Reporting Studio (FRS) reports. Store them in the folder labeled Shared Folders>Custom. Otherwise they will be overwritten by the upgrade. Publish sandboxes to preserve any customizations that you want to save before the upgrade. Delete those that you are not going to publish. Close any open accounting periods in the sub-ledgers and general ledger, run the reports, and reconcile general ledger account activity and balances. Emtec advises all Oracle ERP clients to complete this process as part of each accounting period close. Run a few key financial reports, maybe one from each sub-ledger application, just prior to the upgrade. Then run those same reports again right after the upgrade and compare the reports to ensure the upgrade did not have a negative impact on the financials. Any significant differences should be investigated and resolved. One item to note: you should determine if an environment refresh is needed before upgrading your Test environment. This will give you recent Production data for testing after the upgrade. It takes several weeks for Oracle to perform the refresh after being requested, so plan accordingly. Alternatively, you can provision an additional test environment to use for the upgrade. Again, plan ahead as this takes several weeks for Oracle to deliver a new test environment. There is additional cost for another environment. CHANGE CONTROL PROCESS Emtec recommends that all Oracle ERP clients establish a change control process to be followed when making any changes to the Oracle applications. This process should include and enforce change documentation requirements and that the business users have successfully tested the change, recorded their test results, and signed off on the change before it is deployed in Production. When the Oracle Cloud applications were implemented, documentation should have been created to capture the original setup and configuration of each application including any RICEW (Reports, Interfaces, Conversions, Extensions, Workflows) deployed. If not, we suggest you take this opportunity to go back and use the change control process to establish the documentation for those changes. Deployment documentation for the setup and configuration of the applications and the RICEW items function as input to the development of the regression testing suite of test cases.
4 REGRESSION TESTING SUITE When completing a release upgrade, as well as any other system change (e.g. monthly update patches) it is important to thoroughly test the system and all applications. Each Cloud client should build a suite of test scenarios and test scripts for regression testing of their Cloud applications. The test cases should address all standard Oracle functionality being utilized in each of the applications. The test cases should also address testing any RICEW (Reports, Integrations, Conversions, Extensions, and Workflow) components that have been built and implemented. Some examples of RICEW items we test as part of our upgrades are custom BI, FRS, and Smartview reports, Banking integrations, Payment formats, and approval routing workflows for expense reports, invoices, and journals. Having a strong Regression Test plan is critical since it will be reused multiple times in the future. You should already have one from your initial implementation but it may need updating or additional detail. A good System Integration Testing or User Acceptance Testing plan is the road map and the starting point for the regression testing suite you will use at each release upgrade. Build other test cases around the basic test plan to cover all functionality being utilized and any changes that have been deployed since go-live. ASSEMBLE YOUR UPGRADE PROJECT TEAM Although significantly less effort than a traditional, on-premise application upgrade, upgrading Oracle Fusion Cloud applications still requires effort and dedicated resources to execute successfully. Ideally, you want some people on the team who have been through the Oracle Cloud upgrade process previously and can help guide the team. You will also need people who have experience and expertise in all of the applications being utilized. They will be able to identify any issues and verify functions far better than any outsider or generic Oracle expert. You also want in-house Oracle Fusion IT resources involved in the project to assist with anything to do with the specific setup and configuration of the ERP system, the applications, and any RICEW items that have been developed and deployed. A seasoned Oracle project manager is essential to develop the upgrade project plan and timeline, ensure effective communication and keep everyone on the same page with regard to assigned tasks and due dates. An Executive Sponsor should be identified for the project to give it the high-level visibility needed across the company. Leaders of the Business areas that utilize the Oracle applications should also be put on the project team as sponsors and supporters of the project. Last but not least, the Oracle Success Manager should be a key member of the upgrade project team to provide escalation of critical issues within the Oracle Support organization to expedite resolution. There will be some issues that you are not able to solve in-house since these are Cloud applications. Only Oracle has access to make some technical changes or bounce Cloud services and environments. It is critical that you have someone aligned with your organization and project from the Oracle Support team to ensure they are diligently working to resolve the issues that will make your upgrade a success.
5 DEVELOP THE UPGRADE PROJECT PLAN The typical upgrade project will last 3 to 6 months. The longer interval may be necessary if you have not previously built the regression testing suite and gotten your change documentation together. Every time you go thru the upgrade process, you should get better at doing it and be able to reduce the duration of the project. You can use the monthly patch updates as a kind of mini upgrade and use them to help you build a repeatable process that can be used for the larger point release upgrades. While developing the plan, start outlining the post-upgrade steps. These post-upgrade steps are unique to your company, depending on applications and services being utilized, application setup and configurations, RICEW items implemented, and items that are being impacted by the new release that you want to validate. A few of the steps found in a typical Release 10 upgrade include, but are not limited to: Confirm BI and FRS Reports are working ; also confirm standard Oracle reports are working Run audit control reports and compare to same reports ran prior to upgrade Confirm application setups upgraded correctly Confirm new R10 landing page is working correctly Run integration processes and ensure files are loading from UCM The project plan should also include key communications (these can be drafted during the planning phase to be ready to send out at the appropriate time). And don t forget training - identify any user training that may be needed on new or changed functionality and provide for its development and delivery. BUILD THE UPGRADE TEST STRATEGY The overall strategy for testing should be to run all test cases in the regression testing suite before applying the upgrade, to set a baseline for comparison. You will repeat the same set of regression testing after the R10 upgrade. The focus should be on the RICEW items and any suspect items reported as issues from others who have already applied the upgrade. It shouldn t be necessary to pre-test normal functionality that the users are familiar with and do not need to further document as a baseline. Create columns in the regression testing suite tracking document (spreadsheet) for the core team tester and the business tester for each test item, status (Pass / Fail), and comments. Assign the appropriate resource from the core team and business area to each test case. One key thing to remember is that it will usually take a business tester twice as long to complete the test cases as it does the core team member because the business tester has their regular job to perform in addition to the testing. Schedule accordingly.
6 START THE UPGRADE Upgrade the Test Environment Once you have all of the prerequisite tasks complete including the project plan and team, regression testing suite, testing strategy, and the delivery of a new test environment or refresh of the existing test environment, if applicable, you are ready to begin the real work of actually receiving the new, refreshed, or upgraded environments, performing the pre and post upgrade tasks, and performing the regression testing to determine if issues exist in the environment that must be resolved before you are ready to upgrade in Production. Emtec recommends refreshing your test environment before upgrading so you have recent Production data to test with after the upgrade. You should plan for some testing after the refresh just to validate the environment and make sure it is working correctly. We recommend focusing on testing workflows, reporting, and RICE items you have implemented such as integrations with external systems. If you have provisioned a new test environment, we recommend full regression testing be performed to ensure all functionality is working correctly. Once you have checked out the new or refreshed test environment, identified any issues and resolved as many issues as possible, you are ready to proceed with the upgrade of the environment. The next step is to perform the pre-upgrade steps recommended by Oracle prior to Oracle performing the upgrade. At this point, preserve your custom reports by moving them to the Shared>Custom folder, publish any sandboxes that you want to keep and delete the others, and perform the accounting period close process on any open past periods. You do not have to close the current open period. It is a good idea to create accounting in the sub-ledgers to ensure all transactions are accurately accounted for in the general ledger. Also run a few key financial reports, maybe one from each subledger application and the GL, just prior to the upgrade and save them to compare to the same reports after the upgrade as an audit control. Oracle will take the test environment on a Tuesday morning and has a 72 hour window to perform the upgrade so you can expect to have the upgraded test environment back on Friday morning to start your post upgrade steps as outlined in your plan. TEST, TEST, TEST After the post upgrade steps have been completed, it is time to start the system regression testing. The regression testing suite plays a valuable role as your guide to efficiently performing all of the test cases needed to validate the functionality in the Cloud applications, record the results of the testing, and identify any issues caused by the upgrade. Promptly report any issue to Oracle Support by submitting an Oracle SR (Support Request). Oracle will help resolve the issue using their knowledge base, troubleshooting tools, and expert resources. The SR should have REL10UPG at the beginning of the Problem Summary so Oracle Support can use this tag to prioritize the upgrade issues appropriately. Also use the Oracle Success Manager assigned to your company to escalate the high priority issues for faster resolution.
7 We recommend that the core project team conduct the first round of testing to identify any technical issues and work to resolve as many as possible before the business resources start their user acceptance testing. Remember that business testers may have limited time available (because they are still doing their regular jobs) so it will likely take them longer to complete their testing than it took the core team. Please note that Oracle will continue to perform monthly patch updates on your test and Production environments, even when you are in the middle of your upgrade. Pay attention to when these patches will be applied so you can complete your focused testing per your regular monthly patch routine regardless of the upgrade in progress. Use the Regression Test Suite tracking spreadsheet to track the status of all test scenarios. You might want to include a second set of tester name and summary status columns on your tracking spreadsheet for the Business testers and their results for each test case. The business tester should enter their actual results in the detailed test script, of course. We recommend that the test lead should keep track of completed tests and enter the summary status from each test script and update the tracking spreadsheet. The summary status page can also be used as a communication tool to keep the project team up to date on which test cases have been completed and whether the test cases passed or failed. All failed test cases should be reviewed by a core project team member to determine if the issue is an Oracle problem for which an SR should be submitted. In some cases, the test script may not be clear or accurate and could have caused the issue. In other cases, it may be a setup or security issue that can be resolved in-house before sending the test script sent back to the business tester with a request to retest the test case. In any event, an Issue Log should be created and all issues should be documented, progress to resolution tracked, and the actual solution should be documented. The issue log and test scenarios status should be reviewed often with the team to help everyone understand current status, outstanding tasks and issues, and how the issues were resolved so they understand root cause and actual solution. We also recommend tracking Action Items, along with the Issues, so they can also be assigned to a resource, tracked, and completed. One other item to note is that Oracle may respond to your SR s and let you know that the issue will be fixed in a future patch release. If that is the case, make sure there is a suitable work around (fully documented, please) that can be used until the patch is applied. If no suitable work-around is available, go back to Oracle and request an expedited solution as the issue will require a delay of your upgrade schedule. Include your Oracle Success Manager in these communications so they can help expedite a patch or find a suitable work around so the upgrade can stay on track. Align your technology solutions with your business needs. Our collective focus is to continue to build clients for life: long-term enterprise relationships that deliver rapid, meaningful, and lasting business value.
8 PLAN THE PRODUCTION CUTOVER The Production Cutover plan will mirror the pre-upgrade and post-upgrade steps documented in the Test environment upgrade plan. Pull the project team together to review those steps, add in any others that were not a part of the original list, and determine any others tasks that are required for production that were not a part of the Test upgrade process. Be sure to include any post upgrade steps surrounding issues and resolutions uncovered in the Test upgrade process. You will also need a plan to distribute new upload spreadsheet templates that are needed with the new release. Some spreadsheet templates will not change while others will be updated make sure you are using the latest version on your new release upgrade. Additional steps needed for the Production upgrade that were not needed for the Test upgrade include but are not limited to: Follow whatever change control process you have in place. Add those steps at the top of the plan to ensure that the required documentation is created and submitted for approval early enough to obtain approval prior to starting the upgrade in production. Identify and place any scheduled processes on hold (several hours) before the upgrade is scheduled to start. You don t want automatic processes to kick off during the upgrade process. You will need a post upgrade task to release those scheduled processes after the upgrade is complete. Have someone on the team monitor those processes to ensure they are complete successfully. Identify any external processes that are sending data files to Oracle. Place those on hold before the upgrade process begins and be sure to re-start them after the upgrade. Include the need to communicate with the business and end users of Oracle applications advising them of the Production upgrade schedule and any changes that they will notice when they login after the upgrade. You should also communicate the procedure they should follow for support if they run into issues using Oracle Cloud after the upgrade. Based on your experiences, there may be some refinements or extensions to test scenarios that were identified along the way. Upgrade your plan and test scenarios to include these refinements so that they are included in the next upgrade process. You will also want to identify critical business processes that should be tested as soon as possible after the upgrade and/or monitored during the first week to be sure issues don t recur after initial testing. Some of these, like those for reporting and security, can be completed by the core project team. Other test cases will require end user participation as they use the upgraded Production environment. Identify the business people that will be asked to perform those tests. Review the cutover plan and test cases with involved individuals so they know what they are assigned to do and when to do it.
9 You may want to include such items as: All Banking integrations including Payments, Statements, Positive Pay, and Credit Card transactions. If you have more than one bank, make sure you test what is appropriate for each bank. Journals, Invoices, and expenses both online, using spreadsheet uploads, and from mobile devices for expenses. Verify that transactions are being routed correctly for approval and approval notifications are being received. Check that invoices sent to scanning and OCR services are being received for processing. Our experience with Production upgrades has taught us that you cannot just test it once and forget about it. There may be issues that don t reveal themselves until regular processes are resumed. EXECUTE THE PRODUCTION CUTOVER PLAN AND GO-LIVE At this point, you have done everything you can do to plan and prepare for the Production upgrade. The weeks prior to and after the Production upgrade should be focused on executing the Cutover Plan, ensuring all the tasks are completed, responding to any issues encountered, and working with Oracle Support to ensure your issues are understood and timely resolution is achieved. The expectation should be set with everyone that there may be some issues encountered after the upgrade but they will be worked to resolution as quickly as possible. Tell the users that they may encounter issues during the first few days after the upgrade and let them know how to report the issues they encounter. Also let them know that things should get back to normal by the end of the first week on the new release. As noted previously, we recommend that key business processes and system integrations be monitored by the core project team during the first week after the Production upgrade so any issues are immediately recognized and investigated. SUCCESS! SO, WHAT S NEXT? The upgrade is complete and your systems are up on the new release of Oracle Cloud. Complete your documentation, clean up the test scenarios and plans (for use next time), and stay in touch with the users to make sure all is going well for them. Now that the main upgrade process is behind you, you have an opportunity to start rolling out some of the new features and functionality that were included in the upgrade. Since the upgrade project can be demanding enough on its own, we usually recommend waiting until after the upgrade to review and implement new functionality. The Oracle Cloud upgrade process, albeit less complicated than the upgrade process for on-premise installations, is still a significant process that takes considerable time and effort for IT, your in-house Oracle support team, and the users of the system. This critical process must be well planned and tightly managed to ensure timely completion and quality results.
10 You can complete this process on your own with the help of Oracle support, as some companies do, but we strongly encourage you to educate and prepare your organization for your R10 upgrade. You may see the value in enlisting help from an experienced Oracle Cloud support organization to help guide your team and reduce risk. Emtec would love the opportunity to help your company with the planning, organizing, and execution of your next Oracle Fusion Cloud upgrade or other Oracle Cloud support and management requirement. Contact us: to schedule a discussion. We are experts at implementing, upgrading, integrating, and extending the functionality of the Cloud applications and will be happy to offer our assistance as you move forward with your Oracle Fusion Cloud applications. ABOUT EMTEC Emtec is the right size provider of technology-empowered business solutions for world-class organizations. Our local offices, highly-skilled associates, and global delivery capabilities ensure the accessibility and scale to align your technology solutions with your business needs. Our collective focus is to continue to build clients for life: long-term enterprise relationships that deliver rapid, meaningful, and lasting business value. ABOUT THE AUTHOR Alan Green, Director, Oracle EBS Practice at Emtec, Inc. Alan has over twenty five years of experience in Finance, Accounting and Information Technology with over twenty years of experience working with Oracle Financials applications. Alan has worked in a variety of roles including developer, systems analyst, business analyst, business relationship manager, project manager, and director. Alan excels at understanding complex business processes, requirements and issues and then designing and implementing automated application solutions that provide efficiency and value to the business. Some of his recent professional experiences include managing Oracle E-Business Suite Release 12 upgrades at several companies, managing acquisition projects bringing new companies into Oracle Financials, and his first Oracle Fusion project at a large insurance brokerage company. Alan has worked with the Supply Chain and HRMS applications in addition to Financials. Alan is a Master in Business Administration majoring in Corporate Finance and also has a Bachelors of Business Administration in Management Information Systems. He has experience working with several industry domains including Telecommunications, Utilities, Insurance, and Aerospace.