HCL V9 Top Ten Lessons Learned

BlueSky Commerce, a top-tier HCL Commerce partner, has led many V9 projects – both implementations and migrations alike – for our HCL Commerce clients. We polled our technical and business consultants to summarize the lessons learned from some of these projects to share with you.

Our V9 projects have varied in size and complexity. We have led projects for clients who have unique business or technical needs to be factored into the overall project, like the desire to include user experience enhancements or migration out of IBM’s Cloud environment, in congruence with the V9 upgrade project. One of our favorite new implementation projects was for HCL themselves. BlueSky was selected to implement HCL’s renewal ordering portal on V9. This project was slated to go live before the transfer of business from IBM to HCL was finalized, and was successfully completed on a tight timeline.

Since the newest version of HCL Commerce was introduced, many HCL Commerce clients have completed or are in the middle of their migration projects. There are also many clients who are still making plans to upgrade to Version 9 sometime in the foreseeable future. There is plenty to factor into your consideration like timing, budgets, priority over other projects, etc. So, once you decide to make this jump, we thought it would be helpful to have some insight and feedback from real-life V9 projects.

Here are BlueSky’s Top Ten V9 lessons learned based on the experiences of our architects, business analysts, and project managers:

1. Invest in DevOps and Automation
   • The move to a container (Docker, Kubernetes, etc.) structure requires skill sets that are different than managing the environment in V8. If you do not have this knowledge in-house, plan to invest in training, new staff, outsourcing, or a combination.
   • All the various jobs will need to be “migrated” which really means they must all be rebuilt. This is an opportunity to optimize the entire job schedule.
2. Minimize Feature Enhancements with Migration
   • Enhancements should be minimized to differentiate between issues that are from V9 migration vs. from release enhancements.
   • Ideally, as best practice, the V9 upgrade should be done on its own to mitigate risk.
3. Be Aware of Potential Solr Search Migration Complexity
   • If you are planning to do a “lift and shift” to V9 and stay on Solr Search, it may require some changes to search and business processes.
   • Example: In V9 there is some additional optimization in the search pre-processing step for building the index.
4. Environment Planning: Resources Requirements
   • If planning to migrate to V9 on-premise, be sure to allocate time for resource planning. Although the application containers are lightweight, the management containers that are native to Kubernetes need to be accounted for.
   • If you have to provision servers in batches and are on a tight timeline, building the production environment first is recommended.
5. Plan for Discontinued Asset Management Tool
   • When IBM released V9, they removed a management center tool named the assets tool. This tool provided the business user the ability to upload files directly within CMC and then reference them as needed. Example files include marketing images for use in eSpot content, owners manuals, and user guides to reference on a product page, etc.
   • If you are using this feature, a migration of assets should be planned and a new solution for file management must be found. Using an SFTP file server or HCL Digital Experience (DX) may be good alternatives.
6. Involvement of HCL Support
   • HCL’s support teams are available to be leveraged throughout V9 migration projects. We’ve found it beneficial to include HCL’s team on regular calls to ensure alignment as challenges arise.
7. Performance Testing and Tuning
   • We’d recommend baseline performance testing followed by post-migration performance testing and tuning to ensure that you are taking advantage of the potential performance improvements by moving to V9.
8. Practice Go-Live
   • Practicing the migration processes is a risk management strategy that provides several benefits. Among them are validating the duration of the various migration steps and the overall migration timeline and any associated downtime. Practice also validates that all needed access to various systems is available, steps are included and are being executed in the correct sequence and all dependencies are properly considered.
9. Go-Live with Little Downtime and Rollback Planning
   • Minimizing the downtime during migration is important from a lost revenue perspective. A migration can easily be 12-16 hours of downtime. Strategies to reduce this downtime can be put in place – such as locking down changes to a registered user’s profile a few days early and migrating registered users ahead of time, reducing the amount of order history to be migrated, etc.
   • Rollback planning is a standard risk management strategy and just as important as the migration plan itself. Understanding how to roll back if something goes wrong and what data will be lost is important.
10. Post-Go-Live Plan for DevOps Changes and Training
    • It is crucial to plan time for team education and ramp up on new tooling and processes of this new architecture.

These are some of the lessons our team has taken away from V9 migration and implementation projects over the past few years. Are you planning a move to V9? Let’s connect so that BlueSky can help you plan and execute your project.

Contact us to set up some time to discuss your V9 plans.