Drupal 6 and 7 were powerful work horses of the open source community. They were often chosen for applications because of the ease with which they could be customised, or a custom module could be produced to solve a problem. This has created two significant issues for end-of-life planning:
- The customised elements are not part of any automated upgrade process
- The developers responsible for such sites have limited Drupal 8 experience
These issues leave web project owners with a problem it is hard to see how to solve.
If you have a complex Drupal 6/7 site you may well be concerned about its future. Drupal 6 is in end-of-life already, and Drupal 7 end-of-life is planned. Whilst for many the migration tools in Drupal 8 will be sufficient, for others the path might be quite problematic with some developers recommending a total rebuild. How do you know where your site sits on that spectrum? If you don't know, then you cannot have a plan for the upgrade.
Our upgrade audit solves this problem for you by analysing your site and creating a viable plan for upgrading to Drupal 8.
The key to our Drupal Upgrade Audit is to start by ignoring the fact that your site is already in a Drupal version. We analyse how we would build such a site from scratch to take advantage of the best features of Drupal 8 within our i-ntarsia platform, and how we would give your site new opportunities. That creates the endpoint for our upgrade plan.
Once we have an endpoint, we then look at the technical aspects of moving from the current state to our desired endpoint. Given the nature of the Drupal 8 core upgrade this is not just a case of looking to see if the modules your site uses have been ported. Often contrib modules (even combinations of modules) were created to overcome perceived shortcomings in the Drupal core. If those shortcomings have been addressed in core we will identify a method to replicate the functionality using just core, making the availability of some module ports irrelevant. During this part of the process we will also consider if any new contrib or custom modules are needed.
Finally, we will look in detail at the data migration path. This is much more than simply looking to configure the migration module. In many cases the data structures underlying the functionality of the site will need to be changed prior to migration. In addition, the data itself might need cleaning or modifying to make migration more effective. Within the i-ntarsia platform we have a huge array of tools for HTML and other content markup manipulations which we use to smooth a migration.
The output of this process is a written upgrade plan and effort estimate. Whilst we may recommend the use of some tools that are specific to the i-ntarsia platform, these will be clearly identified and alternatives suggested. This makes the plan we produce for you something you could work with any developer on implementing.
OK A detailed technical plan enables you to undertake detailed financial and project planning
OK A third party audit provides confidence