In this episode of Tag1 Team Talk, co-host Janez Urevc discusses a challenging migration project from his past. Janez shares his experience of migrating a media organization from a proprietary internally developed CMS to Drupal. The organization faced resistance from its existing development team, who were emotionally attached to their custom CMS.

His migration story serves as a valuable lesson on the importance of not only executing technical migrations successfully but also managing user adoption and handling challenges related to team dynamics and leadership.

The episode highlights the significance of planning, communication, and a well-structured approach to ensure the success of migration projects. The lessons learned from this experience can benefit organizations planning similar transitions.

Stay tuned for more insightful discussions on migration, Drupal, and other topics in the Tag1 Team Talk series.

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 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 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.

Glad to be here.

Thank you for having me.

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.

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,

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 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.

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?

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 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 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.

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 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.

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 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 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 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 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

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.

, 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 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 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.

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...

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.

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?

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.

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 well planned and and the organization was challenging to work

with.

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.

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.