For years, Oracle ATG was one of the most popular e-commerce platforms among enterprise commerce companies. The Java-based, server-side platform was designed to be an all-in-one solution. Licensing is expensive, creating a degree of vendor lock-in, but the platform comes with a robust set of features, more than you’ll likely ever need.
Over time, e-commerce technology has evolved significantly but Oracle ATG has not kept pace. The platform was never really modified to adapt to new sales channels and changes in consumer behavior. Being tightly coupled, it is difficult to scale and does not enable brands to effectively create modern hopping experiences.
Many companies are now migrating from Oracle to a headless architecture. Instead of a monolithic on-site solution, a headless setup is built using decoupled cloud-based platforms and microservices.
Retailers looking to move away from the Oracle e-commerce platform to a headless solution have to decide on how to approach their migration. Fortunately, you can transition to headless commerce without the costly downtime normally associated with changing platforms.
In this post, we’ll go through the steps you can follow to seamlessly migrate from Oracle ATG to a headless commerce architecture.
Follow the steps below to understand what it takes to move from the Oracle e-commerce platform to a headless commerce solution powered by a modern platform like Fabric.
Taking a modular approach to migration decreases the risk of downtime and increases your ability to ship new features faster. For this, you’ll want to use an API gateway as a middle layer. Doing so will allow you to run services from both Oracle and your new system while the transition takes place.
You can start moving individual services away from Oracle by using the API gateway to route calls to your new backend components. As a middle layer, the gateway sends calls between Oracle ATG and your new system. This allows you to continue using Oracle’s frontend features while you build out your new system.
You can then focus on implementing one new service at a time. Building piece by piece helps you better monitor the effects of your changes. If you ever need to revert to your old setup, you just replace your new routing calls with the old ones.
Your Oracle ATG system will likely have a large amount of data that you need to move to your new system. There are several ways you can export the data. First, you can export from Oracle to an XLS or CSV file. Another way is to export the entire database to an XML file.
When moving data out of Oracle ATG into your new system, you need to look at how it is stored and see if you want to replicate the existing data structures or make changes.
Once you’ve exported your data, you can use JavaScript to pipe it into your microservices. One way to do this is through AWS. Amazon will use TypeScript and SQS to copy the data from your old database to the new services. The AWS documentation explains this in more detail.
Below is an example of how you can adapt that code to transfer product data to your new services.
const { SQSClient, SendMessageCommand } = require("@aws-sdk/client-sqs");
const REGION = "us-west-1"; //replace with your region
const params = {
DelaySeconds: 12,
MessageAttributes: { // adjust this to your data if different
id: {
DataType: "Number",
StringValue: "543",
},
displayName: {
DataType: "String",
StringValue: "Pure Cotton Regular Fit Shirt",
},
manufacturer: {
DataType: "String",
StringValue: "Mark's Shirts",
},
version: {
DataType: "Number",
StringValue: "3",
},
},
MessageBody:
"Clothing Store Product Data.",
QueueUrl: "SQS_QUEUE_URL", //replace this with your queue URL
}
const sqs = new SQSClient({ region: REGION});
const run = async () => {
try {
const data = await sqs.send(new SendMessageCommand(params));
console.log("Success, product sent. MessageID:", data.MessageId);
} catch (err) {
console.log("Error", err);
}
};
run();
After you add a service, you should test everything to make sure all is working properly before moving on to the next service. Approaching the migration one step at a time makes it easier to actively monitor any changes to ensure no bugs have appeared.
The modular design of Fabric’s commerce services gives retailers the ability to upgrade their e-commerce architecture without impeding their existing operations. We call this The End of Replatforming™.
You can gradually replicate only the features you need from ATG, not those you don’t use. When you’re done, you’ll have a new system that is more agile, scalable, and built for modern commerce.
Tech advocate and writer @ fabric.