Go to: Part 1 | Part 2 | Part 4 | Part 5
Step 8: Perform test migration and validate
With the preparation done, it’s time to perform a test
migration.
For direct instance migration, cloning the production instance and
performing the test migration on the cloned instance is preferred.
For fresh
install, plan to sync content as closely with production as possible when
performing test migration.
Execute the process as documented in the previous preparation
step. Follow the document religiously, updating the document if required to
reflect actual execution.
Cover all aspects of migration starting with the
pre-migration steps and following through to simulate cutover. Do not miss to
simulate rollback scenario so that you are prepared for the worst case if the
need arises when migrating your production.
Make sure to measure and validate the following in the test
migration
- All the objectives set for the migration are achieved
- The application functions and performs as expected in the target environment
- You would be able to meet the downtime limits agreed for the migration
Step 9: Tweak the process and repeat test migration (Optional)
This optional step can be applied if required. If you are
not able to meet any of your set objectives or if any change is needed in the
migration execution, make sure to update the migration document and repeat the
test migration starting from the beginning.
You may end up in situation where you have to go back to
preparation step (step 7) to cover for any gaps identified and come back to
step 8 to redo the test migration.
It’s essential to make sure a full end-to-end cycle of
migration is performed in the test environment to be absolutely sure of repeating
the same in production.
By the end of this exercise, you should have performed an
end-to-end test migration and have a proven migration document that can be
followed for doing the migration in production.
Step 10: Redefine the dev, ops and devops processes
After the successful test migration, you might want to start
aligning the development, operations and dev ops processes for the target AEM
version.
Also start planning the migration for your lower environments (Dev,
stage, …) to the new version. Update the maintenance procedures for these lower
environments for the new AEM version.
Development can also shift to the new
version and sub-sequent releases can be planned for the new version. Dev ops
process can now be updated for the new AEM version.
With the test migration successfully completed, we can jump
into preparing for the final migration run detailed in the next part
Go to: Part 1 | Part 2 | Part 4 | Part 5
No comments:
Post a Comment