What does ATG's end of life mean for your business?

Oracle ATG is now in Sustaining Support, with no ongoing patches, security updates, or ecosystem certifications. Although the platform continues to function, it becomes progressively harder and riskier to maintain. This is the inflection point—where maintaining the status quo gives way to planning a controlled, strategic transition.

Why should you act now?

Reasons to migrate from Oracle ATG:

OLR ATG Services

What can we do for you right now?

 Clients we have supported

ATG Migration Services

How do we guide your move off ATG?

Our tailored services provide end-to-end guidance, from strategy and planning through to full platform deployment. Whether retiring a legacy ATG estate or launching a modern commerce platform, we ensure a seamless transition that drives long-term growth and elevates the customer experience.

e-Commerce Accelerator

From legacy to live — faster than you'd expect.

Launch faster. Sell sooner. Souk Store Accelerator gets your catalogue, customers, and content live at speed — with conversion-optimised layouts built in from day one.

Souk Store Accelerator is OLR's answer to the time and complexity of launching e-commerce. Bringing together OLR's e-commerce expertise into a ready-to-run storefront, out-of-the-box features including loyalty, gift cards, and quick returns deliver a modern retail experience from launch.

Composable vs. Monolithic:
Is the increased complexity worth it?

One of the biggest decisions in your migration is what to migrate to. Before you commit to an architecture, make sure you're asking the right questions.

FAQ

Here are some of the most common questions:

Customisation is expected in most ATG and Oracle Retail environments, and it forms a core part of our migration assessment. We take a structured approach to understanding what has been built, why it exists, and whether it still needs to exist. We start with a full assessment and catalogue of all customisations — covering business logic, workflows, and integrations — and a clear separation of core platform functionality from custom extensions.

From there, we determine which elements should be retained or replatformed, simplified or eliminated, and whether they should be replaced with out-of-the-box capabilities available in the new platform.

This approach deliberately avoids a lift-and-shift of legacy complexity. The goal is a target architecture that is simpler, more scalable, and aligned to modern commerce models. This reflects standard enterprise migration practice, where legacy customisations are re-evaluated rather than directly replicated, reducing both complexity and long-term technical debt

Data migration is handled as a controlled, structured process, with integrity and business continuity at the centre of every decision. The approach is designed to ensure that nothing critical is lost, corrupted or left unvalidated in the move to the new platform.

This begins with full data mapping and validation across all key domains — products, customers, orders, inventory, and beyond — followed by data cleansing and preparation before any migration activity takes place. Staging and test migrations are run to validate accuracy ahead of the live cutover, with parallel validation in place to confirm that reporting, transactional history, and customer data remain intact throughout.

The core data domains in scope are:

• Customer profiles and purchase history

• Product and catalogue structures

• Order and transaction records

The measure of success is that each of these moves cleanly and completely, without impacting trading capability, reporting accuracy, or the customer experience. A migration that introduces data gaps or inconsistencies creates downstream problems that are costly and disruptive to unpick — which is why validation at every stage is non-negotiable.

Modern migration approaches are designed to keep your platform live throughout the transition, eliminating the need for a hard cutover that puts trading at risk. In practice, this means running parallel environments where the old and new platforms operate side by side, allowing thorough validation against live conditions before any traffic is moved. Common deployment strategies such as blue-green or phased rollouts build on this by allowing traffic to be switched incrementally and rolled back instantly if an issue is detected.

These approaches minimise or eliminate downtime by gradually introducing changes rather than switching everything at once.

Phased migration is the preferred approach for complex ATG environments, as it reduces risk and avoids a “big bang” cutover. A typical approach includes:

1. Assess and segment

• Understand the full platform, integrations, and dependencies

• Identify low-risk and high-impact components

2. Build and integrate new services

• Develop new capabilities in the target platform

• Ensure they integrate with both legacy and future systems

3. Run in parallel

• Legacy and new components co-exist

• Business continues to operate as normal

4. Gradually shift traffic

• Move functionality incrementally

• Validate each phase in production

5. Decommission legacy components

• Retire ATG features as new services take over

This “incremental replacement” model allows organisations to migrate at their own pace, maintaining business continuity while modernising the platform.

For most modern retailers, composable commerce offers significant long-term advantages, greater flexibility, independent scalability, and the ability to adopt new technologies without overhauling your entire platform. However, the right architecture depends on your business objectives and where you are in your commerce journey. Read our latest article to understand how to make the right architectural decision for your business.

The value of composable commerce shows up in faster deployment cycles, easier maintenance, and the ability to respond quickly to changing business needs, but only when the right foundations are in place. If those aren't there, even the best architecture will underdeliver. Read our latest article to understand what those foundations look like in practice.

A well-structured composable architecture should reduce complexity, not add to it. If upgrades are slow, integrations are fragile, or your teams are working around the architecture rather than with it, those are signals worth investigating. Read our latest article to find out what good looks like.