The strategy to adopt, aspects to be taken care of, planning to be done and the process involved in upgrading or migrating an AEM installation to a higher version

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