1 + 1 = 12: A Look at Migration vs. Consolidation

PDFPrintE-mail

This article focuses on two approaches for combining multiple instances of Oracle® E-Business Suite (EBS).  For purposes of completeness and generality, we will consider two instances of different releases (11i and R12), the processes that must take place in order to make them compatible, and the actual combination of the two instances via two different options: Migration and Consolidation.

Goal

For a globally expanding business looking to streamline operations and get to R12, the general objective is to conduct all existing business in a single EBS R12 instance.  In our example, the company has two business lines: one runs in an 11i instance, and the second runs in its own R12 instance.  Here we will simply refer to the instances as Current 11i and Current R12.  When the Current 11i business is combined into Current R12, the resulting instance will be a truly global instance, which we will refer to as Global R12.  The two sub-objectives to reach the goal are (1) to conduct both lines of business in R12 and (2) to combine Current 11i and Current R12 instances.

Summary Comparison Between Migration and Consolidation

Two approaches are available to get from multiple instances and reach the goal of a single EBS R12 instance in which to run an entire business:

  • data migration plus sunset instance, and
  • R12 upgrade followed by eprentise Consolidation.

Migration is the way things have been done before when it was necessary to combine two instances, and it is characterized as relying on highly skilled technical staff, labor intensive, supported by very general purpose software utilities such as data loader.  The end result is usually a compromise among schedule, business, and technical constraints.  Migration generally takes a long time and is expensive; it has been the only game in town and follows practices and techniques generally used in the Oracle EBS community.1

Consolidation is new, characterized as relying on a purpose-specific software product that displaces labor, elapsed time, and technical risk.  The end result has no business or IT compromises.  We have developed the eprentise Consolidation software to meet Oracle EBS customer needs, reduce the costs of EBS, and improve the business results.

A migration approach generally calls for data to be extracted from one instance, transformed by custom scripts, and loaded into a new instance.  In our example, the company would need to extract the Current 11i data, transform that data into new data compatible with R12, and load the transformed data into the Current R12 instance, forming Global R12.  During a migration companies generally only bring master data, open business transactions, and 1 - 2 years of closed transactional data into the new global instance.  As a result, one of the byproducts of the migration approach is a recycled instance that must remain in a "sunset" state for 5 - 10 years, the exact duration being based on external regulations for data retention and internal business operational requirements.  Thus, there is an implicit redefinition of the goal to include (1) a single R12 instance for future business plus (2) a sunset instance for the historical data until its regulatory and operational usefulness expires.

Migration Example

The migration approach calls for custom programmers to select and transform 11i data into R12 format; albeit with whatever available R12 APIs can be used.  Where R12 APIs are not available, the custom programmers must also combine Current 11i Current R12 data.

The consolidation approach involves a software-assisted combination of Current 11i and Current R12 instances, forming Global R12.

Consolidation Example

This approach calls for Oracle's standard upgrade process to transform all the 11i data into a R12 instance, which we call New R12 in this example.   The next step of the approach relies on eprentise software to combine all the New R12 data and setup configurations into the Current R12 instance, resulting in Global R12.

The post-steps involved for reconfiguring interfaces in the Migration and Consolidation plans are similar, and thus are not a factor in comparative workload estimates.  Since the Current 11i business data in New R12 will change during consolidation, it will be necessary to ensure that the interfaces are re-written to utilize the reference data (such as customer number, invoice number, vendor number, item number, etc) rather than the system identifiers such as customer_id, invoice_id, vendor_id, and item_id so that the interfaces only have to be written one time and not redone after the R12 upgrade. 2

Pros and Cons of the Two Approaches

Traditional Migration Approach eprentise Consolidation Approach
Pros Cons Pros Cons
Common approach, often recommended by consulting organizations No standard extract/transform scripts.  Very similar to a custom development project requiring a more formal development and testing methodology including documentation, error handling, and development standards. Shorter project duration with fewer resources translates to lower costs.  Project can easily be completed in less than 8 months and generally for well under a million dollars in labor.  That means that the savings of a single instance are available sooner. Not widely understood among Oracle professionals.  Customer needs strong "Early Adopter" sponsor.
No need to upgrade Current 11i to New R12 due to straight data migration into an R12 instance. More risk in extract, transform, and load (ETL) that will not be supported by Oracle. Only testing that is required is functional testing Need to upgrade Current 11i to New R12, so cutover will be done in stages.  May need to have interim production of New R12 prior to consolidation into Global R12.
  Requires technical knowledge of all tables and usage in the E-Business Suite. Repeatable results, reusable as requirements change.  As requirements change, only need to add/change rules, a step that is usually done by a functional user on a specially designed user interface in the software In a very short time.  
  APIs do not exist for all tables.  There is a risk of compromising the data integrity by extracting and loading data incorrectly.  Oracle Support not available. All data integrity is maintained because the code is automatically generated.  
  History is generally not converted.  Generally a sunset instance is required for reporting, reconciliation, business intelligence, and audits.  Every time the sunset instance is accessed, data must be transformed to align with the R12 instance. All history is converted so there is no need to maintain a sunset instance for reporting, reconciliation, etc.  All the data is complete and consistent and available in a single instance.  
  Need to configure target instance No need to configure target instance  
  Scripts are written for the current state of the data.  Any changes require re-writing of the scripts. Full documentation of existing instance including comparison of instances from Metadata Analysis  
  12-18 months duration 4-8 months duration  
  Need to maintain multiple production instances and consistent patch application, addition of master data for all instances. Consolidation of entire US instance occurs in a weekend so no need to maintain separate instances for reports, business intelligence, open items.  

Comparative Costs of Migration and Consolidation Approaches

The following example spreadsheets calculate the minimum and maximum costs for resources for a traditional migration approach compared to the cost of resources for the eprentise Consolidation approach.  Neither example includes resources for creating and testing interfaces, project management, or database administration since those would be similar for both approaches.  The minimum is based on the shortest time and the fewest resources in the above diagram, while the maximum is based on the longest duration and the most resources.  A standard of 12 modules and a consulting rate of $1,000/day were used in the calculations for all examples.  All of the examples utilize a 50-week year and five day work weeks. The total cost of resources for a traditional migration approach ranges from a minimum of $9,000,000 (12 months duration and 3 resources) to a maximum of $27,000,000 (18 months duration and 6 resources).

Migration Approach

The major difference between the eprentise Consolidation Approach and the Migration Approach is that since there are no scripts to write, test, and revise, the only required resources are business users who would test the functionality of the resulting consolidated instance and make decisions about what rules to include based on the data requirements.  The functional team does not need to configure the R12 instance for R12 functionality.  Our experience is that the functional users would only be required an average of quarter-time.  The cost table below does not include the license costs for the eprentise Consolidation software.  The estimated resource costs range from $255,000 for a 4 month project and a single functional resource per module to $1,020,000 for two resources per module on an 8 month project.

Consolidation Approach

Conclusion

eprentise Consolidation provides a more complete solution at a lower cost and in a shorter time than the Traditional Migration Approach.  With eprentise, the total project costs are a fraction of those of Migration.  All history is converted.  There is no need to worry about getting the right technical resources or compromising the data integrity.  Having the right tools make the users look like pros.  Using eprentise Consolidation software is the right choice for a successful project.

Add comment


Security code
Refresh

Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Enter your email address to sign up for our Newsletter

Sign up now

captcha
TEChanges - Agility by Design

May Puzzle

David is often referred to as Rainman due to his peculiar ability to effortlessly figure out a certain date's day of the week. He recently displayed this talent when I asked him if there was a conflict with the upcoming Fuzzy Dice Conference and our weekly court-ordered community service. He asked the date of the convention. It was April 20th, 2012.

"Oh, that’s a Friday," he said, effortlessly. "And your sentences have you committed for the next few dozen Wednesdays so you'll be able to go." And of course he was right.

One day a few weeks ago I asked out loud in the office about the date June 5th. And of all people, my brother Tommy piped up and said "Oh, that's a Tuesday."

"That's right," said David.

Well how about Otcober 3rd?

"That's a Wednesday," said Tommy. Then I asked about Christmas Day 2012.

"Oh, that's a Tuesday." David nodded in agreement.

Do we now have two rainmen? Or had Tommy figured something out?

Show solution...

Solution

Here's what was going on. Tommy was using something called anchor dates. And these dates apply to each and every year. April 4th, or 4/4 we’ll call it from now on, June 6th or 6/6, 8/8, 10/10, 12/12, are all the same day of the week, each and every year.

So too are 5/9 and 9/5, May 9th and September 5th. So too are 7/11 and 11/7, and all the above dates are the same day of the week, as is the last day in February, Leap Year or not. And they’re all the same day as January 4th, it would otherwise be January 3rd, but this was a leap year, and that’s changes the anchor day from January 3rd to January 4th.

Tommy also knew that New Year's Day was a Sunday. He was sobered up by then. And he knew it was a Sunday because Christmas was a Sunday in 2011, so New Year's Day is a Sunday, so the Anchor Day for 2012, January 4th, has to be a Wednesday!

So if that's a Wednesday, then 4/4, 6/6, 8/8, 10/10, 12/12, 5/9, 9/5, 7/11, 11/7, and February 29th are all the same day of the week, and they're all Wednesdays. So when I ask for example, about October 3rd, he knew October 10th was a Wednesday, 10/10. So 10/3 must also be a Wednesday. 12/12 is a Wednesday in 2012, so it’s 12/26, which is two weeks later. So 12/25, or Christmas Day, must be a Tuesday.

Success Tips for Oracle Project Management

  • Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
  • Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
  • If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
  • Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
  • Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
  • Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
  • Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
  • Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
  • Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
  • Include governance, risk, and compliance management as part of the project plan.
  • Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.

The Analyst Corner

John Van Decker, Research VP of Gartner, states:

"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."