When I came to the Ivan Allen College of Liberal Arts in late 2014, it soon became apparent that one very large project loomed in the semi-distant future: the migration of the college's primary website from a proprietary content management system to Drupal. Little did I know that we would not be able to start that journey until five years had passed, and that in the interim I would go through rebuilding all of our school websites twice (once in Drupal 7, and again in Drupal 8 a couple years later). In the end, those five years of experience prepared me for the "big one", but it still proved to be a year-long project, completed amidst the Covid-19 pandemic no less.
What made this project so challenging? The website was not on any standard proprietary content system - it was running on a system written from the ground up by a private outside developer. The foundations of that system were nearly ten years old, so there was little hope of being able to export and import page data in any usable format. On top of that, the site was large by our standards - even after stripping out all of the pages that would be delivered dynamically on the new site (news, events, faculty profiles, etc.) there were 231 pages to migrate over, plus several custom functionalities that our communications director did not want to lose.
Building a Plan
I have taught about migrating websites on several occasions, so I knew that I needed a master site plan before I started doing any actual migration work. With some content systems, this might be pretty straightforward to generate. With others, you have to call in Sherlock Holmes to find all of the existing pages. Let's just say that the great detective would have looked favorably at my sleuthing skills as I dug through the existing site to build a spreadsheet documenting all of the existing content. Even then, a few previously undiscovered pages turned up later on, but I had enough to formulate my plan.
As I had already brought all of our other Drupal sites up to Drupal 8, I had a good array of Drupal 8 tools already built, but one was actively in development when the project began: an implementation of the then new Layout Builder system. Fortunately, I knew the migration of the college site was on the horizon, so I used its existing common page layouts as templates for our Layout Builder implementation, meshing them with layouts used on our school websites to create a much richer layout system for everyone. In the long run, this part of the process would seem pretty easy compared to migrating the actual content.
While I did start development on Drupal 8, Drupal 9 came out halfway through the project period, early enough that I went ahead and upgraded the development site to Drupal 9 so that I could be sure that all parts would work with 9. Thus, ultimately, the production college website went from the old proprietary system directly to Drupal 9.
Migration Copy-and-Paste
Under the circumstances, this phase is rightfully called the Copy-and-Paste phase, as that was the best we could do. The old content system had a somewhat sophisticated layout system of its own, but it was completely proprietary, so there was no way to extract any of the layout configuration and port it to the Drupal site. Since 90% of the pages used the layout system, all we could do was sit and copy-and-paste page after page, laying everything out in the Layout Builder system to try to match the old site as close as possible. Along the way, I learned a lot about what does and does not work well in Layout Builder, and I ironed out a lot of wrinkles in my layout system toolkit.
One interesting case study area was our content manager's desire to have rows within a page layout that had an alternate background color going from browser edge to browser edge. At first glance, this might seem like a simple request to fulfill, but in truth it is riddled with issues. Our body section in our standard theme is configured with a maximum width, so to present a DOM object with an alternate background color that stretches edge to edge, you have to escape that boundary. This is possible with CSS, but there are some ugly browser calculation bugs that you have to work around to get there.
Equally important and easily overlooked is that being able to place the background color is only half of the problem. You also have to provide a way for the content editor to indicate where these alternate backgrounds should be used. Which means building configuration interface under Layout Builder for custom layouts. Custom layouts without custom configuration are pretty straightforward, but custom configuration requires building a special autoloader class and interfacing the layout template to it. Further complicating matters is that there's no simple way to enhance or replace the built-in Drupal layouts (one, two, three, and four-column layouts). So, I spent a while trying to figure out the best way to present these new background color options without making it too complicated or too confusing.
This is not to knock Layout Builder - it has many strong features, and hopefully in time the developers will improve on its weaknesses. One area where Layout Builder shined was in the way I could develop more straightforward custom layouts to solve long-standing layout problems, such as the dreaded photo gallery. Traditionally, these gallery layouts required a ton of extra modules and still felt cumbersome to set up and maintain — enough that I had begun promoting the use of external galleries, such as ZenPhoto or social media. By pulling upon the Drupal Media Library system, I was able to create a custom Photo/Image Gallery block that can be placed within Layout Builder. Simply add one of these custom blocks, upload your photos through the Media Gallery interface, and they come out lined up in rows of four standard size thumbnails across, formatted nicely with a link around the image and its title that links to the full-size image. The content manager doesn't have to understand how any of that works, as the Media Library along with a custom template and a little CSS handle all of the technical stuff. (See my previous Photo Gallery blog post for a technical description of how to set this up.)
Simplicity and Abstraction
When I came to the Ivan Allen College of Liberal Arts, the college had a few Drupal 7 websites, but they were in bad shape. One of the big problems with them was module overload, stemming from developers throwing far too many third party modules into the mix to gain unnecessary enhancements while often failing to fully remove modules they had decided they did not need. Thus began my quest to build better websites through simplicity and abstraction, a topic I presented about at conferences in 2015. As I look over the new college website, I am pleased that I was able to do so much with so few modules. The site uses thirteen third-party modules (not counting a few API modules) and twelve custom modules, each of which is well documented. That's a far cry from sites I inherited in the past with over a hundred modules including many custom modules with zero documentation.
Of course, some of the credit rightfully goes to the Drupal core development team, as core Drupal 9 can do a lot more than core Drupal 7, meaning less need for third-party modules to bridge the gaps. It's especially useful to have powerful features like Views, Media Library, Layout Builder, and Entity References built in and ready to use out-of-the-box.
Completion
As projects go, this one had an interesting race to the finish line. With our communications director retiring at the end of 2020, the goal was set to launch the site by then, and we made it just barely, launching in the middle of December. Even then, we were not able to have nearly as much review of the site as either of us would have liked, so as 2021 has progressed I and our new communications director have been discovering all of the little issues that fell through the cracks.
When I added it up, the amount of content we moved over (all by hand) was staggering:
- 231 pages (not counting faculty profiles and Mercury news/events)
- 702 layout builder blocks
- 1,043 document and image files
Lessons Learned
-
It would be easy to say, "Never run your main website in a completely proprietary content system that is supported by exactly two people," but reality is that you don't get to choose what you inherit when you come into a job. Most people reading this are not likely to put something like that into place — they're most likely having to deal with something built by the people who came before them. When life gives you lemons, just make sure you do your best to turn them into high quality lemonade. (I like to add a little raspberry flavoring, but your tastes may vary ;-)
-
The planning spreadsheet was a complete life saver. I could not have kept track of everything involved in the project without it. However much time it takes you to build it out, you will save far more time later on when you need to locate content or verify what has and hasn't been copied.
-
Never promise the impossible, but don't rule out the improbable. Know when to be gentle but firm about something that simply isn't going to work, and know when to take a week to review the possibilities even if you are certain a request is impossible. You might find something that you missed, or something new that didn't exist the last time you checked. And, if you still feel the request can't be fulfilled, the client might be more open to listening to you if they feel like you took time to do some research, even if you already know the answer. (There's an interesting analog that I came across with web UIs, in that some web UIs are purposely built to work slowly, simply because some non-technical end users refuse to believe that computers can do things as quick as they can these days. The unnecessary delay will actually reduce support calls from users who think the process didn't work because the "success" screen came back too fast!)
-
Perhaps the most interesting lesson is how "make the most of what you have" can come into play in the oddest of ways: During the first couple months of the Covid 19 pandemic, a lot of my normal project work disappeared, as no one was thinking much about new websites or rebuilding websites. Faculty were rightfully absorbed in trying to get their classes going online and figuring out how they would finish out the spring semester that way, all while dealing with the stresses of the pandemic that everyone had to face in that difficult time. Rather than sit back and twiddle my thumbs, I put all that time to good use and did a lot of content migration. Even though I knew we would have to go back and refresh some of it, just getting more of the then current pages into place provided a solid framework that helped ease the rest of the migration process.
Addendum
While there are a lot of things to like about Drupal 9, it is vital to understand that a modern Drupal website is not something for the non-technical user to build from scratch. A well built and well managed Drupal 9 (or 8) website needs to be built by and managed by a technically knowledgeable web developer. It is a completely different beast from Drupal 7 and earlier versions of Drupal, and while it can do a lot more, that technical complexity comes with a need for someone with the right skills to set up and manage the site and keep it patched on a regular basis.