AEM is still getting better. For those who weren’t able to stay updated, Adobe created the AEM Modernization Tools: free and fruitful. Let’s have a closer look.
SUBSCRIBE TO OUR BLOG
As the Adobe Experience Manager has been a success for a while already, a lot of iterations have made their way, meanwhile; and with every iteration, new functionalities have been introduced. Editable templates, core components and touch UI are just a few to name. Organizations that missed out are not getting the maximum out of the product. That's where the AEM Modernization Tools come in: a framework developers can use for updating legacy AEM implementations.
The modernization tools can be divided in four categories:
- Converting static to editable templates – and old container types to responsive layout containers
- Converting foundation components to the core components that were introduced in AEM 6.3
- Turning design nodes into policies, thus driving the behavior of the components on editable templates
- Converting classic UI dialogs to touch UI dialogs.
It's important to note that existing code will not be affected by the modernization tools. Thus, the code behind the new features has to be created first, and only then then the tools can be used, to migrate the content to be based on the new code.
Updating alternatives exist – but ...
Of course, there are still other options for migrating your content. You could ask the content authors to manually remake all the content in a new template. You could convert components. Or have your development teams create a series of scripts which can automatically copy the content. Depending on your situation, these can be valid options – but they do have some severe drawbacks, in comparison to the modernization tools. So, let’s make a comparison between the manual solution, the scripts and the modernization tools – under different aspects:
1. Time and cost efficency
The first aspect to look at are costs. As the modernization tools are free, the biggest cost – for all three options – will be the time spent by development team and content authors. The volume depends on the size of the project. A simple project with limited number of pages does allow authors to quickly migrate all content to the desired locations. But as projects grow, this solution becomes significantly less attractive, repeating the same action over and over, on every single page.
The time spent for the alternative two options is much less bound by the size of the project: No matter how many pages you have, you'll always need to set up a limited amount of configurations – which can be used to migrate all pages at the same time.
Creating the scripts will be a time-consuming process: You'll have to create a bunch of code from scratch and go through multiple development and testing cycles, before you are ready to start of the migration. And as time is money ...
That's why the modernization tools, with predefined and pretested functions, will help you keep time and costs lower. In the following graph, you can see a fictive example of how your costs could evolve, depending on the size of the project.
The AEM Modernization Tools:
Comparison of cost and time efficiency
Migrating content is often rather error-prone, so we also have to look at the precision with which migrations can happen. Both automation options obviously have advantages here, compared to the manual option. Especially with the task being so repetitive, human errors are more than likely. Automating the tasks will not take away all errors, but will make them much more straightforward and consistent. You won't have to check every single page for mistakes – which is necessary while migrating manually.
What gives the modernization tools an edge over the scripts is the fact that unit tests have already been configured, to make sure the code runs as expected. You could replicate this behavior in the scripts, but that would increase the cost tremendously, as discussed above.
The automation options take over the repetitive work from the authors. Ideally, a few clicks should allow all content to be migrated. Working with scripts, the development team can make them exactly as needed for your project. The scripts won't contain any excess code, as they won't ever be used in another context.
The modernization tools, on the other side, were created for as many situations as possible, so they will not be tailored exactly to your project. But the project is very extensible: If necessary, the development team can add or remove code that doesn't fit the specific need. Also, the four different categories of tools can run independently from each other, making sure you only have to use whichever piece of code you need.
Drawing up a summary, I definitely suggest to have a look at the modernization tools before initiating a content migration track. It gives a very strong framework for converting your content – and they can also be used as a starting point for custom scripts, if necessary for your specific use case.
For more detailed information on the perks of updating as such, have a look at the four key innovation themes in AEM 6.5, the best use of AEM core components and the six biggest business gains of upgrading to AEM 6.5.
About the author
Tim Melotte is an AEM consultant at Amplexor Belgium. He started his Amplexor career with an AEM bootcamp in 2017. Since then he worked as an AEM consultant for various customers, working with AEM, AEM Forms and Adobe Campaign Standard.