This article contains an explanation from elfware CEO Hamish Cameron of various Oracle Retail cutover strategies, previously an answer to a question in a Q&A. 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:

Transition planning - define the states, what is performed where in each and how will you transition from one to the next
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.
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
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.
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, however usually purchasing, invoice matching, transfers and allocations are your key pain points.

4. Decouple by process area/functionality

e.g. Item and Master Data followed by pricing/promotions, purchasing etc in some order. This is the most difficult to achieve and I would not recommend it unless you have a very specific reason and the capability to manage the complexity.

Mitigating Cutover Risk Through Automation

The key to successful cutover - regardless of approach - is derisking through automation and repetition. The more you can automate every aspect of the cutover process, and the more times you can run complete cutover-style cycles, the lower your risk becomes.

Automate Everything

Every manual step in your cutover is a risk point. Focus on automating:

Data migration - Complete end-to-end automation from legacy extraction through transformation to loading
Data validation - Automated reconciliation and quality checks at every stage
Environment provisioning - Rapid standup of test environments that mirror production
Cutover runbooks - Scripted execution of all cutover activities with automated checkpoints
Rollback procedures - Pre-tested, automated rollback if issues arise

Run It Many Times

The real power comes from being able to execute complete cutover cycles repeatedly:

Practice makes perfect. Each cutover run reveals issues, refines processes, builds team confidence, and reduces execution time.

With proper automation, you can run:

Weekly cutover rehearsals in the months leading up to go-live
Multiple scenarios testing different data states and edge cases
Timed runs to validate your cutover window and identify bottlenecks
Rollback drills to ensure you can recover if needed

This approach transforms cutover from a high-risk, one-time event into a well-rehearsed, predictable process.

Data Migration Prototyping

Start early with data migration prototyping. The earlier you can get real legacy data into your target system, the earlier you can:

Validate solution decisions with actual data
Identify data quality issues and begin cleansing
Test end-to-end processes with realistic scenarios
Build confidence in the migration approach
Refine and optimise your automated migration processes

Parallel Running

Consider running legacy and new systems in parallel for a period. This provides:

A safety net if issues arise in the new system
Opportunity to validate outputs and reconcile differences
Time for users to build confidence in the new system
Ability to roll back if critical issues are discovered

Phased User Adoption

Even with a Big Bang technical cutover, you can phase user adoption:

Start with power users and early adopters
Gradually expand to broader user base
Maintain intensive support during initial phases
Gather feedback and make adjustments before full rollout

Conclusion

The choice between Big Bang and phased cutover approaches depends heavily on your organisation's specific circumstances, risk appetite, and available resources. While phased approaches may seem safer, they often introduce additional complexity and cost that can actually increase overall programme risk.

The key is to:

Honestly assess your organisation's capability and appetite for change
Understand the true cost and complexity of each approach
Invest heavily in automation of all cutover processes
Run complete cutover cycles as many times as possible before go-live
Start data migration activities as early as possible
Maintain clear communication with all stakeholders about risks and trade-offs

Most importantly, ensure you have the right expertise and support to execute your chosen strategy successfully. The organisations that succeed are those that treat cutover as a repeatable, automated process rather than a one-time event."

View all articles

Oracle Retail