The project was divided into several phases.
Phase 1 - Inventory and plan of action
The goal in this phase was to give Aarhus University insight into the available scenarios to make the right choices together.
To create the scenarios, we started with mapping the situation. Based on what we found, two well-founded scenarios were presented.
Scenario 1: all websites in one installation.
This scenario had the advantage that a few custom extensions that are focused on TYPO3 CMS 6 did not need to be upgraded. The disadvantage was the performance of the page tree.
Scenario 2: leave the installations and update all.
The advantage of this scenario was the better performance of the individual installations because they remain smaller. The disadvantage is that there is more customization required for the extensions that were based on TYPO3 CMS 6.
The second scenario was selected. Based on this decision, a plan of action was created. We decided to start with the multi-installation environment (an installation that consists of multiple websites) with the most extensions.
Phase 2 - The extensions
In this phase the focus was on the extensions that were used in all the different installations. We ensured that the extensions that worked on CMS 6 were made compatible with TYPO3 CMS 10. Through this approach, potential bugs were discovered earlier so the upgrade should go smoother.
Phase 3 - Testing and fixing bugs
After all extensions were made compatible with TYPO3 CMS 10 we started testing the migration.
During the test migrations, the up-to-date database was made compatible and merged with the new version of TYPO3 and the modified extensions. By automated testing this process several times, the team could detect and fix any bugs. These bug fixes were then applicable to almost all installations because many extensions on this installation also appeared on other installations. In total, three test migrations were done.
Phase 4 - Going live
By doing several test migrations, it was possible to go live with the first upgraded installations without any risk. Any bugs should have been discovered during the test migrations. When going live, the DNS of the domain name was migrated to the new environment. This prevented any downtime.
The going live phase consisted of several periods/sprints of 1 to 2 weeks. During this period MaxServ performed the migration and Aarhus tested the upgraded platform. To manage this intensive cooperation, good communication was of great importance. Therefore, daily stand-ups (daily's), evaluations (retrospectives) and review meetings were held.