In the Construction we’re used to fact that we rent tools when we need it. In the Oracle world there is no such thing. Migration is a phase in the project that could benefit from the usage of temporary licenses. Oracle has tools that really can improve the quality of a migration and decrease the risk. Buying licenses for migration supporting products however is usually too expensive for the job. Here a plea for a change in the licensing rules for migration supporting products, rent instead of buy!
We are approaching the end our project. Timeframes that have been ridden of all possible slack lead to high-pressure milestones and killing deadlines without any room for maneuvering. Always at the end of the chain, full on the critical path and largely dependent on the decisions made in previous steps is the data migration. After months of preparations, verifications, and load tests, D-Day arrives: the Cut-Over weekend. Massive amounts of data need to be extracted at exactly the right moment and need to be squeezed into the new production in a time frame that is as narrow as the average letterbox slot. And usually, that is done with the tools available in the intended production solution and supplemented with one-time-use custom tooling. This all puts data migration in a precarious position. Little time and the single last deciding factor for the Go or No-Go decision. This is the Boom or Bust part of a project. This is what penalties and bonuses depend on and therefore the most stressful period of a project.
So if we can take large chunks away from the data migration to reduce the load and the resulting risks from the equation, we can reduce the pressure on the timeline resulting from data migration to more achievable proportions. The negotiations begin:
- The organization wants full history: the project proposes open items only.
- The users want all detailed accounting: the project proposes opening balances only.
- The reporting requirements require complete data for any reporting period: the project proposes to go live at the turn of the fiscal year, or at least at a month end.
- And if you want historic data, you can look it up in a data warehouse solution or a frozen copy of the old system.
This haggling over data in the new system leads to a reduction of the volume of the to be migrated data significantly, effectively reducing the risk and the timeframe, but it also puts a dark cloud over the user satisfaction at an early stage of the new system. Next we can start preloading static information. If you’re absolutely, positively sure that certain data does not change anymore, you can preload it in your intended production system as early as possible. Again reducing the pressure on the cutover weekend. But at what moment can you be sure that data does not change anymore? Keep in mind that the pressure in this case comes from two sides. The design of the target system has to be vigilantly kept frozen for this object. And the data itself in the source system is alive. In the end nothing is really static unless a freeze is enforced through total change control. And the longer the freeze period, the deeper the frostbite gets.
Now if you could subscribe your target system to some sort of service that pre-populates and updates the data without actually going live for operations just yet. Obviously certain designs have to be final, the foundations must be sound. But there is a moment in any project that the foundation is solid enough to start pre-populating certain data components early and keep them in sync over weeks or months before the production cut-over moment. Imagine replicating all transactions as they occur and at a leisurely pace, synchronizing changes as and when they happen. This will get a complete set of transactions in the target system allowing for full history and full reporting. It would allow for a go live at any moment, because a large part of the information is replicated.
Yes: the migrated volume is large, but why would volume be a factor if the time constraint has vanished? You have a better adoption of the system, you have less pressure on the critical path in the project, and you have a tool in place that provides standard functionality and tooling in place for all your data migration and data cleansing activities. It even allows for a gradual and phased go live, as long as the process information stays connected within a process chain. A topic for another time.
And when you are moving towards the new system for operations you terminate the subscription service, end the use of the hub and can decommission the old system. Or enhance your business processes by leveraging the use of the hubs as a permanent solution. Now we just need the tools to do that.. .and guess what… the tools are becoming available through several hub solutions Oracle is making available. Just as a few examples:
- Oracle Financials Accounting Hub (FAH) allows for a subscription for accounting, with accounting rule to interpret accounting events in the legacy systems into journals in the target system.
- Oracle Universal Customer Master (UCM) allows for master data management of Customer master data, with “golden record” logic to define a single source of truth for your target system.
I recently had an encounter with a client faced with a challenge: Merge 4 Oracle eBS 11i instances into a single new R12. One of the components in there were the AR customers. Lots of overlap, lots of small differences, relative many mutations and updates, and a definite need to merge into a single Customer Truth. And a volume large enough to cause concerns for a single weekend data migration. So I suggested the introduction of the Oracle ebs R12 Customer data hub and instead of a onetime high pressure data migration weekend a 2 month “gestation” period building towards a fully up to date customer base in the target system, paving the way for the migration of all receivable transactions.
The client liked the idea of a pre-populating strategy followed by a continuous synchronization of the resulting information. However, looking at the license pricing strategies of Oracle a two month use of the ebs R12 Customer Data Hub with the given number of records proved prohibitatively expensive… So interesting approach and a great idea, but cost-wise overkill. Back to the old fashioned way of manual data cleansing and custom tooled data loading…
If you are constructing a large building, you obviously rent the scaffolding, the cranes and the cement mixers to get the job done. And by the time you don’t need the tools anymore, you return them to your supplier. You pay the bill and shake hands…
With Oracle pricing strategy you must purchase the tools. Perhaps it is time that Oracle allows for project licenses for temporary non-production use of certain components. Components to be considered would be FAH, UCM and CDH, but also system tooling such as Oracle Enterprise Manager. This change in pricing strategy would support complex and high pressure projects with an increasing demand for ever shrinking timespans, reducing risks, reducing pressure on timelines by taking substantial parts of datamigration away from the critical path. It would leverage standard Oracle supported functionalities, and make Oracle related projects generally more successful…
, Lead Consultant Oracle Financials.