 Thanks everyone for joining this session. We will present the journey and the experiences of Novartis.com to migrate our Drupal site from Drupal 7 to Drupal 8 while making a drastic transformation of the portfolio of website. But before we start let me say a few words about the company. That's not a sales pitch, don't worry. So Novartis is one of the top five pharmaceutical company in the world with the ambition to be among the top three. Our team, the channel management team is one business group within the company and we are responsible for all the corporate channels. These include the excellent-facing website such as Novartis.com, the intranet and the social media. Today we're gonna have Marchello, our technical guy, myself responsible for the platform and operation, specifically Novartis.com, the flagship of their organization and then we have François, content guru, who will be discussing the content part. Our team is mostly based in Basel, Switzerland, but we also have people in the U.S. and in India. Therefore we cover the full range of time zones. Now before we start I would like to make this session a little more fun and understand this is the end of a long day and maybe you had a few crazy nights. Therefore we need to have something to keep you awake. The goal here is to have a few queries and every time you'll hear you'll know that's the time for you to open your eyes and to show how smart you are. So if you have questioned yourself please keep them for the end of the session. We have a Q&A. What is a corporate website you might ask? So a corporate website is the place where we provide information about the company itself, the history, the leadership, talk about the strategy for us about the disease we're trying to cure. We have a few things about communication such as press releases and stories. We also display the jobs opened for the public but we do not sell medication or we do not do marketing. From a figures perspective we have a website covering 60 countries, a very large set of visitors and then therefore a large page of number of page views. We also have a lot of integration, technical integration on that system and our website are covering mostly 30 plus languages. Then finally the industry where we deal, the pharma is extremely strict. So things such as data privacy for patient is a top topic as well as we're dealing with patient. Accessibility has to be on top of our mind because of impairment they might have. On the operational side we also have to deal with a different constraint. We are a newsroom therefore we have potentially some news coming up at any time of the day or the week. Novartis.com is also a publicly trade company therefore we also use Novartis.com as the channel for the financial results and you can guess a 50 billion plus dollar company. Those data are pretty confidential if they are published before the official time. And then finally coming back to this larger set of countries we have a large set of stakeholders to deal with. So before getting into the why and the whole trip that we have done I need to provide you with a small background to understand the situation. So many years ago when the world was young we had a set of website with content. They were all kind of different from a technology perspective from a content perspective and nothing was the same. In 2014 the C2HC2 has changed. Our group was created and we started to have a platform based on Drupal 7 that was the first almost in the industry open source and we provided a platform with the share technology, share set of features and shared governance. That was a big success that helped to make everything more consistent. Like everyone on Beluga perhaps a small thing the name of the project the goal and the name of that project was Beluga because Beluga are usually standalone animals that group together when they migrate in the summertime. 2019 like everyone you heard about the end of life for Drupal 7 which was at that time scheduled for November 2021. So we faced a big question. We had two paths. The first path which was fairly easy is to tell IT to take all the Drupal site that we had to move from Drupal 7 to Drupal 8 and as you understand before we are business so we asked IT to do it. We wait and then when it's done we celebrate. IT is here. The other path slightly more complex is to review the portfolio and perhaps to ask ourselves that question. Is there an opportunity to do improvement and here then that could be a very long journey. Genius is like going through a jungle with a machete and you know what some people like to suffer. So we went through that long path. We did a lot of analysis. What we needed is not something based on gut feel but really based on data and we also had to have a really strong business case in order to justify all the cost we would have. The outcome was to take all those website that we had all those country website and to bring them all on the one single umbrella of what is.com. So every country website will be slot into what is.com into the way it was described here. So global at the top and country section underneath. The reason for that are multiple. First all the country would benefit from the SEO authority from what is.com. So what is.com has a very strong authority and any pages of what is.com in Google would be ranked better than any other pages from Novartis country website. So by putting those country website within Novartis.com then they benefit from that authority. Second by merging everything under this concept making this consolidation we have to use that business model to define if we keep a site merge it or close it. That will help us to justify some merger and everything. Third we could go through a content consolidation. So the idea here would to put all the global corporate content at the global level and have the country just manage their local country content with this distinction then we have a simplification of content to reduce duplication. And then finally at that time and even now many countries are going through this kind of consolidation having one single website to manage all the countries and we also want to be part of those cool guys. So if we go back to that journey that we described before so went to that silo architecture which was a little messy. Went afterwards with the Belga 777 which was quite a big success and we leverage all those benefits to build on top and put more things about the content SEO with its domain name strategy. So the new program was called Arctic and now question for you. So what were the two main reasons for naming that program Arctic? You have 20 seconds to answer. T-shirt to wins. Any suggestions? Okay go ahead. That's perfect and the congratulations. Impressed. Exactly. So in fact the first reason is because Belga are migrating to the Arctic in summertime and then really the Arctic no country owns it. It's kind of a council of multiple countries managing it the same way Novartis.com is kind of an umbrella for multiple countries. That was the idea behind. So going further you understand that such a large program with so many countries so many stakeholders we had to had a very strong structure to manage it. What we did is to put these initiatives into seven different streams to manage that thing and then to discuss about some of those streams I'm going to invite our colleague François to discuss about the content. Thank you Pierre. I'll take the mic I'm a bit too tall for this mic. Thanks Pierre for the introduction. So yeah I really thought how to present the content and information architecture part I'll call it IA of the program and I thought the best way to do it would be just to drive you through a couple of questions we tried to answer in the scoping and phasing of the program. These questions are extremely simple right but actually they're not so simple to answer. The why question is something Pierre already dealt with remember the Arctic end of life sorry Drupal 7 end of life and various business specifications. I will deal with the when how and what question so when do we migrate how we did it and what we migrated and I will let my colleague deal with the where question at the end of the presentation. Right so into the when so as Pierre said Novartis is quite a big company we have yearly plenty of communication activities going on so it's quite it's not so easy to find the right moment to migrate a huge website as Novartis.com as you can see I already spoiled the date it was in October 2021 but of course plenty of things happened before so to choose the date the thing is that Novartis we have very clear period of times right end of year like November December are usually the medical congresses period like ESMO, ASH end of October is usually our Q3 financial results so it's in a way no way for us to migrate a website at this point. On the other side begin of the year is extremely easy as well you have big forums like World Economic Forums, GPMorgan and we also have our Q4 financial results begin of the year so actually October 8 was a great date for us right after the soft period of the summer and just before the busy period at the end of the year. So as Pierre said we went through a planning and scoping phase where we tried to answer the questions you saw on the previous slide and we started on migration you saw a little bit of a logo migrating and we had a chance during the migration period to migrate two global sites Novartis Foundation and Novartis Bayum which are very similar to the Novartis.com website since they are global and monolingual so it was great training for us before Novartis.com migration. You see we allowed ourselves two to three weeks of freeze period count and freeze just avoid any discrepancies when migrating. So a big first achievement for the team was October 2021 but now that wasn't the end of the project and not even half of it. We then had to migrate 55 countries through six ways of migrations and as you can see the whole project took approximately three years which is kind of a long period of time and it was a tremendous amount of work to participate in this project. Worst to keep in mind that 2020-2021 where of course the Covid years so it impacted the project as well having to work from home and adapt to the new world was something. Now going to the how we did it well it's of course it's a valid question how do you migrate eight global sites 55 country sites more than 20,000 pages dealing with 200 borders approximately and everything in 17 months for the global sites. Well one of the big fighters of course a manpower you need you need you need people to do the job right and that's what we did we hired contractors for planning and scoping we hired a company also to help in the one mastering job so we had a team of approximately 10 webmasters to support us. Important to note that the global sites were migrated manually we didn't have any technical migration for them. I will come back on that under what we migrated because it's actually one of the reasons why we did a manual migration we wanted to do to get the extra mile content wise. Country though where we had a technical migration for them mainly for the big bulk of the migration like nodes and file system but all nodes were always hand revised by the group of 10 webmasters so it was quite a huge job right. Of course when you do that you go through tons of Excel sheets and believe me we went through them these are just examples from that com Novartis.com sorry but what's really interesting is what is within these Excel sheets so the content itself as you know websites are nothing without the audiences behind them so that leads me to my little quiz so on Novartis.com according to you what's the largest audience in terms of visitors on Novartis.com note that I added some icons just for the industry specific audiences so patients and healthcare professionals. Now do you have an idea which one is the biggest one in terms of numbers? You can take a guess yeah good job yeah and actually by quite a margin it's more than 50% of the traffic on Novartis.com knowing that we have approximately 9.5 million visitors per year and 32 million page views you can imagine the number of people coming just for the career section of our website so into the what we migrated question well I think the main important part is we didn't want to be the two guys on the right side of this picture right so this migration was a great opportunity for us to improve the site clean the pages improve the navigation and that's what we did content-wise so as we have said Novartis.com is quite an old site we've been accumulating lots of content press release story articles various content types and this migration was a great opportunity just to clean up so we reviewed our retention policies make sure it makes sense delete outdated content and it was very useful for the migration which actually simplified it a lot something we went bold on was the navigation so in on Drupal 7 in Beluga that was an example of the top one navigation so very traditional our company our focus our science very simple but it works right it it makes the job but for this type of navigation you have two problems at least we face two problem the first one is these kinds of element can change right companies change their focus change a lot so it implies a lot of content changes as well since we were migrating without maybe there's something to do here second big downside is more Novartis specific our communication strategy is very much audience focused so we just went bold on it and we decided that would change our first-level navigation to really bring audiences at the first place and that's what we did so as you can see that's an example of the top one level navigation patients, HCPs, media but investors, partners, suppliers you could name them all and that's actually very useful because audiences don't really change for websites right in the farming industry you will always have patients you will always have healthcare professionals so that was actually a great argument for changing the whole navigation to say very high level I just would like to go a bit deeper in one specific subject we we changed for the for the site and this topic is ESG so I don't know if you heard about ESG before it's environmental system social and governance and the reason I'm talking about this is because in Drupal 7 we had a very nice section called corporate responsibility and it was including pages like environmental sustainability access to health care this kind of topic right but when we changed navigation we faced a problem that was where to put these elements and actually we had another candidate that we didn't know where to put where everything related to reporting codes policies and guidelines transparency and disclosures these kinds of topics right and what's cool with ESG it's actually a generic term a whole theme that contains all that are just coded so both access to health care more environmental topics but also a bit of more financial topics like reporting etc so we created whole section to merge all the content and it was very helpful for the migration right the downside to do this company focused navigation and moving to a audience focused navigation was of course redirect because if you change your level one navigation you end up with hundreds of thousands of redirects and that was actually a pain with for the team but nevertheless Drupal is pretty strong to manage redirect so that was fine right now I will let my colleague come to the stage and talk you more about the where we migrated question so much hello please so so I'd like to take a step back before answering them to where question talk about the main technical challenge that we have the first one was switching from a multi domain approach to a single domain approach and managing everything under unique domain umbrella the second one is we are running a multi site and share core base instance so configuration management was a challenge so I'm gonna list some of the example of some of the challenges that we had and then the last one is financial results so we had to find a way we can prepare confidential content keeping it secret and non accessible by authenticated users so multi domain and single domain okay so we had the option to go with one huge database for all our multi sites or we had the option to have local database and separate database for each site of course we went with local and separate database mainly because of local regulation data privacy GDPR and also because the data needs to seeds within the site jurisdiction then another requirement that we have was having the same underlying code base so that's why I mentioned before share code base deployment must impact all sites simultaneously and then the last one is site are available under the same domain which is the main topic so this side explain what we went through from the multi domain to the single domain we have to include an additional piece of information here which is the language identifier as you can see on the right side which we didn't have before and we include these also on monolanguage sites so for example Germany we will have DE and DE duplicated so we have two options here we could go with the domain based approach or we could go with the path based approach of course we went with the path based approach because it fits more the requirements that we had how we did it we leverage the domains dot PHP file where we map the front end with a back end and in this case as you can see you have two different front end one CHDE which is the Swiss website in German map to the Novartis CH database and also the CHFR which is the Swiss website in French map to the same database it works but there is a bot as you can see there is like a backend URL and the public URL Drupal needs a language identifier especially to to build multi language capabilities and to translate content but we don't need this identifier when people visit the website through the WWW so we had to remove this additional information from the public URL we actually didn't have to just remove it we need to reflect this information within the URL prefix the CHD and CHFR so we kind of develop a little bit some custom code in the configuration we were able to specify this for value the country code language code backend URL and public URL and with this information available we were able to build a logic to do this transformation that I showed you before an additional challenge that we have which is also similar to kind of related to this additional language identifier is the the site map HTML which as you can see in the slide it contains the additional slash DE or slash FR which we don't need when we use it for WWW so with a little snippet of code we managed to solve this but unfortunately well after the migration to Drupal 10 this is broken again so we are currently fixing it the second challenge is configuration management which is a hard topic in the community still a hot topic in the community so I'm not going to go very deep into it the situation we had we had several use cases we have the case of common configuration for a example the cache strategy and the aqua connector those are configuration that are the same for all the websites so for this we use for example the default configuration we just put the yaml file in the default configuration and we're good then we have situation where we have per site configuration so for example the list of enabled module the core extensions or multi language settings that we only need for example multi language site and in order to manage this kind of configuration we use the config speed and then there are other cases for example the external link module settings which we couldn't find a solution for so we had to use the config ignore and I'm gonna elaborate a bit more on this especially the external link configuration so you can see in the slide here we have on the left side this is the configuration page for the external link module on the left side is what we identify as global configuration so things that are common for every website for example an external icon that we place next to an external link or the fact that we want to open external link in a new window this is common for every website and then on the right side we have what we identified as configuration which is different side by side for example the regular expression that determines what's an external link and what's an internal link and this changes side by side now the problem is that we cannot this is the YAML file related to this particular configuration the problem is that we couldn't the red highlighted part is the global part and the green highlighted part is the custom part side by side unfortunately it's one YAML file and we couldn't find a solution to split this so we're looking at the way to kind of like micro manage those permission in with more granularity which we haven't found yet without custom development so that's why we use the config ignore now the quits is coming I just wanted to set up the context first so that you know what I'm talking about let's say we have a role defined in our code base and the role is called site owner this role is defined in the user role site owner YAML file and it's it exists in the global configuration then we have a module that we call content protection which define a permission and the permission is called bypass content protection and the module is not installed on the website so that's the question so in Drupal 10 what happened if you edit any permission for the site on a role and the Novartis content protection which define this permission it's not installed do you get an error or nothing is missing and everything goes well anyone nothing no so the right answer is error you get an error but only in Drupal 10 so you are almost there in Drupal 9 this would have been ignored so even if there is a permission which doesn't exist because the module is not enabled Drupal will still save the form but in Drupal 10 unfortunately you cannot save it you get an error so this is probably something that can be improved but I guess even if you did it wrong I think it deserves a t-shirt for the bravery and then the last topic I wanted to discuss is financial results financial results is a very important event for our company because we have to prepare so much confidential content that then needs to be disclosed at a specific time so those are the requirements prepare confidential content while ensuring operational continuity prevent this confidential content from being accessed by authenticated users for obvious reason big bang publishing we after all this content is prepared we want to push life all in once and then the last one is make changes to the target size during the phase and I will elaborate this more in the next slides one of the challenges that we add is we cannot draft or moderate files because we are not using a digital assets management at the moment so Drupal as far as I know doesn't provide this kind of functionality so I'm gonna talk about what we did in Drupal 7 in Drupal 7 and we use an approach which is called copy freeze lock and prepare we take Novartis.com we make an exact copy of it and we we spin up we make a clone and we call it secret dot Novartis.com and when I say clone I mean we copy database the database the files and the code base of course is already shell because we have a multi-site installation then we freeze Novartis.com meaning no more changes are allowed to the site and we start preparing the content on the secret dot Novartis.com environment of course before we start preparing the content we protect this environment so that people cannot access it through a shield module for example or through other authentication system that we use within the company and then we use the deploy module basically we create buckets we put the content in those buckets and we organize those buckets in a way that bucket one goes at 7 a.m. for example a bucket two goes at 7 or 5 and we just need to click a button when you click the button the deployment module will just transfer those information into the target website. It works nice solution but there is always a but there may be network constraints so if the deployment partially fails we cannot redeploy again. There is no way to test in advance otherwise we might need to spin up a third environment a third website which is time consuming and resource consuming too. If the incremental node AD has changed in the target in this case the secret website we might have conflict when we deploy even if we use the UUID module and we need to keep those deployment buckets small because the bigger they are the bigger is the risk of a network failure or of the deployment failing and we cannot change anything on the target website because as soon as we create an additional node on the target website the data has changed and so you have more an additional node ID on the target and which creates conflicts and even with when we use UUID that could be a problem. So in Drupal 10 we kind of like reinvented the solution and we develop a custom solution so we still make a copy of the website from novartis.com to secretnovartis.com and this is the step one. This shows the domains of PHP again as I mentioned before this maps the front end with the back end and this is the current solution. Step two this is when we want to start preparing the confidential content we switch the two websites we prodnovartis.com with points to the secret database and secret file folder and the secret website points to the folder that was previously pointed by the original website and as you can see the domains of PHP has changed we have switched the two map domains. In this space here we after this is done we start preparing confidential content we enabled any old password authentication system and no one can access it apart from the webmaster involved into the confidential content preparation and then the day of the financial results we just switch back to the previous situation by changing the domains of PHP file again. It's not as simple as that because when we switched in step two also the file folder has changed so people if people have bookmarked the URL this has changed and they are no longer able to access the file so we had to also play around with some redirects rule in Cloudflare which I'm more than happy to discuss if you're interested offline. So this solution worked for us and here you can see the pro and cons of both solution with the Drupal 10 solution we can have a big bank approach because we change the content of domains PHP with clear cache and everything is immediately available. There is no issue with bandwidth of course if there is no internet we cannot change the domains PHP but this is a bigger problem. We can edit content, publish content anyway we are protected by the SHID module. We can review the confidential content. There is a problem with the file URL which has changed if people have bookmarked them but so this is not good but we play around with the Cloudflare rules and we can publish the content immediately and the other thing which is not mentioned in this slide is that during the freeze we can make changes to the target website so if there is an important announcement the press release which needs to go live on the live website we will have to upload this twice on both websites otherwise when we switch back we will lose the content again and that's it. I think I'll get back to you. Thank you much. So here is kind of a sample of our learning pages for countries under novices.com and then now I would like to take this down to close and summarize what we have discussed. First with our unified domain strategy we benefit of two things. First one being the SEO authority because the country website now plugged into novices.com are going to benefit from this SEO authority from the novices.com itself and two with the content so we have now all the global content at the global level and then the corporate and the local countries are just looking for their local content themselves. The second one with this new structure went through this exercise of trying to merge close whatever it doesn't fit the business model therefore the landscape at the end is a lot simpler. Third with this business with this audience first approach our informational architecture is far more sustainable in the long term and we also have something easier for the visitors they find the content quicker. Finally the outcome is a great improvement in many KPIs. As you can see many places compared between 2021 and 2023 we had some drastic improvement and that's a significative. Our journey however is not finished so we have done the migration and now we still have a few things to put on the table. First right now we're going through a brand refresh which will be revealed pretty soon. We want to leverage digital asset management. We are about to finish something related to the event management. Content sharing hub is an idea as well to distribute content and then also something we like to do is to give back to the community. We have to use many Drupal modules built by the overall community and we like to use some of them use some of the modules that we have created ourselves and bring it back to the community for the future. The journey was not without difficulties and during that journey we learned a lot and I would like to share a few of those pieces of wisdom. First for such a large program you really need a strong leadership otherwise you assign a task without the power to execute it. Second as Sarah from us was saying yesterday during this keynote leadership there is time for listen to people and there is time for taking decision. Know what to use one because you need to be able to move forward. Three everything takes way longer way longer than expected being on the content side or on the technical side. Fourth if you want to make big improvement you're gonna have to go through a long journey which can be difficult. Don't be afraid. And fourth I think the major one if you do such a program migration if content is not on your driver's seat you're missing the point. Content is the driver for such a big initiative otherwise you're gonna miss the benefit. So with this I would like to use that stage to thanks of you partners that we use during this exercise. On the business side we had Camelweb helping us a lot really with the content migration on the small hands that use that Francois was using to migrate everything. On the IT side we had HCL developers Acrea for the platform and of course all those are Drupal modules that we use from the community. With this getting to the end of that session and I'm opening the floor for the Q&A. So what's your collaboration with the agencies who helped you develop this? How was the work? So was it very agile or something else? The approaches at which you worked together. I think the collaboration was at several levels. You had the agency for anything related to the technical part I would say and we also had a strong collaboration to be done with all the stakeholders from content perspective or the country's owner. So with the agencies I would say we had experience with our partner for the content and they have also experienced from the past from other migrations. So that was I would say the easy part of the content side. On the development side with the IT so it was a long process. So it's first we need to first understand the vision and then once you have everybody aligned and it's this long path to get to this MVP side. So the first two global website that Francois talked about, the Rottis Foundation and the Rottis Biome. Those were kind of the I wouldn't say the guinea pig but the first way to validate what we had and afterwards we went through the final big bang for the Rottis.com. Collaboration I think was extremely good. I think Volodymyr from IT would say business has been extremely involved with IT. I think we had collaboration really tight that helps a lot to make the path forward for such a large project. I think you have to have this collaboration between the two. If you just send the requirements over the fence and expect for something greater on the other side and it doesn't help. Any other question? So I saw that you went with this separate databases approach at the end and I understand that this is beneficial for more rigorous separation of access between the sites and so on. But after all, eventually do you still think that it was worth doing it this way? Because it could have been solved within one database with proper access management as well and then you would have benefited with, at the end it would have been maybe simpler at the very end to manage a single Drupal site with a single database. Yes. So the access manager was one of the topics, one of the reasons why we were thinking about one unique database or several databases because of course you benefit from one single database you can manage all the users. But the regulation we had in place forced us to go with local databases. Also there are solutions in place at the moment where we could still achieve this unified user management even if we have separate databases. So for example we have the JSON API or these different tools that allow us to make this centralize. So it was not a driver factor, this user management. More was like for example during the financial results when we have to copy the database and it's different if we copy one unique database it could be like several gigabytes rather than copy just one database for Novartis.com which is local, unified, unique and it's much smaller to manage. So those were like the reason why we and I don't think we are thinking to switch back to the idea of having one unique database because at the moment this is everything we need and we we benefit from from from the situation at the moment. But we're still looking at solution for unified access management and that's why we also use a content sharing app because of course it's not one unique database you have several sites so how do you share the content between those sites. So there are solutions in place. If there were no solutions in place definitely the one unique database would have been the only option. Challenging because of the local regulation but yeah thankfully we didn't have to go that way. Any other questions? For the dealing with identifying the language in the paths for your domains. You obviously had the challenge of Drupal kind of normally expects just a single language identifier. You had your single domain with its country and language thing. Did you explore using like a custom language negotiator for Drupal? What alternative did you use instead? I'm not sure exactly where the option explored again because we are from the business but the simple solution and the one with less development was this one because you add the language and country prefix and you just have to deal with what Drupal adds at the end which is this additional language identified and it also perfectly matched with the intention that we have to have this everything under this unique umbrella. Drupal provides a lot of those functionality out of the box. That's why the configuration page that I showed you before only includes for example the public URL, the backend URL. It is not something that we develop with a configuration that we provide. This is coming from Drupal. We only needed to tell Drupal okay this is the language identifier this is the prefix so and do the transformation. We also wanted to move all the heavy lifting to Cloudflare when possible so this is why this solution where the only I wouldn't say the only Drupal component is not just a domain PHP there is also some little module that was developed as well but this is the one with the least impact on Drupal and to move the heavy lifting to Cloudflare. I'll answer your question but if not I'm more than happy to catch up offline. Perfect I believe I think we are running out of time so one last thing there is still those contribution opportunities happening so be ready for that still on Friday. Thank you everyone