Migrate from Oracle ATG to fabric

In this article, we’ll talk about the advantages of microservices-based commerce and how it can help grow your business. If you’re moving from Oracle ATG and want to learn how and why to make the switch to microservices, we’ll explain what you need to know and show you some simple examples of how you can migrate your data.

Why Microservices over Oracle ATG?

• Security: Microservices allow you to take full control over your online presence. Their modular nature allows you to tune everything to your needs and update specific elements at any time. With security issues arising regularly, a fixed system like Oracle ATG can easily leave you stuck. If a security issue appears, you need to wait for a patch, and then update the whole system.
• Technical Limitations: Oracle ATG uses old technology. Developers need to understand not only Java, but also ATG’s Nucleus framework. That’s highly specialized, and it makes finding and retaining people who can update your system more challenging. There are also dated technologies like Java Server Pages, which are slow and harder for developers to work with than more recent alternatives. Features like dynamic pricing, advanced search, and cross-channel real time inventory availability are difficult or impossible to implement in Oracle ATG.
• Flexibility: Oracle ATG is a large, comprehensive system, so breaking out from the way it does things is difficult. With a headless system, your backend and frontend are not tightly coupled. You can add different frontends for different platforms and delivery channels, and provided these use a consistent API, they won’t need to be updated every time you change the backend.

Planning the Oracle ATG Migration

Online platforms offer so many features it can be hard to know where to begin your rebuild. Let’s talk about some of the core features that should be top of your list.

• fabric Product Catalog: Storing product information is a crucial part of most online stores, with many businesses storing a huge amount of data. Transferring this to a new system accurately and automatically is a key first step when transitioning to a new system. With a microservices-based backend, this data can be available for use across the whole set of services you offer, and once it’s there, it won’t need to be reformatted or reentered for new systems.
• fabric Orders: Getting this right is essential and shows customers they can trust your site with their information. Mistakes can put people off ordering entirely, and that costs you money. Building this system with microservices means you can perfect everything and use the backend to support a range of frontend services, where you can focus on the presentation and delivering the best user experience possible.
• Supporting Services: Aside from those already mentioned, Oracle ATG has many features that you’ll need to replicate if you want to move away from it. There are also some you might not want; not replicating what you don’t need can make your new system more agile and manageable. Oracle ATG’s core services include ID generators, scheduling, and random number generation, which may be useful but also showcase its unwieldy, monolithic nature. Take a close inventory of what it does, start by replicating what you need most, and work from there.

To move services away from Oracle, you can use the API gateway pattern to route calls to your new backend replacements. That way you can sidestep Oracle’s backend architecture while continuing to use its frontend features.

With your gateway in place, you can focus on building new services one at a time, which allows you to effectively swap out legacy services. The gateway can send some calls to Oracle ATG and some to your new system. That keeps things simple and allows you to monitor the effects of your changes. It also means you can easily revert to your old setup if needed. Just replace your new routing calls with the old ones in the gateway or service mesh.

If you have an existing Oracle ATG setup, it probably has a large amount of data that you need to transport to your new system. One way to do this is to export it from Oracle to an XLS or CSV file. Another is to export everything in the database to an XML file.

ATG includes a huge number of services in its API. When rolling your own setup, you will want to replicate some but not all of this functionality. As well as having a more streamlined, focused set of services, you can also add API features that do precisely what you want.

To get data out of Oracle ATG into your new system, you’ll need to look carefully at how it is stored and see whether you want to replicate or change existing data structures. If data is transferred from one property to another, you’ll need to decide whether to make changes and if so, how.

The following table is a list of properties used to store product data, sorted by how each property is set.

ATG Control Center	Catalog Maintenance Service	Other
auxiliaryMedia	ancestorCategories	catalogs
childSKUs	ancestorCategoryIds	catalogRelatedProducts
description	parentCategoriesForCatalog	creationDate
displayableSkuAttributes	siteIds	dynamicRelatedProducts
displayName		manufacturer
endDate		parentCategories
fixedRelatedProducts		parentCategory
id		type
keywords		version
largeImage
longDescription
productInfos
relatedProductGroup
relatedProducts
smallImage
startDate
template
thumbnailImage

For more details, check this documentation.

After exporting, you can use JavaScript to pipe the data into your new microservices. Here we’ll walk you through an example of how to do that in AWS.

Amazon can copy the data from your old database to the new services using TypeScript and SQS. Have a look at the documentation for more details.

Below is an example of how you can adapt that code to transfer product data. Only a few fields are included here, in the message attributes.

Note: This article only begins to tell the story of migrating from Oracle ATG to microservices-based commerce with fabric. We are currently creating an Oracle ATG migration playbook with more detailed information.