This is an edited transcript. For the blog post and video, see Scary Drupal Migrations with Janez Urevc
[00:00:00] Michael Meyers: Welcome to Tag1 Team Talks, brought to you by Tag1 Consulting. I'm Michael Meyers, the Managing Director at Tag1. We have two special Halloween episodes for you. In both episodes, we're going to be telling scary platform migration stories. Cautionary tales to learn from based on experiences we've all had prior to joining Tag1.
In today's episode, episode 2, I'm going to be chatting with Janez Urevc, a top contributor to Drupal, the open source content management system.
Among his many contributions, Janez is the multimedia initiative owner who's been appointed by the founder of Drupal to oversee the design and implementation of the next generation of Drupal's multimedia capabilities. He's also a performance and scalability expert who's done many talks on the topic.
He's also the product owner for Gander, a new open source automated performance testing system that the Google Chrome team and Tag1 have been collaborating on. Gander is now a part of the Drupal core development workflow and will be there to help [00:01:00] ensure that Drupal's performance gets even better over time.
And as it's open source, it's also something that your organization can run to ensure that your sites are as fast as possible. Keep an eye out for the blog posts that are coming up and the team talks on Gander in the next couple of weeks. When you've been part of a lot of large scale migrations like Janez, you've undoubtedly run into some challenging situations and our hopes that in sharing some of these stories and things that went awry and the challenges that we faced will help you better navigate your platform migration.
Today, Janez is going to share the human side of migrations, the challenges that organizations face when it comes to navigating politics and staffing issues and other people oriented issues that you often face when changing tech stacks. As a company, there's a lot that you need to transition beyond just completing your tech transition to have a successful migration.
And yet the human side of things is not a topic that we often hear about when it comes to migrations. So I'm really excited about this talk. Please [00:02:00] remember to keep an eye out for episode one in our Halloween series with Benji Fisher, one of the maintainers of Drupal's migrate capabilities, where he shares two scary stories about the technical challenges that he's faced.
I'm joined today by Janez Urevc, who is my co host for the Tag1 Team Talk series. Janez, welcome and thank you for joining me.
[00:02:21] Janez Urevc: Glad to be here. Thank you for having me.
[00:02:24] Michael Meyers: So we're covering scary stories from our lives before Tag1 and we're going to anonymize, we're not going to cover, we're not going to say who these organizations are specifically. Um, but you know, you were the, Drupal Multimedia Initiative owner for many years. And you work with a lot of media companies. Could you just sort of set the stage for your scary story.
[00:02:46] Janez Urevc: So, um, when I, when I finished my studies, I had to feel, and I had my first child on the way, so I had to figure out what to do and, you know, based on a few,[00:03:00] um, unplanned things, I ended up doing web development and initially I started.
Working, or I was collaborating with a company that used their own CMS internally built. But I've always been a huge proponent of open source, even during my studies. And I also knew Drupal at the time. And I was trying to convince that company to adopt Drupal and open source in general, and they didn't really want to do it because they were selling licenses for their CMS.
So the first opportunity that I got to work on open source web technologies, I took that opportunity, like gladly. And that was My first exporter to media because that company where this opportunity arose was in the media industry. And then through that, I became interested in media and then naturally started contributing, ended up leading the media [00:04:00] initiative for Drupal 8.
And, because of my involvement in Drupal media and media industry in general, then later in my career ended up having a lot of clients from this industry.
[00:04:13] Michael Meyers: And I'm sure you've been involved in numerous migrations. I'm curious, are they, largely, you know, uh, older versions of Drupal to newer versions of Drupal, uh, other platforms to Drupal, a mix?
[00:04:27] Janez Urevc: Migration, the migrations that I've done throughout my career were for the most part from some other system to Drupal. We migrated media portals from other systems to Drupal 7 and then later I did a lot of migrations to Drupal 8 and 9. I've actually not done a lot of migrations from earlier versions of Drupal to newer versions of Drupal, but I have a lot of experience in migrating from third party [00:05:00] legacy systems.
And to add on that for all these migrations we always use Migrate module migrate tooling that we have in core now, when we were doing it into Drupal seven, it was not yet in core. It was in contrib space but very similar. And my experience with migrate was that it's really solid. Really featureful really reliable and even when, because now if you are, if you're migrating from an older version to Drupal to a newer version of Drupal, in theory, you have most of the plugins, most of the features that you need already built into Migrate, because this is the prime citizen type of migration.
But even if you're migrating from a legacy system, that's in theory, no other Drupal developer ever heard about Migrate still allows you to [00:06:00] execute these migrations with hardly any need for custom code, which I think tells a lot about how good how solid this system is. And yes, of course, I mean, of there are things that you have to do custom, but those are.
Mostly my experience were mostly related to the way content was created, not the way those third party legacy systems stored the data. in general, I was always happy with Migrate. It's a really nice tool, and I was very excited when, when we decided that it will become part of Core.
[00:06:37] Michael Meyers: Yeah, we'll have to do, uh, I mean, we're doing a whole series on the, the migrate subsystem and migrating to Drupal in general and various different aspects. Um, one of the things I love about your scary story, a lot of what we've covered in our other scary stories are, uh, technical fails or challenges that organizations have faced. Um, but you're going to give us a different [00:07:00] perspective today and cover a really important part of migrations. And that is. User adoptions and end users and you know, in order for a migration to be successful, you don't only need to technically execute it, but you need to facilitate success of the new application and the challenges that come with it.
[00:07:19] Janez Urevc: And a lot of those challenges can be people related. It was my experience. So a little bit of back story. I've been involved in a migration from third party CMS. into Drupal, and the specific of this case was that this third party CMS was not like a commercial product or some other open source CMS, but it was a proprietary internally developed CMS that a dedicated development team inside the organization built.
And you can [00:08:00] imagine that this sets the stage for some pretty strong opinions and emotions about things. Cause you have this team there which was not huge, but still has been with the organization for quite a while. And they love things that they built and it was working, but then the key decision makers realized that they simply cannot achieve the pace of innovation that they require in order to execute what they like to call the digital transition.
This is one of these media organizations that are like 50, 60 years old newspapers. Used to print newspapers on a daily or weekly basis or what have you. And now they were faced with this new reality where they had to be present on the internets. Or, and on other digital channels or delivery channels as well.
And they were figuring out how [00:09:00] to do it. And pretty quickly, they realized that this internally developed CMS while in theory, they should be able to add any functionality that they needed to it. The team was too small for that to be realistic. So they started looking into other solutions they pretty quickly decided that they want to have something that is open source.
Drupal was one of the, um, candidates. and then we, did a pilot project with Drupal and they were really happy with it. And they decided, okay, we're going with Drupal. We're going to replace like all usages of this internally developed CMS, uh, incrementally because they had multiple sites, um, and, start using Drupal from their own because they, they understood that the pace of innovation that we have in, in Drupal community is, uncomparable to what they could achieve internally.
The [00:10:00] problem was that. This decision was, obviously, was communicated with the internal team. But it either wasn't, either the internal team didn't feel that they were involved in the decision, which was probably true, or they wouldn't accept any decision that wasn't their own CMS.
It was probably a combination of both. But to say the least, the internal team was not very happy with the decision. And then myself and some other people that were familiar with Drupal were brought on the team basically as consultants. To help them transition and to teach the internal team to use Drupal.
But what ended up happening is that we were basically two separate teams. That didn't go along very well. And maybe one of the reasons was [00:11:00] that the transition was not... Quick, because they had so many sites that we started when we started transitioning sites to Drupal, they still had to maintain a lot of the sites on the existing platform.
So the argument as well is, Oh, like we can divide it like this. Then the team that is more familiar with Drupal will do Drupal. And the team that is more familiar with the old system will maintain the old system. But in reality, what ended up happening, we had two teams with a lot of rivalry and not enough collaboration
[00:11:36] Michael Meyers: So you have a group of internal developers highly resistant to the idea of moving to anything with a proprietary system that they build and another team coming in and migrating them off. I'd imagine they're not the most cooperative.
[00:11:50] Janez Urevc: , no, I remember like we had this training sessions , where we would, literally do like workshop workshops for them and explain, you know, how Drupal [00:12:00] works and how community works and how you contribute.
And then one of, one of the things that we adopted was, we adopted Drupal's coding standards also for our internal code which is what most of people usually do in my experience. And then, of course, then we had this discussion, why, two spaces, not four and whatnot. But then we set up this automated QA in place for all the pull requests to our internal projects that were rejecting everything that was not by the standard.
And then when we were talking about... Contributing to Drupal first thing that the other team did was they ran those checks on Drupal core. And of course it failed miserably because there were like 15 million problems with it because of, you know, all the history that Drupal went through and they were like, ha ha.
How are they going to force me to use this coding standard if they [00:13:00] can't follow it either? And they, they try to submit the patch to Drupal core, you know, you fix your problems and then I will start using it. And I'm like, no, no, no, no, no, no, no, let's not do this.
[00:13:12] Michael Meyers: What about management and leadership? it sounds like they didn't necessarily, engineer this transition very well.
Like, do you think that was a big part of this failure? You know, I can understand the
resistance from developers, but...
[00:13:26] Janez Urevc: I think that this was the main, probably the main problem, the leadership. I think that, I'm not entirely sure, but my, my thinking looking back at this is that leadership was too optimistic and too hopeful.
And they, I think that they thought that the problems would resolve by themselves eventually. Which... Usually doesn't happen, like if you let the snowball rolling without control, it usually goes in a completely undesired direction. And this is what basically happened here. I'm still not sure if there was a way to convince, um, the existing team to really become on board and become excited about Drupal.
But maybe there was a better way to manage it to prevent a lot of. Friction and rivalry and stress that resulted from that and then eventually even burnout because combined with this atmosphere that we had, we also had really crazy pace of working on new projects, sending them out, going live.
It was like 12 or 16 months of really crazy pace. So both these things together. Caused a lot of burnout in my opinion, and then the whole team or both teams basically dissolved to some extent.
[00:15:02] Michael Meyers: How did the migration itself go? Were you guys able to pull the migration off? , with all of these challenges, did it like blow the schedule, the budget, like what happened?
[00:15:12] Janez Urevc: yeah, , migration worked quite well. , we did. multiple projects, as I already mentioned, but we had one that was, like, by far the biggest. Um, and it was, , more gossipy, yellow media style kind of media portal, uh, with quite a lot of traffic, um, for our circumstances, , We did the incremental migration, which means that you build a new website Parallel to the old one that was serving live traffic we migrated data over and then we ran migrations on a regular basis to get new content that was created since
the, the last time migration run over to the new system, which allowed the content editors and other stakeholders to test the new site and see if, all the content is coming through as it should. And it looks okay. We were also migrating blocks on the front page. So when they expose something to the front page on the old site, it's immediately updated that.
On the new site. So it was, it was pretty, pretty well, well made migration in my opinion. , and then, but we were a little bit behind schedule. I'm not exactly sure what the reasons were. I think that we simply had more requirements. The estimates were mostly done based on hope, not on the actual estimating process.
So the hope was, oh, we will go out by 1st of June, and then we just caught all the requirements, and we figure out that it won't be possible. So mostly because of those reasons it, was postponed a few times, but then eventually we were ready and there was pressure to go live at that point but the problem was that the go live date was like, I think it was less than a week before the national parliamentary election, which is obviously a huge deal for a media portal and, uh the managers, like the leadership asked us, Um, you know, do you think that we can do it?
And we were all really young and really stupid. And a little bit too, brave. So we said, yeah, sure, we're going to do it, no problem. and we go live. And then on the night of the parliamentary election this portal was one of the first to publish exit poll results. And the results were quite surprising.
Because it was tight, but the polls before the election were showing that, you know, side A will win, but then it happened that side B won. So it was, everybody was super surprised. So we got this huge spike in the evening which we survived. There were a few glitches, but not the site didn't go down, but there were things like editors didn't know how to do certain things on the site because, they were not familiar with it yet because they just got it a few days before that.
But other than that, the site worked fine and the election night went through without any problems. We obviously had our hands on the back, but that's normal for situations like this. Um, Yeah, even years after that, when I got more experienced, I started thinking about that event and I was like, man, if things got really wrong that night, it would be, it would have been really bad.
But no. Back then we just felt, no, sure, we're going to do it. No problem.
[00:18:58] Michael Meyers: Either tremendous hubris or tremendous confidence.
Wow. Yeah, I mean, I don't know that every migration is scary, but at least I can say that every migration I've done is very stressful. And. You talked about working, really long days for a really long period of time, they definitely tend to stretch a team and, um, you know, it sucks that that organization didn't handle it well.
And, it sounds as a result of it, they lost both teams and, I wasn't too surprised to hear that they lost the internal team that, predated the migration. Unfortunately, I think that's pretty common. There's a lot of resistance. To making transitions. People are married to their technology choices, and some people do.
But, I would say it's 50 50, but it surprised me that the that the folks who came in also didn't last, in part because it sounds like it wasn't very [00:20:00] well planned and and the organization was challenging to work
with.
[00:20:05] Janez Urevc: Yeah, it also coincided, they, um, when things started falling apart, they also replaced the CEO and the CEO was really big supporter of this digital transition project.
And then the new CEO that came in was not really that much into it. They had to, like, they also wanted to cut costs because we, when I joined and after I joined, they increased the team quite a lot and that costs money. And I guess they also wanted to decrease the costs that, that, came with.
So they, they shrank the team and they switched priority and that was the beginning of my career back then. Some people that were on the team that were, not so much interested into constantly changing and, always getting on the bus of the latest and greatest thing. We're probably happy and mostly those people stayed with the company and people that wanted to live more stressful lives moved on.
[00:21:23] Michael Meyers: Wow. Thanks for sharing your scary story. I think it's an awesome perspective, the dynamics of the team and the people which are obviously critically important to the success of your company and your migration.
A huge thank you to Janez Urevc for sharing scary stories from his time before joining Tag1. Make sure to check out our other Halloween episode with Benji Fisher, another top contributor to Drupal, who's going to tell two scary stories about technical challenges he's faced in large scale migrations. If you like this talk, please remember to upvote, subscribe, and share it out. You can check out past Tag1 TeamTalks at tag1. com slash TTT. That's three T's for Tag1 TeamTalks. And as always, we'd love your input, feedback, suggestions on any topics. You can write to us at TTT at tag1. com. That's T A G, the number one dot com.
A big thank you to Janez and everyone for tuning in. Thanks for joining us. Thank you. Bye.