Upgrading or migrating to a higher AEM version - Planning and process
0 likes234 views
The document outlines a comprehensive process for planning and executing an AEM migration, emphasizing the importance of defining objectives, assessing current states, and determining the target version for migration. It provides detailed steps for preparation, testing, validation, and stakeholder training to ensure a smooth transition while addressing potential fallback options. The document stresses the need for a well-documented process to facilitate both test and production migrations effectively.
Upgrading or migrating to a higher AEM version - Planning and process
- 1. AEM Migration – to a higher version A comprehensive process for planning & performing the migration Ashokkumar T A | 31-Aug-2019
- 2. Define 2
- 3. Establish the objectives Be clear on why you are doing what you are doing… • As-is vs. clean up vs. rewrite • List down all the objectives • Classify them into primary (must achieve) vs. secondary (nice to achieve) • Assign priority to each objective in primary and secondary (greatly aids in decision making during execution) 3
- 4. Plan 4
- 5. Finalize the target version Obviously to the latest version available right? • No… not always… • How stable is the latest version? • When is the next version due? Can we wait, especially when we need some of the features coming in the next version • Or to be safe, should we always migrate into version (latest – 1)? 5 Give due consideration to decide on the target version you wish to migrate your AEM into…
- 6. Assess your current state Document your current state if you don’t have one already • Topology of current deployment • Infrastructure details • OS and software version on the environment • Content repository size and sanity assessment of the content • OOB & custom components and services used by the application • Configurations and customizations done if any • User and usage volumes • Constraints and limitations in the current application • …. 6
- 7. Define target topology Your objectives might require a different deployment topology than your current one • Include all components when defining target topology – including integration, interface mechanisms with any third party systems, … • Validate the infrastructure for the target topology • Validate compatibility of OS and software's for target AEM version • Arrive at the hardware, OS and software upgrade/update requirements as needed 7
- 8. Agree downtime requirements Approach to migration depends on downtime duration availablity • Downtime of the systems for users vs. authoring downtime (Freeze on authoring) • Application could be generating UGC content • How much of content gets cached? • Can the application be served by content in dispatcher cache while the migration of AEM repository is happening? 8
- 9. Finalize the approach Now define the approach for migration • In-place upgrade vs. fresh install • Fresh install is more involved but would be required if the objective is to cleanup content or to change the deployment topology • In-place upgrade becomes more suitable if content is retained as-is with revision history and audit logs intact • Decide on fresh authoring vs. automated content migration in case of fresh install. • Could be some content are to be auto migrated while others are freshly authored 9
- 10. Prepare 10
- 11. Prepare for migration Build the pieces needed to perform the migration • Get ready the infrastructure with OS and software's as needed for the target state • Update & validate the code build for the target environment • Create all the scripts and commands needed for migration and validate them • Detail out the steps to migrate each of the components (Author, Publish, dispatcher) • Create a process document with a checklist – which aids the execution of migration. Let this cover all the steps – all pre-migration activities, migration steps and all post migration activities • Cover the testing to be done post migration and establish criteria to measure the success of migration • Include rollback, fallback procedures and create scripts & commands needed for invoking rollback 11
- 12. Test & Validate Perform a test migration • Preferred to clone the production instance and perform test migration on it • Follow the process as documented in the previous step. Update the document to reflect reality • Do not assume any step as trivial. Execute each step and validate it • Perform post migration testing and validate the success criteria – Has all objectives set for the migration achieved? – Application functions and performs in the target environment as expected – Is the migration performed within the downtime limit agreed • Perform rollback and validate the rollback procedure 12
- 13. Tweak and retest – if needed Accommodate changes and tweaks needed and redo test migration • Do not hesitate to go back to preparation step if needed to tweak the migration process • Update the migration process document and checklist to reflect the tweaked process • Redo the migration from the beginning • Essential to have a full end-to-end cycle done on test for the same to be repeated in production • Make sure you have a proven process, that’s documented which can be followed in prod for successful migration 13
- 14. Redefine development, Operations and DevOps processes Test migration is successful… You are sure of rolling it out in production • Time to align development, operations and devops processes for the new version • All lower environment can be migrated to new version • Maintenance procedures shall be updated for the new version • Assess the release cycles and plan for new releases in the newer version 14
- 15. Train your stakeholders Time to get all stakeholders excited about the new version • This is an essential part of migration that often gets overlooked • Include business team, developers, technical support, administrators and operations staff • Its not always a classroom training… self exploration, going through the documentation or video based… any such mechanism can be used for training • Remember… this is an important step to bring everyone onboard • Also this helps individual teams to prepare their work and innovate based on new version 15
- 16. Finalize cutover date On what date should be migration be complete and cutover done? • We know the migration should be complete by year end. But performing the migration on Dec 31st is not a good idea • You might have to choose a non-peak day and off-peak hours to perform your migration • Consult key stakeholders and agree on the migration period and cutover date • Agree on authoring freeze period if needed and cutoff access to authors during authoring freeze • Communicate the timelines and implication in advance to all stakeholders 16
- 17. Socialize the fallback options Things going wrong is not always your mistake, but not planning for it is definitely yours • Unexpected things do happen at unexpected time • Not sufficient to keep your fallback options ready, its equally important to socialize it with all stakeholders • Keep the key decision makers well informed of implication of each of your fallback option so that they can take quick decisions if and when needed 17
- 18. Perform 18
- 19. Migrate And… here you go… • Follow the document tested and validated • Avoid temptation to do any experiment or take any deviation • Stick to the tested process • If something goes wrong, access it quickly and kick off the appropriate fallback process • Hopefully everything goes fine… well you are not fully there yet!!! • Time to kick start the testing process 19
- 20. Test and certify the migration Perform all the testing and certify the success of the migration • Conduct the functional and performance test of the application • If you have crunched time window, you could perform a quick sanity test and declare the migration complete while continuing to perform elaborate testing • Validate the application to tick off for each of the objective achieved • Certify the success of migration after all the testing is complete 20
- 21. Adopt 21
- 22. The new normal Embrace the new normal • Adopt to the changes in development, operations and devops processes • And remember… sometime not very far from now, another migration is due… 22 More details at https://aem-musings.blogspot.com/2019/06/steps-to-plan-and-perform-aem-upgrade.html
- 23. Thank You 23 Feedback and suggestions welcome. Please write to ashokkumar_ta / ashokkumar.ta@gmail.com