So, we know the move to Drupal 8 or 9 is going to be expensive. We know it’ll be time consuming. But what about some of the benefits of migrating? On today’s episode, Blake and Brie talk about ways to improve your site through a migration and some things to look out for along the way.
Visit The Agile Podcast website.
Blake Newman [00:00:06] From Washington, D.C., I’m Blake Newman.
Brie Ripley [00:00:09] And I’m Brie Ripley.
Blake [00:00:10] And this is the Agile Podcast. Where we explore the stories and people behind agile web solutions.
Brie [00:00:16] And on this season of the show, we’ve been talking all about Drupal 7, which is reaching its end of life, if you didn’t already know, in the year 2022.
Blake [00:00:27] Even though that date seems like a long way away, you should consider moving right now. A migration to the next version of Drupal could take months or even years.
Brie [00:00:34] And as we talked about last episode, the move will likely cost a fair amount of time and money.
Blake [00:00:42] Maybe millions of dollars, depending on your web site. But today we’re going to talk about how to put that money to good use and what to watch out for during a migration. Some highs, some lows.
Brie [00:00:53] Roses and thorns.
Blake [00:00:54] Peaks and valleys. And all this ties back into agile software development.
Brie [00:00:59] Because, of course, it does.
Blake [00:01:02] Of course it does, it’s the Agile Podcast. Brie, do you remember when we talked about the waterfall method of software development way back in the first episode of this series?
Brie [00:01:10] Vaguely, but here’s what I remember: it’s like the idea where you spend a lot of time gathering all the project requirements and then you go away for like an even longer period of time to build the product. And then finally, at the end, you debut it.
Blake [00:01:28] Right, and that’s the product. Not a lot of customer input along the way, except the requirements at the beginning of the project. Developers disappear for a while with those requirements. Then they come back with a product, ta-da, that might be outdated or might have something that you as a client don’t even like and maybe the original stakeholders aren’t even there anymore.
Brie [00:01:47] With agile, I’m in the loop, so to speak. I’m troubleshooting with developers and project managers. I’m giving them feedback along the way to make sure that they understand everything and the product evolves with the time.
Blake [00:01:59] Right. And so you can be involved early on. You might find something on a beta version you don’t like or something that doesn’t work.
Brie [00:02:06] At least not the way it used to.
Blake [00:02:09] And if that’s the case, you can tell the developers immediately and they can fix it. In waterfall, on the other hand, you would only find these things at the very, very end of the project. But then it could be too late.
Brie [00:02:21] Ah. So, agile is a way to at least identify pitfalls early on in migration so that problems can be corrected.
Blake [00:02:28] Exactly. Nipped in the bud. Plus, in agile, we set up clear prioirties. When something doesn’t work out just how you want it, you can ask yourself, is this is really important? Or are there other priorities? When things go smoothly, you can meet more of a client’s needs. Let’s say you end up coming in under budget. The client might have some functionality they want added.
Brie [00:02:49] If you don’t come in under budget, at least you get the features and functionality delivered that the client needs. If there are pitfalls and roadblocks along the way, you can focus on what’s most important.
Blake [00:03:01] All just makes things easier for everyone. Problems will arise. It’s almost inevitable. We’re going to talk about some of the worst ones because no migration’s perfect.
Brie [00:03:10] All right, let’s jump into it. Pitfalls.
Blake [00:03:13] Pitfalls. So, the first pitfall is just running into things you don’t know will be problems. We talked about this a lot in the last episode with unknown unknowns, but I have a good example of this that Jen Lampton ran into. She’s an independent Drupal developer and co-founder of Backdrop CMS. Here’s Jen:
Jen Lampton [00:03:35] What I found in Drupal 8 is that the way in which this software is really different in Drupal can sometimes end up requiring extra investment. So, for example, I have a lot of sites in Drupal 7 that are heavily using the file entity module.
Blake [00:03:50] This feature basically allows you to add fields to an image.
Brie [00:03:53] Things like captions or a photographer credits.
Jen [00:03:56] The user interface for this is really different in Drupal 8. And so we’ve been having to add a bunch of additional features to our sites to make that editors comfortable with using it. And so it’s the kind of thing where initially you’re like, okay, here you go, give this a try. And they’re like, we can’t use this and we’re like, what do you mean? It’s sort of the same. It’s familiar. And they’re like, no, no, no. This doesn’t work with the way that our editors interact with the site.
Blake [00:04:18] And suddenly you need to change what you’re doing because the Drupal 8 module is unworkable for the client.
Jen [00:04:23] Okay, well, we’re going to add these four modules. They’re going to improve the experience of, you know, the way that you manage entities, the way that you browse for them, the way that you can edit them. But then they’re like, okay, well, now we can’t delete, I need to delete this PDF. It’s like, oh, that doesn’t exist in Drupal 8. So we’re gonna go through a new, entirely new, interface to do that. So there’s just some stuff that you don’t necessarily know isn’t gonna work because it’s completely different than it was before.
Brie [00:04:50] So you rebuild a site in Drupal 8 and then something just doesn’t work.
Blake [00:04:56] At least not the way you used to. And you, as a client, might have to learn to do something differently. That might mean new training.
Brie [00:05:03] Ugh, training. I know all about. From being trained to training others how to use a CMS. You know, I wish it was easier. Sometimes it’s just it’s just not easy.
Blake [00:05:16] But if developers are agile and incorporating client feedback than they can at least address these problems earlier. If it’s important to the client, they can make changes and then find new modules or new ways of doing things that work for the administrator or author of a web site.
Brie [00:05:30] And if you’re about to embark on a great migration, it helps to have a good idea of what functionality you have on your CMS and then to prioritize that functionality so that you know exactly what you need before you move.
Blake [00:05:43] Virginia, a project manager at Agileana, says that making a list of functionality on your current web site is a must before starting a migration.
Virginia Alvarez [00:05:50] Creating that inventory of functionality is the best thing you can do because it not only helps you kind of guide the way you’re going to be planning your migration, but it can also help you decide what things might not be worth migrating because you definitely are not using it anymore. And when it comes to testing, you just have the list of things you need to test right there.
Brie [00:06:12] Okay, so this pitfall will probably happen?
Blake [00:06:16] Maybe some contributor modules or custom code won’t really work as well in D8 or D9, though, some may work better. You might just have to get used to a new system or new way of doing things.
Brie [00:06:26] Okay, so hit me with another pitfall.
Blake [00:06:29] Little disclaimer. For the most part, all these pitfalls land on the client. Sorry Brie.
Brie [00:06:33] No.
Blake [00:06:35] Yeah. I mean, you can lose all your data. I mean, this is rare, but not unheard of. Here’s Jen again.
Jen [00:06:42] For example, if you are migrating a bunch of content into a site and maybe there’s like a news content type that contains news articles for the last 10 years or something, and maybe because the client doesn’t care about these, they don’t create new ones, it’s just an archive. They don’t check. You launch a new site and then a month later, they’re like, all our news is missing. Like that would be a huge nightmare. You then have to go back and figure out like, okay, quick let’s migrate the content and hopefully, you know, we’ll put it on the new site and it’ll be fine.
Brie [00:07:15] Oh geez. Fingers crossed. So how do you avoid this?
Blake [00:07:18] Well, first of all, you should back up everything.
Brie [00:07:21] Control + S.
Blake [00:07:24] But you should also be very clear with your team of developers or project managers that like, hey, this is really important.
Brie [00:07:30] Right. But like, sometimes you don’t know it’s important until it just is. So what then?
Blake [00:07:37] Well, that’s why you should hire an agile team so you can be involved in the process as it’s happening. Hopefully you’ll end up seeing that some data wasn’t migrated that you need and you can send up the flare.
Brie [00:07:48] Okay, so next stop on trip through migration horrors.
Blake [00:07:52] Losing your configuration. So, it’s one thing to have your Drupal setup and your data, but these config files have all the settings, the permissions, the authors, the search, the cache, the storage — all that.
Brie [00:08:03] A lot of little settings that you’ve been working on. And if you lose that, it’s gone. You have to write everything all over again.
Blake [00:08:11] Here’s Jen again.
Jen [00:08:13] What I would be afraid of losing would be that configuration.
Blake [00:08:16] Jen says that this is something she’s more afraid of in the move to Backdrop from Drupal 7, but it can happen in any migration.
Jen [00:08:23] And if you happen to delete the directory that contained all those configuration files, you could lose the configuration that controls everything about your site, like the data architecture and all that.
Blake [00:08:34] It’s possible to lose all that work.
Brie [00:08:36] That sounds terrible.
Blake [00:08:39] Well, it’s not the end of the world, but it could be a major inconvenience.
Brie [00:08:42] Okay. So can we talk about improving your site through migration?
Blake [00:08:47] Thought you’d never ask. And can we talk about agile for a minute?
Brie [00:08:50] What if I said no?
Blake [00:08:52] But this is the Agile Podcast.
Brie [00:08:54] All right, I’ll allow it.
Blake [00:08:55] OK. This time, let’s talk about iterations when you rebuild your new site. It’s a new iteration of your web presence. You can try to improve your site, see what works, make improvements.
Brie [00:09:05] Right, since you’re rebuilding much of your CMS, why not build it the way you want as opposed the way it’s been? Try something that better suits your needs.
Blake [00:09:15] Yep. And by migrating your site, you’re just inherently making it better. I mean, that should be the case. If you go to the latest version of Drupal, you get a more updated and modern site. It uses object oriented programing.
Brie [00:09:29] OOP?
Blake [00:09:29] Yep, O-O-P. OOP. Now your Drupal 8 or 9 site is gonna take up more server space, but it could also go faster than you D7 site. Here’s Jen.
Jen [00:09:37] Drupal 7 was something, you know, everybody who had a very complicated site started to notice how slow it was at the end.
Blake [00:09:44] And you get Google search engine bonuses if the site is faster. Drupal 8 and 9 aren’t like lightning fast. They do take much more server space than a Drupal 7 site would. But the site is more modern. And if you go to something like Backdrop CMS or WordPress, well, that hopefully better suits the needs of your organization or company. So just by migrating, you’re inherently improving the site.
Brie [00:10:04] Right. But. When a migration does go smoothly, sometimes it feels like you did all this work, paid all this money and spent all this time for a website that just looks the same. Like, I know that my site is up to date or more secure. I know that if I moved to Drupal 8, then move to Drupal 9, it should be pretty easy. But I don’t really get to experience those things. Like my site looks the same. It’s running faster, a little bit smoother.
Blake [00:10:30] OK. So, Jen runs into this all the time. And when the client is feeling a little bit unsure about making a big investment in upgrading their site, she tries to package the move with a rebrand.
Jen [00:10:42] The easiest way to sell them on the upgrade is to combine the upgrade with an investment that does give them a return. So, something like, oh, we’re gonna do a rebrand. That’s perfect because you have to build a new theme anyway, you might as well put them on a platform where you would have to build a new theme at the same time so they’re not doing it twice. So, now it looks like a savings to them rather than an investment into nothing because they don’t get exactly the same thing out that you started with.
Brie [00:11:10] Makes sense. Maybe you haven’t rebranded since you migrated to Drupal 7 in 2011. Since you’re tearing everything down, why not rebrand?
Blake [00:11:19] Why not? And if you’re doing that, you might as well rethink the functionality of your web site. Does it fit your target audience’s needs?
Brie [00:11:26] Right. The world looks different right now than it did even a year ago. Update your site. Think about your audience. Rethink your web site to meet that audience where they are.
Blake [00:11:37] Well, yeah. And one more upside of migration is that you can clean up your code. So if you have deprecated code or maybe some developers put content functionality into templates.
Brie [00:11:46] Which you aren’t supposed to do.
Blake [00:11:49] Right. This is a great time to clean that all up. Start fresh.
Brie [00:11:56] OK, so migration is a great chance to think about what your web site was missing and add that functionality. Hopefully this next iteration of your website will work better for your target audience.
Blake [00:12:07] Or you can do a brand refresh, fresh site, fresh look.
Brie [00:12:11] And sure, there are probably going to be some pitfalls along the way. You may lose all your data or configurations, but you know, that’s unlikely. It’s more likely that some of the modules are used to just won’t work anymore. So you’ll have to find some workarounds.
Blake [00:12:24] But if you’re in on the process …
Brie [00:12:28] Ahem. Agile.
Blake [00:12:29] Then you can hopefully find out these sooner than later and deal with these problems as they come up.
Brie [00:12:33] And in the end, you’ll be in a new CMS, one that better suits you and your organization’s needs.
Blake [00:12:40] We’ll have two more episodes on Drupal 7 migration on the Agile Podcast. But I just want to recap where we’ve gone so far.
Brie [00:12:46] Drupal 7 is reaching its end of life in November of 2022.
Blake [00:12:52] But you should move as soon as possible. It’s a big investment of both time and money to move out.
Brie [00:12:57] Because you’ll likely have to rebuild your entire site.
Blake [00:13:02] You can go to Drupal 8 or, more likely, Drupal 9. Future migrations should be easier.
Brie [00:13:07] Or you could go to Backdrop CMS, a fork of Drupal 7. It’s great for smaller sites currently in D7 that like where they’re at.
Blake [00:13:15] Or you can go to a different CMS altogether, like WordPress. It all depends on what are your needs.
Brie [00:13:20] Migrations take a lot of time and a lot of money.
Blake [00:13:25] But hopefully after all this is over, you’ll have a better site when that benefits your needs.
Brie [00:13:30] Next week, we’re talking to Tim Lehnen, the chief technology officer at the Drupal Foundation, about what’s happening at Drupal and what he sees in the CMS’ future.
Blake [00:13:39] So stay up to date by subscribing to the Agile Podcast on Apple podcast or wherever you get your podcasts.
Brie [00:13:45] And won’t you please leave a review while you’re at it? They actually really help us. Thanks for listening.
Blake [00:13:50] Talk to you next week.
Blake [00:13:55] The Agile podcast is produced by Agileana, a DC based web development company. To learn more about Agileana, you can visit our web site, Agileana.com or send us an email to [email protected]