When faced with the decision of whether to do a technical upgrade or migrate data to a new instance at the latest release, most companies will select the technical upgrade path because it is the least expensive and least disruptive to the business. First, let’s look at some definitions. A technical upgrade uses Oracle-provided scripts that convert the data from the current release to the latest release. All of the data, including all of the history may be converted or upgraded. All configurations and all modules that existed in the original instance remain the same. Migrating data is often called “lift and shift” indicating that data is lifted or extracted from the current environment, transformed, and loaded into a new environment. That new environment is a new instance of Oracle software that has been installed from scratch, and all modules have been reconfigured. There is no difference between a migration to a new environment and a reimplementation. In a reimplementation, APIs (application programming interfaces) are used to load the transaction data from the current environment into the newly configured Oracle instance. Generally companies load only one year’s worth of data.
Some of the consequences of a reimplementation include losing history, and having to maintain a sunset instance for reporting, auditing, and tax reasons, since only a year’s worth of data is in the new instance. Further, there are no standard extract, transform, or load scripts. Those must be created by a technical developer writing code. For a reimplementation, users must derive their landing balances and reconcile between the current instance and the new instance. If any changes are made to the configurations between the current instance and the new instance, users must continually normalize the data every time a report is needed, or a load is required for the data warehouse. New interfaces, extensions, and customizations must be created for the new environment.
However, there are several factors, including the desire to redo business processes, lots of customizations in the current instance, poor data quality, or structures that don’t meet the current business environment, that have led many to decide to reimplement or to delay the decision to do a technical upgrade. Other drivers may include multiple EBS instances, a short downtime window, or the inability to take advantage of new EBS features and functionality with the current configuration.
Before making the decision of whether to do a technical upgrade or a reimplementation, there are several steps that you can take. First, identify the pain points with in your current environment – what is working, and what isn’t working. For those things that are not working, engage your executive team to design the to-be state that is in line with the long-term corporate strategy and expected growth. Sometimes, the mapping between the current state (the source) and the to-be state (the target) involves changing a chart of accounts, merging or splitting ledgers or operating units, or adding new modules within Oracle. List all of the things that need to be changed, and determine if there is a sound business driver to incur the expense involved. Evaluate any alternatives to a complete redesign or reimplementation. Are you able to use eprentise tools to modify your current environment to meet your needs? Second, evaluate the entire portfolio of all of your customizations and extensions. Is there a way to take advantage of new Oracle functionality in the new release to eliminate many of those customizations? Third, develop a decision matrix to prioritize and quantify the decision drivers.
As customers look at whether they should reimplement or do a technical upgrade, these are some of the considerations and their impact on the decision to upgrade or reimplement.
- Changing the business processes: For some customers, business users and IT staff have been frustrated with their current EBS implementation and its restrictions. They accept the requirement to reimplement as an opportunity to break with the past and get a clean start with Oracle. Because it’s perceived as a requirement, they have an easier time justifying the additional expense, effort, and delay of putting the newest version into production. However, a reimplementation doesn’t always fix the frustration or reduce the perceived operating restrictions. Before deciding on a reimplementation, determine what about your original EBS instance doesn’t work. Very often, even with a reimplementation, users want to do things the way they’ve always done them. Even in the early days, when companies first implemented EBS, they designed their structures (i.e. chart of accounts, ledgers, or legal entities) to mimic those in their legacy systems, and they didn’t take full advantage of the functions and features of the Oracle Applications. This means that even if they elect to reimplement, they often end up with the same or similar problems as they had in their old environment. It is difficult to get users to design new business processes with a blank screen. Further, if those changes in business processes result in different configurations or use of new features and functions in the latest release, users often have a hard time visualizing the impact of those changes on their data.A reimplementation drains the business’s resources more than a typical major release EBS upgrade. For a fresh install, the functional team must design and approve the configurations for every module, must do manual mapping from old configurations to new configurations, and must insert sample test data for the first conference room pilot to validate the new configurations. The technical team must apply localizations, create new interfaces, and code from scratch, every customization and extension to fit the new environment. Only after the configuration, customizations, the extensions, and the interfaces have been unit tested and validated, then the technical team can write conversion scripts to bring over data from the existing EBS environment.
- Poor data quality: A reimplementation doesn’t guarantee that the quality of the data in the new environment will be better. The old garbage-in, garbage-out principle applies. You can’t rely on a programmer who is transforming your data into the new instance to know how that data needs to be cleaned up, and what needs to be retained. If you are trying to get rid of bad data, you need to go through the process of cleaning up master data using Oracle merge functionality. You may also need to clean up the chart of accounts, or purge obsolete data. Oracle provides seeded purge programs to eliminate transaction data that is not needed. Even though the migration into a new environment generally brings over only a year’s worth of data, and thus the footprint of the new instance is smaller, your history needs to be retained somewhere. Retaining the history in a sunset environment is expensive because every time that data is needed, ETL (extract, transform, and load) scripts need to be written to aggregate the historical data with the current data.
- Customizations: If you have a lot of customizations or extensions in your environment, there are many third-party products and scripts available to identify customizations. A reimplementation doesn’t take away the need to evaluate each of those customizations to determine whether new, standard Oracle functionality can replace them. It is far easier to do the analysis, and implement new Oracle functionality then it is to rebuild the existing customizations in a new environment.
- Mergers, acquisitions, or divestitures, or the need to comply with new statutory or regulatory requirements may mean that your current EBS environment is not aligned to your business. If that is the case, you have other options besides a reimplementation. eprentise offers software that can:
- Transform the fundamental setups of your old instance(s) to eliminate the reimplementation conditions.
- Adjust or re-do any unsatisfactory setups. You can change the chart of accounts, the calendar, any other key flexfield structure, the business structures of a legal entity, and operating unit, a business group, or an inventory org. You can merge or split data, move transactions to a new operating unit, or purge data that is no longer needed. Within your current EBS environment, eprentise software can transform the old data to reflect the removal of the perceived reimplementation conditions and new setups.
- Consolidate prior instances as required so there is only one instance to upgrade.You can also use standard Oracle functionality like secondary ledgers to accommodate some of these business changes. If you only need to have a new structure for future data, you can create a new ledger or operating unit. The solution of creating a new structure is for going forward only, and may necessitate creating processes to deal with in-flight or open transactions, and may create some reporting and compliance issues.
- Upgrade Choice: Most EBS customers upgrade if given a choice because that is the path of least resistance. It is important to hire a consultant who does a lot of technical upgrades. An experienced consultant understands the issues that are likely to be encountered, and works closely with Oracle to determine the most efficient upgrade path. Compared to a reimplementation, with an experienced consultant, a technical upgrade is simpler, uses fewer resources, will cost less, and the time-to-value is shorter.
- Reimplementation Consequences: Here are some reimplementation consequences in the areas of implementation, data history, disposition of the old instance, reporting, and business intelligence:
- You must install and configure a fresh installation of the newest version of Oracle EBS.
- You are on your own to get your historical data from the legacy instance into the new instance.
- You must decide what history to load and what to do with the remainder. You will need a policy for each different type of data. The usual choices include most recent and current fiscal year, current year, and only open transactions.
- Even though data conversion tools these days are powerful, and programmers in the global data centers are inexpensive, dealing with data history will be a significant part of your reimplementation project. It will cost money and require several iterations to get it right.
- There is little to gain from custom historical data migration across the numerous EBS tables compared to Oracle’s upgrade process.
- You will keep the old instance in “legacy” mode. Some call this a “sunset” instance. It must be frozen and restricted to read-only access.
- You will devise reporting mechanisms to span the legacy instance and new operational instances. That includes translations, reconciliations, mappings, and external reporting environments.
- If you have a business intelligence environment or data warehouse, you will make changes to incorporate both the frozen legacy and new operational environments.
- The reimplementation is often as complex, cost as much, and takes as long as the original EBS implementation. It is often a multi-year project that you would generally undertake with the support of a professional services provider.
- Customer’s Choice: You now have a choice. Despite the conditions that apparently require reimplementation, consider eprentise Transformation software plus an Oracle upgrade: Use eprentise software to:
- Transform the fundamental setups of your old instance(s) to eliminate the reimplementation conditions.
- Adjust or re-do any unsatisfactory setups.
- Transform the old data to reflect the removal of reimplementation conditions and new setups.
- Consolidate prior instances as required so there is only one instance to upgrade.
Run the technical Oracle upgrade scripts.
With this transition approach, you retain more of your investment in the old instance. You also take advantage of Oracle’s upgrade software, for which you pay as part of Oracle Support.
- Your result: The result is an instance with all the desired target characteristics and all the historical data. All the transactions in all subledgers reflect the new setup parameters.
- You have the same opportunity to change setups (flexibility) to define the target as you would have if you were to reimplement.
- You can set up new features, add additional Oracle modules, or use the new functionality of the new release to streamline your operations and align your EBS to your current business.
- Benefit: eprentise transformational software plus a technical upgrade is cheaper, faster, and better than Customer reimplementation plus data migration.
It is important to keep the upgrade vs. reimplementation discussion in the context of the overall transition to the newest Oracle EBS release. First, understand what the target needs to be. Compare that to the current EBS setup. Itemize and inventory everything that needs to change. Then consider how you would make each change via an upgrade (with eprentise Transformation software plus a technical upgrade), and via reimplementation (install and configure a new environment and migrate your historical data). A parallel analysis considers everything in the old instance(s) that does not need to change. What do you not need to touch if you upgrade? What do you need to replicate anew if you Reimplement? What extra historical data that is supposed to be unchanged must be managed and migrated if you reimplement? There will be other project components impacted by the reimplementation decision , virtually everything that touches the E-Business Suite. Some things such as reports may be independent of the upgrade vs. reimplementation decision. Another set of items will be dependent, such as what happens in the Business Intelligence environment.
When planning to go to a new release, focus on the components that are dependent on the specific transition methods. Cost/benefit and resource expenditure analyses will assist in your transition planning, specifically aiding you in deciding which method will be best for your organization’s adoption of Oracle E-Business Suites latest version and the new features that come along with it.
With the introduction of eprentise software, you can eliminate obsolete fundamental setup configurations and multiple instances as reasons that lead organizations to select reimplementation. If you like what the most current Oracle E-Business Suite (EBS) offers and you want to save time, money, and resources on the transition, you can combine eprentise Transformation software with a technical upgrade to shorten the time-to-value at a lower cost, and provide a better result for both the Business and IT. Why reimplement?