I was contacted recently to assess the work involved in an upgrade of a corporate site with 14 verticals in a Drupal 7 multisite installation. In 2018, I embarked on the migration of eight verticals from a context driven Drupal 7 website to 8 separate WordPress installs. In short: I know what it takes get a website migrated away from Drupal 7.
Goal
The goal of the project: move from one codebase delivering 14 standalone websites running Drupal 7, to 14 standalone sites using a common code base and running Drupal 8. All of the data, all of the credentials and all of the configs would be preserved or improved upon.
The Review
I did a review of the codebase and a partial review of the databases.
A rundown of what I discovered that impact migration speed and success: there were 14 verticals in a multi-site set-up each with their own URL. The automated upgrade process would need to be executed on all 14 of those sites.
Modules
There were 79 contributed modules in the core; most of them have an upgrade path from Drupal 7 to 8. Also, some of the modules in the codebase were not active. For the sake of consistency, all of the present modules needed to get upgraded. There were two additional modules in the Careers site. There were three modules referenced in the corporate Installation profile. There was a module build by an agency, but the other two were commented out from being activated.
The list of modules (in sites/all/modules) held 26 modules of varying complexity. Some were almost one liner modules; some were very elaborate. In a quick review of the code, I saw a number of places where the code in one custom module referred to another custom module with no contingency check to see if the other module was active before being referenced. The code would all have to be rewritten for Drupal 8 and those module cross-checks would have to go into the mix. These do involve the cross-site API calls, so they are key to the overall functionality of the sites and communication between the sites.
Some elements that are common in a Drupal install:
- Views – the views found across the 14 sites would have to be re-built for Drupal 8
- Panels – migration automation handles some of this, but the Panels presence assumed some rebuilds.
- There was no Context module active. That simplified the process.
- Vocabularies and terms are well used. The migration would handle that but their use would have to be assessed for their role in the custom modules (some of those custom modules lean heavily on taxonomy to build navigation and workflows).
- There were seven libraries in use. That’s not a massive amount and they were well supported elements.
Themes
All of the satellite sites used the corporate affiliate site, which was a child of the corporate main theme. It doesn’t appear to be build from an existing theme, so the migration to Drupal 8 would require a theme rebuild in Drupal 8. The theme does lean on the custom modules for the display of context and some of the navigation.
Our Estimate
Web asset preparation, project management and meetings create some overhead. On a project of this scope, that would amount to 14 development / meeting days.
The automated update will take about three hours per subsite. That extrapolates to 5 development days (@ 7 hrs. of billable time per day). My experience has been that the we can get lucky and have a very fast automated update, but it’s often the case that something interrupts the update that has to be mitigated and then the update can resume.
Converting the 30 custom modules will range from very simple to very complicated (varies from module to module). I will look for ways to expedite the update of the custom code as I originally would have forecast a median of a day per module (one would take 30 minutes; some will take three days). I estimate that to take about 30 development days.
Redoing the base theme; the main theme and the affiliate themes will take approximately: 12 development days for the base; 3 day for the main theme; and 1 day for the affiliate theme that is used throughout the sites. As we are not revisiting the design (the styling), I was going to remap all of the existing layout and CSS to the Drupal 8 modules. The mobile experience of the legacy code is usually something that need review and repair when jumping from Drupal 7, but the standing code looks solid in responsive views.
Views and panels will take about 1 to 3 hours per. Across the sites, that medians out to about 30 development days.
QA will be a significant element as the sites are locked up in their current state and the new incarnations have to work as well as the old were intended to work. I want to put an hour of QA per site to assess and mend what is found: that extrapolates into 4 development days. Ideally, this element of discovered issues and their repair would need more time.
Combining the above figures comes to 99 development days. What does a conversion like that look like when it comes to budget? The estimate is $56,000. While that is a hefty price tag, it means the per vertical conversion costs something less than $4,000 per vertical.
