We polled members of our team, based on their past performance, about potential pitfalls that people and organizations should be careful to avoid as they plan and execute their Drupal 7 exit:
- Running out of time and money before migration is complete. This is also, by the way, a case for agile web development because an underlying premise of agile is that you will never have enough time or money to do everything you want. So, you have to prioritize and focus on the most important things first. If and when you do run out of time and money, you will have assured yourself and your organization that what got done was, indeed, the most important.
- High cost of custom modules. A significant amount of work (time and money) involved in Drupal 7 to 8 migration is rebuilding custom modules. Moreover, there is also a risk in programmer errors and functional inconsistencies between the legacy module and replacement module. In addition, many contrib modules may not be fully ready or mature enough so you may have to invest time working on these modules as well.
- Content inconsistencies. Depending on the volume of content that needs to be migrated, it may make sense to automate the content migration process. However, with automated content migration, it is possible that content might not make the trip intact. Things can break or pieces of content could get lost or put out of order along the way. Make sure legacy content matches up to the new site because the chance of failure is high.
- Security risks. It’s also worth mentioning that if a company DOESN’T have separate environments for the D7 site, while building out the new D8 site, there is a security risk. If Drupal comes out with a serious security patch for D7, while building a D8 site on a testing server, with no D7 testing server, you would either have to wait and hope you don’t get hacked, or push an untested patch to production.
- Data inconsistency Because there can be some Drupal 7 modules that won’t be possible to have in Drupal 8, this can lead to data loss or inconsistency across the site. Moreover, migrating the functionality not covered by Drupal core or current contrib modules, that could be associated with some custom data structures, will impact time and budget.
In my view, one of the biggest risks in any major website migration (Drupal or not) is the complete lack of requirements documents typical of such projects. Because contrib modules are created to be as generic as possible to cover the maximum number of use cases, there are often unexplored dark corners that might be hiding undocumented website functionality. When recreating and migrating a site, it is very easy to overlook such things, which might be considered of vital importance to the customer.
For any non-trivial site, knowledge of how the site works is broken up into small fiefdoms. No one authority figure will know how every subset of the site operates. Identifying these knowledge silos (and their owners) and gathering this information into a centralized repository is a huge and unglamorous task. Those who ignore or devalue this task do so at their own peril.