Whenever i get to hear about an opportunity about migration of a platform, i normally get into split mindset. From a technical standpoint, it gives an opportunity to re-factor your tactical fixes which would be there in any platform that would have existed for a while. It also gives an opportunity to leverage some of the new features the platform would have implemented (be it through organic changes or changes done due to acquisition of a complementing platform) For e.g.: If we take a platform such as ATG 10.*, there are substantial changes in the platform. Namely, Endeca has replaced ATG Search, Multi Site capability has been introduced out of the box to support multi-brand and multi-country websites. While these are good enough case to migrate from an existing platform to a new platform, it becomes difficult to convince business groups especially if a multi store capability already exist (albeit it is a custom implementation) and if they are happy with the Search capability that already exist.
So, there is always a struggle to create a business case for a migration of a Technical platform and hence to get the required budget to do such work. But still it makes it an absolute necessity to migrate from one version of a platform to the latest. That is where the role of an IT director and Architect slightly gets challenging and powerful as well. I normally take the approach of doing Show and Tell (i.e. demo the features) as much as possible to showcase the benefits and get buy in from Business groups early in the project. i.e Set the expectation correctly so that there are no surprises later.
Having convinced Business group of one our clients in a similar way, lets see what all we need to worry or rather think about if we have to migrate from an older version of ATG platforms to a ATG 10* platform. I am covering largely the data related challenges here.
Choosing the right migration approach
At a very high level, you can have two approaches:
- Approach 1 – Migrate from 9.1 to 10 using ATG provided scripts and perform data migration
- Approach 2 – Recreate the application using the new Common Reference Store and new version of ATG
Use approach 1 if timelines for migration are less and you are not absolutely sure of all the features that are already build and more importantly if you are not aware of usage of current data
Use approach 2 if the current implementation need lot of re-factoring and there are lots of time to do development and testing. In reality, you will end up choosing mix of approach 1 and approach2.
Schema and Data Migration
Irrespective of the chosen approach, the data is of paramount importance. In eCommerce, the key data elements are:
- Catalog, Category, Product, Sku and Related Data
- Promotions and other Marketing/Sales Data
- Customer and Order Data
Catalog and related data
So, when you are migrating, one need to look at the above in isolation. As you know, the Catalog data is completely in a different schema in ATG. I.e. ATG_SWITCHING_SCHEMA’s. You will have hence two option to migrate this schema.
- Either you can export and import from old schema or
- Recreate the whole catalog in BCC and do a Full deployment.
First option is preferred. However, as ATG 10 introduces the concept of Site, it is suggested to create the Site Group, Site Category and Site information manually, then import the Product, Sku, Category data and then attach the catalog to the respective sites.
- The nuances we got into were the fact that the “related products” were used to provide Product Recommendations and also to address quite a few things. When we migrated, the related products started appearing in the Cross Sell Menu bars etc. So, look for places where data is used to drive logic and make sure it is used correctly.
- If the products are expired (i.e. No longer in sale), the tendency is to cleanup such products when you move to new platform. Don’t do that! Carry the products as not having them will not allow old orders having the expired product to be opened in CSC. You will not realise this during migration. The impact will be seen later when CSC wants to deal with some old orders.
Customer and Order data
This is the most critical data and you need to make sure not a single attribute would get missed. Now, the big decision is to decide whether to migrate the entire PRODUCTION_CORE schema or should we move the data into the new ATG 10 schema in an incremental fashion. We took the former and the same is recommended by Oracle as well. The biggest risk of choosing this option is that you have to move the schema on the day of cutover as well. We took this calculated risk and made sure that we had rehearsed the schema migration before the day of migration multiple times.
Nuances: In ATG 10.1, to ensure higher security, a new password hashing algorithm called SaltedDigestPasswordHasher is used. This uses SHA-256 algorithm with a random salt. Prior to ATG 10.1, the default profile hashing used to be DigestPasswordHasher component. This used MD5 algorithm. Now, to make your existing profile password to work properly in ATG 10.1 onwards, you need to enable the MD5 configuration layer while building the .ear (i.e. When you assemble your application.
Migrating Card Data
If your website is built on top of CRS 10.2 (ATGs Reference Application), then you need to worry about this. The older version of CRS uses DES encryption method for encryption/decryption while CRS 10.2 uses AES encryption/decryption methods. So, we have two options:
- Option 1 – Change CRS 10.2 out of the box behavior by forcing it to use DES algorithm. This requires to introduce the DES component of ATG 9 into ATG 10.2.
- Option 2: – Write code to decrypt the card numbers from Live in ATG 9. And, then write code to encrypt the cards numbers in ATG 10 and write to ATG 10. The source code is available from ATG 10 CRS.
We picked option1 as option 2 requires changing the data.
Orders would get migrated as part of the PRODUCTION_CORE schema. However, if you need any information that CSR would provide such as Notes related to Orders etc, then make sure the AGENT Schema is migrated as well.
Migrating promotion is again tricky as the promotion as an entity (or table) does not exist. It is the rule that qualifies an item, order or both for an offer. So, when we talk of migrating a promotion, we talk of migrating the rules. Now, based on when the rules has been applied, certain data elements are derived. For e.g.: the coupons linked with promotions, to be used by customers, end up in “active promotion” property of customer profile and if the coupon is used, then it will end up in “used promotion” property of profile. Now, what if the active promotion property has a promotion that has already expired? Do you migrate the expired promotion as well? Business groups would not like that. So, you may end up in deleting the active promotion property. If you take that option, then you need to worry about what if the promotion that you are deleting is active? Would this change the behaviour of the site and would customer perception get impacted?
So, we suggest few things:
- Do not have any promotion active on the day of cut over as much as possible
- Remove the active promotion property from users profile.
- Create new promotion rule with the same promotion id as it was in earlier platform.
ATG 10.* handles Site id differently. You need Site Ids to all the data elements be it catalog, products, targeters, orders etc. So, when you are migrating make sure the Site id is captured and moved correctly across all schema’s (including DATA LOADER schema’s so that your reporting is done correctly.
While the above covers only the data, there are few other configurations and API related stuff that need to be thought through while carrying forward from ATG 9 or older versions to ATG 10. For e.g.: In ATG 10.*, Cybersource module is no longer supplied with ATG installable and we should reach out to Cybersource directly to get the Integration APIs
We will cover these things later some other day!