A Guide to Oracle Retail Cutover Strategies

This article contains an explanation of various Oracle Retail cutover strategies. In particular, it focuses on the different features of a phased cutover versus a 'Big Bang' cutover, as well as offering methods to reduce project costs and ensure cutover success.

Hamish is concerned with understanding and communicating the transition risk landscape and agreeing a combination of cutover approach and mitigation activities which appropriately balance risk and cost for an organisation.

Q: "We are implementing Oracle Retail, replacing an in-house legacy application suite in which retail applications such as Merchandising, Inventory Management, Pricing, Allocations, Assortment planning etc are tightly coupled to core Master Data tables. We are steering away from big bang, but can you advise on what approaches we could take?"

Response

"The biggest two questions to consider when cutting over are: how agile is your current legacy and integration landscape and how big is the appetite for mitigation?

Typically I believe phasing a cutover actually adds more risk, as it requires significantly extra work and the costs escalate and/or the quality processes going in to each state then reduce.

Phasing an implementation reduces cutover risk but has other big impacts I'll refer to later.

In particular doing anything apart from Big Bang requires a significant amount of:

1. Transition planning - define the states, what is performed where in each and how will you transition from one to the next
2. Change and Training - you will need to prepare change activities for each state including preparing and executing training. This is not just for users but also application support and integration teams.
3. Testing - end to end testing is required for processes and integration in each state, including reporting visibility. That means UAT (User Acceptance Testing) as well as technical and integration testing
4. Development - Mostly this should be legacy and integration plus interim reporting, but you'll typically be surprised by how many downstream systems are impacted that hadn't been considered. It really depends upon your organisation's ability and appetite for decoupling existing capabilities into multiple transition states.
5. Support - I've been going in reverse order, but after each state transition it is key to stabilise support for the state, and validations, reconciliations and operational reporting may well change between each state. Data integrity issues may well also cause delays to the next transition.

So you need time, capability, organisational commitment, Oracle Retail and Legacy architectural expertise and budget to make it feasible to mitigate by phasing your implementation or your cutover.

Alternative 1: Phasing your Implementation

If you have plenty of time then you can plan upfront and execute each state as a sequentially separate project over a timeframe - it becomes a significant Programme Executive undertaking to persuade business stakeholders why a long running project with a large price tag is unlikely to deliver benefits in a typical retail timespan.

Alternative 2: Phasing your Cutover

If you don't have plenty of time, then you will need to execute in parallel ... and that's where the fun really begins with people designing, building and testing for multiple states in parallel across multiple environments in order to be ready to execute the cutover sequentially.

With that said I've been involved with different approaches over the years, for example:

1. Decouple by System

This is the most advisable approach where possible. It really comes down to ensuring all processes in each system are covered in the relevant transition state and that interface commissioning/decommissioning is well planned and executed.

2. Decouple by Division/Merchandise Group

<

Works where the divisions have largely separate legacy systems with low levels of overlap, so probably not feasible for you. If you try this by splitting out from a single integrated application I suspect you will open a 'Pandora's box' of modifications and testing. Normally the issues will come in POS, sales transaction auditing and reporting, but depending upon your current legacy systems, it may also impact purchasing, invoice matching (and/or accounts payable), inventory, transfers/allocations, pricing/promotions, e-commerce, planning and finance ... you name it.

3. Decouple by Location e.g. Brand/Country

This really has similar characteristics to decoupling by Division/Merchandise Group, but may be more feasible if your brands or countries are largely independent operationally.

Also On The Blog

• What is Oracle Retail?
• Oracle v19: What You Need to Know