Migrating from Workbench Moderation to Content Moderation.
Services
Team Leadership

When the Commonwealth of Massachusetts first built their Drupal 8 site, they started in Workbench Moderation that allowed their authors to write content and put it into various moderation states such as “draft” or “needs review”. With over 600 content authors on the platform, this is a vital piece to help ensure content on the platforms meets their requirements. At the time of build, Workbench Moderation was in core and Content Moderation had not reached a stable release yet. Drupal 8 introduced Content Moderation in core and as part of our ongoing engagement with Mass.gov, we were asked to help with the heavy lifting associated with the upgrade in an effort to keep their site supported and up-to-date. The Commonwealth found this to be a greater challenge than expected and relied on LCM to facilitate the right migration path.

Our first step in initiating the migration was to investigate what we were dealing with. At the time, mass.gov had around 600,000 revisions with a moderation state that needed to be migrated from Workbench Moderation to Content Moderation. We started off by digging into Content Moderation’s code to fully understand the complexities and layers of the switch. We found the systems to be very different and with no pre-designed migration path, we deduced that we needed to create a handmade migration path from scratch, outside of a standard Drupal 8 migration. Once the initial configuration of this path was set up, the process was just to keep building the migration through trial and error and figuring out the fastest plan of action.

We knew that switching from Workbench Moderation to the new core module, Content Moderation meant the mass.gov site and its authors would benefit. For a government site, security is always a concern and therefore a top priority. When working with a core module, it is actively supported for security and for any updates that core has as opposed to still running on a contributed module. 

After we felt sound on the coding portion of the switch, we wanted to make sure we were in alignment about expected workflows, transitions, non-transitions, and revision states. We started with around 20 transitions in Workbench Moderation that we were able to consolidate to 5 transitions in Content Moderation for a more optimized workflow. 

We also worked on rebuilding some views such as the “all content view” and mass.gov’s specific dashboard called, “MyContent Block”, which contains all the content the logged in author is watching. 

After a successful switch, mass.gov users are leveraging Content Moderation to moderate content. We are implementing a patch to Content Moderation for the view for “filter by moderation state”. This filter was missing some indices that would cause MySQL to incorrectly do a full table scan instead of an indexed scan of content that caused a lot of performance issues. We ended up writing a patch to include the missing indices that would bring down the query load time on the “MyContent Block” view from 15,000 milliseconds to 200 milliseconds. We plan for this patch to be made available for other sites experiencing the same issue with a lot of content like Mass.gov does.

Overall, the goal was to make the switch as seamless as possible and create little to no changes to the content authoring experience. On the module itself, content authors did get some smaller UI changes such as the submission process with dropdowns for moderation states. When it came to deployment, authors trying to make changes during this window would have experienced downtime but we were strategic enough to initiate migration on Memorial Day weekend and experienced no content loss.

When we started the migration path, the expected migration time was 15-20 hours. When we executed deployment, we got the time down to 4 hours through our optimization efforts. The migration was incredibly successful on deployment and we experienced no issues!