 All right, we're going to go ahead and get started. So I am Mandy Englert. I am a Solutions Consultant with FFW. And I'm Jill Maraca, Senior Director of Web Development Services at Princeton University. A little bit more about my role at Princeton University. So I manage a group called Web Development Services, WDS. I joke our acronym is We Do Sites. So our mission at Princeton is to make websites for all the departments, programs, centers, et cetera. We're a team of 15. That includes developers, designers, content strategists, project managers. And currently, we support over 1,000 Drupal websites, over 600 WordPress sites. And if you do the math real quickly, it's over 100 websites per person. That includes me. A little bit about our structure at Princeton. So we have a central IT unit. And that's what my team is part of. And that's 300 plus people. And we run all sorts of IT services at Princeton. And we serve all the departments. But we also have what we call our distributed IT staff. So for example, the Department of Geosciences might have one or two technical people embedded in that department. But we're in the central office. And so I just wanted to explain that to you. So you can kind of compare and contrast your organization to my situation. And even if there's differences, I still think that there's something you could take away from the presentation. But just letting you know, I'm in the central IT office. We serve all the departments. And we run Drupal in WordPress. Mandy? Awesome. And I'm with FFW. We are a global agency. We help digital agencies scale like Princeton, with Jill and her team, Stanford, Harvard, and other brands as well. And so today, we're going to be specifically talking about higher ed and multi-site management. And how this usually starts is with a stakeholder or a content author, someone really coming to a platform team and saying, I want a new website, or I want a new component, or I want a new theme. And that platform team really having to make sure that it's on brand. Make sure that the website can even take that feature on. And a lot of times, this adds to a pretty big struggle between marketers and platform owners. Because that custom site sometimes can't handle all of the things that they want to do right at that very moment. So that's where we see multi-site management really comes in handy for a lot of our higher ed partners. And some of the reasons why a lot of our clients really move to multi-site, brand and marketing consistency, that's a really big piece. So when it comes to user experiences, for instance, you want to have a consistent experience for your marketers across all the different websites. We also don't want logos to be distorted. A lot of brands have these policies in place where you don't want to have distorted logos or you don't want a stakeholder to say, I want a bright lime green theme, even though our brand colors are gray and black. So you want to be able to have those conversations and have that built in to make it super easy for people to stay on brand. Cost of websites and resourcing. We hear this a lot from IT side and Jill's team even. Just making sure that you can have a small team while being able to take on a lot of different websites and being able to manage that cost from either a central perspective or even as a group, as a university. And being able to have the resources to do that. And something that we hear just across the board, speed to launch new websites. So that conversation that we were talking about earlier where marketers are coming and they're saying, we need this right now, we have a campaign going out. We need to get this done. That speed to launch new websites, multi-site platforms can really help with that. So Jill, do you want to talk about some of the reasons why you guys picked it? Yeah, so there's three main reasons we chose to go with a multi-site setup. So, reducing development time and costs for sure, brand consistency, and then accessibility. Before we built our first multi-site back around 2012, we built our first multi-site in Drupal 7. We did some math and we started to look across the university and started to add up how much each department was spending, going out, getting a website built and what's the total cost. And it was a lot. And that didn't even include the hosting costs and the ongoing maintenance costs. And so, we made that pitch to leadership and we also looked across sites, not just adding up the cost being a lot, but looking at the features. There's a lot of common features across websites. So particularly in a higher ed snare, we have a lot of academic departments and every one of them wants to put a list of their courses on the websites. And so, this development was happening over and over again and the university was paying for that cost over and over again. And so, reducing development time and costs by just building it once in the multi-site and then having it be able to be used by many people was a big deal. So, we also think about brand consistency. We had heard feedback from some people that we don't, we look at some of these Princeton websites and they don't even look like they're part of Princeton. We don't really have a lot of rules around how you have to look. They're more looser around don't distort the logo. But we certainly have some departments that say, so our colors are orange and black. They don't even like orange and black colors. And so, they could really go and do a lot of creative things with the brand. So, we at least decided to have a common set of branding elements in our multi-site and it allowed us to do that. So, at least people were gonna get the logo on their site and at least it was in some expected placements and not distorted. And so, we were able to build that in. Also, with the brand consistency, we're able to build in some flexibility. So, people start to hear like templates and themes and they think, well, I don't want my site to look like everybody else's site. And we're able to build in the variations without like with some guardrails, so to speak. So, something like colors. So, we're orange and black, but people can choose to have a light theme and a dark theme and they can choose to use sans serif fonts or serif fonts. But at least it's within like a realm of sameness. And so, there's a brand consistency. Even navigation systems, we have like three or four you can pick from. So, there is that like variety within some consistency. And then, the last thing would be accessibility. That was very important for us to build in and the multi-site allows us to build in accessibility as much as possible into the base code. Princeton is committed to having websites be usable by all abilities. And instead of redeveloping accessible things over and over again, we've built it in as much as we can. And this kind of goes back into the reducing development time and costs. So, we don't have to like repetitively test certain accessibility features because we know they're already there in every website that we make when it comes to the multi-site. Awesome, and just choosing a multi-site to meet your internal needs. So, there's a lot of different technical solutions that you can go with when you're talking about multi-site. And today, we're really talking about the commonalities between websites. And that's how we're kind of describing multi-site here today. And we break this down into three main sort of decisions when we're talking about that technical solution. And these don't have to be done in this particular order. And we could probably spend an entire session or really an entire day talking about each piece of these solutions. But again, we break it down to these three pieces like architectural approach. So, as a traditional, decoupled, and this will really help you be able to pick a Drupal structure and identify product solutions. And we're not saying that this always has to be done first, but if you kind of have an idea of which way you wanna go, it helps you figure out those structure and those product solutions. Now, Drupal structure, we're a Drupal con, so we're talking about this specifically for Drupal today, but obviously there's a lot of different structures that you can pick for this as well. With Drupal structure, we're talking about the commonalities, like how much of your content is actually being shared across all of these websites? Is it just a very small portion of websites or are you sharing across every single website within your multi-site? So, we will ask our clients, and we talk about those type of decisions, like how much are you sharing code? How much are you sharing databases? And that will really kind of help determine that Drupal structure. And lastly, the product solutions. So, we'll really start to look at your current partnerships and where you currently are working with partners like Acquia or Pantheon, but we also look at custom and Beastbook solutions too. Depending on what your goals are and where your business is going, there's ways that you can kind of customize that approach as well. So, I know, Jill, you were traditional and Acquia site factories, so how did you kind of come to that decision? Right, yep. So, we are the traditional headed approach with domain access, and we do use a product called Acquia's site factory. This approach made sense for us at the time. We are, we're centralized more so than some other higher eds, and so the costs for hosting, for example, we don't charge back a hosting cost each unit on campus. It's covered by central IT funds, so that just approached me since for us, so we have all of our sites in site factory. Additionally, the first iteration of our multi-site, the Drupal 7 version, so it is in Drupal 9 now, the Drupal 7 version, was in Acquia already, and so my team just had familiarity with their products, and so just for us made sense to stay, because we had that knowledge. The other thing that was important to us when we chose our multi-site is that we wanted to make sure our deployment times were as short as we could possibly make them and as reliable as we could possibly make them, so that's another factor. Let's see, what else? We don't do too much content sharing. We do some, and sometimes if we do, we'll use a third-party product, but that's another thing we thought about when we picked a solution, and I guess in general, it's just good to know that there's an awareness, that there's lots of options, and the thing to do is to talk to people, talk to someone like FFW, because they'll help you try and get you to the place that makes sense for your organization and your technical needs, so NJIT, New Jersey Institute Technologies in the room, we were just talking about that in the hallway, where do you go, what do you do? It's, there's a lot of things to think about and just as long as you know, like just talk to more people and talk about like what makes sense for your team and your technical needs. Yeah, so in whatever approach that you pick, you're gonna have benefits and you're gonna have challenges that really go along with that. So what we're gonna be really talking about is kind of taking a more holistic approach and just talking about that future-facing roadmap and how you can really build a foundation for any multi-site and make that sort of be able to grow as your users and your needs grow, and that conversation, unfortunately involves a lot of stakeholder management as well, so really talking to your stakeholders and understanding what their needs are are gonna help you be able to build that solution and that can sometimes really be a challenging conversation. So we've really broken it down with an analogy that we think can really help platform teams be able to speak to their stakeholders about it. So building a single website is like customizing a car. So this is like your Batmobile or your Jack of all trades. So you can have a platform team really focus on just that one car and that one particular piece and be able to do all of these different things. But when you're building a platform, it's like building a car factory. You're building a factory that's able to build all sorts of different websites. So all different types of cars. So a car, an SUV, a truck, a whole product line that you're able to get from just that one factory and those assembly lines that you're building out. So it's important to acknowledge that your stakeholders are really gonna be thinking about what are these restrictions? What are the things that we can't do? But if you really kind of think about it, like a car factory, you can start to talk about it, like what are the features that are working for you? What can you add on? You can add a sunroof. And what's the restriction? I mean, you can't make a car a boat. And you can't really make a Ford or Ferrari, like things like that. But you're able to do so much just within these like certain guidelines. And we typically start building that foundation from a design system. And as you can see, we're gonna be using this car analogy quite a bit throughout the rest of the presentation. So basically, you're starting with something small and when you're starting with this design system and you're starting with these really small pieces, you're able to continue to scale that system over time and you're able to continue to be able to, build new themes and build new pieces without restarting all over again and having to redesign every two, three years, which can be really challenging when you own a multi-site. So we always like to build this in as part of the foundation, that system that can build all of these different kinds of cars just from that one piece. And again, prioritizing that collaboration is so important. And again, you're gonna have to put that greater level of forethought into it. And even if you're already running a multi-site, that next big change that you're gonna go through, consider this, put that forethought in, put that planning in upfront so that you can meet the needs of an individual website, but you're also building a site for the general public. And you can keep these features general enough to serve the needs of many while providing that flexibility. And Jill, your team has actually done a really great job of this, so I'm gonna let you go with that. Yes, Mandy and I, we had a great time with the car analogy. I learned a lot about cars and we were both into cars and one of our developers on our team, he has this historic 911 Porsche and I love it when he drives it to work. So anyway, this is the simplified version of how I explain our multi-site to people on campus who are not technical. This bottom row, this foundation, this is our foundation of the factory, our car factory that's our hosting, so the servers, the databases, et cetera. On that or in that is our Drupal piece, the Drupal 9, it's pre-configured with our Princeton needs. And then in that are the themes that we've designed for Princeton. So the gray parts are like, that's our car factory. And then out of the factory, the orange parts on top of that are the configurations that our website authors, we let them touch. So they can then configure layouts of their websites, the content types to certain degree, they can show and hide things, they can pick menu systems. I mentioned they can pick colors, variations and font pairings. And then they, of course, can enter their content into their website, so the text and the media and the files, et cetera. So this is our factory. And I mentioned earlier that we also try to build accessibility. So accessibility is built into the foundation, so we don't have to retest the code. But I also wanna mention that, and I'll make a plug for, it's a Drupal module called Editorially that helps those content editors when they're in the content part. It helps them in real time enter accessible content. So I think it's a great module. It's from a developer on my team, John Jameson, and it's the word editor, and then the word ally, so like spelled for accessibility A-1-1-Y. So I'll make a plug for Editorially. Let's see, so the Orange Foundation, it gives people the flexibility. Our website authors like it. I get excited about this. I'm a technical person, and I just look at a simple diagram. I understand the complexity and how great this is, but website authors they're not technical like me, and so a challenge is getting people on board with a multi-site, and so there's some thought that we put into that. So things that we did to get people to come on board is a number of things. Because if you go out there and you tell people you're all gonna go into the same template and everybody's gonna use the same thing, and they go, I'm unique and I wanna do my own thing, you have to do some selling of it. So what we did is a number of things. So first things, first is we have a, we call them the starter kits. So if you request a website and you get something set up that is already there, you're not starting from a blank screen. And it gives them some inspiration and a place to go. And we have starter kits for things such as our academic department. So remember I mentioned our department of geosciences and they show lists of courses. Well, that's sort of already there and on and they just have to get going. We have starter kits for things like conferences and events and for labs and things. So starter kits, they're great and they're sort of like a, we show, don't just tell, we just show examples. I kind of think of our starter kits similar to like a parking lot with the cars. Like here, go look at all these different types of cars. They're already pre-built for you. You can kind of just see them open the door and oh, I get what this is, okay. We also have a demonstration website. This website is the website that kind of puts all the elements together. You wouldn't ever build a site with everything but people can just go and see it for themselves. So don't just take my word for all these options you can do. Go look at the page of events and see how many different options you have. That's kind of like our car showroom. You can look through the book of the bazillion options. That's our demo website. We do training classes. So we help people learn how to use the system. Of course we have documentation and then we do one-on-one support so you can just have a Zoom call with us. We'll walk you through your needs and that helps people understand what's happening because certain people just need to have the conversation. They can't just look and start to mentally figure out how it meets their needs. The other thing that gets people on board is we tell them that when they get a website, they will also get a copy, a secondary place. It's our QA or a testing environment and they can have that copy and it's sort of their safe space to try something new. People, they get their website now and they don't want to break anything. They don't want to try something. We roll out a new feature. They don't want to try it there. They don't want to take their site down, put it in maintenance mode or something like that. So we tell them, look, build your website, it's live, but if you want to ever overhaul a little piece and you're just really not sure what you're doing, go to the copy of your site, try it there. It's your playground, it's your sandbox and they go, oh, that's great. They just feel more comfortable going into the platform because they have this safe space to try things out. Outside the platform, so it's not all just the technical and things like that, we build relationships. So we build relationships with each department. They trust us, they see our work, they trust that we know what their needs are because we probably talked to like 10 other academic units and we kind of hear all the common things. So they understand or sometimes they'll ask us, oh, what's that department doing? What's this other department doing? And we're like, wow, they're doing this and they're doing this and so we have these relationships. But I think the biggest thing of getting people on board is that flexibility. Many website authors, they want the freedom to be unique within the platform and we give them the ability to be unique but we give them seat belts so they're not flying out of their car or something. But they get uniqueness with seat belts. So here's an example of what I mean by the flexibilities. This is just a very simple, simple example. What you see on the left is two block listings of events. So most of our academic departments hold events. What's going on, when, where, who's speaking. On the top screenshot is what we call our events list standard. It's just one event listed above the next event. And then the next example below that is what we call our event list, the grid. And it's an event, events that are side by side. And so when our website authors are constructing their websites, they can choose to show their events in either standard grid and there's another one too. And most often people are putting this on their homepage. They wanna highlight the events so they'll put these blocks in their homepage. They do that, there's a screenshot. And this is like an edit block sidebar on the right. So it's a screenshot of some of their options. If I already have taken the screenshot of everything, this would have been a very long list of things they can choose from. They can show and hide a featured image. They can choose the aspect ratio of the image. They can pick different date badges. They can pick different formats of dates. So when we show people all the options on the right in this edit block, they go, oh wow, I get it. I really have a lot of control over how it looks. But again, it's all with like this, the seat belts and the guard rails are on the right. We, our designers have established what these things are gonna look like. And so they just need to pick and choose. The other flexibility thing is our distributed IT people. They might, there might not necessarily be web technical. They might be supporting their academic department in another technical way. And so they feel like they really have a lot of control on building the site without needing to know Drupal or HTML or CSS. They just, they need to know how to do the configurations and we give them that power. But without having these seat belts and guard rails without governance, it can get a little wild and Mandy's gonna talk a little bit about governance. So we like to really bake web governance into the foundation because yeah, it can get wild and it helps ensure that consistency, stability for your platform and scalability for your platform overall. So I'm gonna break this down to just like four different segments here. But when we start talking about actually building a governance strategy, we're looking at multiple different pieces. We're looking at multiple different teams and really how a lot of people work together. We're looking at change management and things like that. So with this, we're looking at first routines. So you put your seatbelt on when you get in the car. So you're developing that workflow. You're developing that standard that's happening every time you're logging into the platform. So that's something that you really wanna build in. Habits, so you have to get gas in your car. So just like that, you wanna kinda pre-built in things like accessibility and SEO to really help authors build those habits. So things like for accessibility, you wanna make sure that your images always have alt text. So make sure that that's a required field for alt text. Or that all of the colors that you're giving them access to are accessible colors and actually kinda go together. Things like that, so behaviors. Helping stakeholders become more involved with their websites. From taking it back to cars, you want them to understand all of the features that are involved. So if they wanna add a sunroof or if they wanna add a stereo or something after the site's built, they have that ability. They have the ability to keep integrating new things with their sites, new things with their cars. So they can request features from a feature committee and be able to understand the committee expectations overall. So just keeping those stakeholders engaged throughout. And lastly skills, so like driving skills. Not everyone has the same skill level and there's varying levels out there. That's the same here as well. So you wanna have that documentation. You wanna have that training session and group meetings to help stakeholders execute those changes competently. And not everyone is going to be as engaged as other people, but at least you're providing the skills and you're providing the necessary training that they need to actually be able to edit their site. And I know that, Joel, you actually developed a feature process. Yep, so most of our web governance is around our feature requests. So taking in requests, we have a multi-pronged sort of approach. So the request can come from within my team where we see patterns of things that people are either asking us for or patterns where like they just have trouble with something. And then our website authors will ask us for features. And I think one of the key things is that we put everything we hear into a JIRA backlog. So it's recorded somewhere. We also don't do everything that people ask us to do. That's another important thing. Our websites are for making public-facing websites. It's not for making an internet or something like that. There are other better tools to do things like an internet. So we do put everything into the JIRA backlog. We then have a monthly planning meeting where we look at our backlog and we start to plan the next month's release. We do have a regular cycle of when we're doing releases for the platform. It's like a product, it's never done. We didn't just build it, it just stays the way it is. During those meetings, we'll talk about the issues. We'll try to prioritize things that we think will benefit the most website authors. And things that we think will support the university's mission and just have a wide-reaching impact. So once we build our backlog for the monthly release, we assign it to developers, designers, and they work together to get it done. We do have an accessibility person on our team. He's our digital accessibility developer, our DAD. He's our dad. And he does get involved in almost everything. We release the platform, so we make sure it's going out the door and it's accessible and it does become a problem later on. We release the new thing, whatever it might be, to QA. We let our website authors know this is available. You can go and try it. Remember that testing copy of their site? We can tell them they can go try it there. And then we, of course, document it. We put it on the demonstration website and it's now part of the platform and everyone can take advantage of it. So even when we're talking to leadership about a multi-site platform, this is like a great example of it. It's like we develop something, we release it, and now everyone at the university can use it and it's a win. We've only developed it once. But again, the key takeaway is we don't do everything that people ask us to do. We're building cars, not hot air balloons. So that's part of our governance. We don't do it all. Yeah, and lifecycle management's gonna be so foundational too and we'll continue to talk about this throughout, but just having that process really built in at the very start can help you scale down the road. And I know that was something that I know your team was really challenged with as well was understanding how we can get through this cycle, how can we build those tools in before we start actually bringing on new websites or migrating websites and things like that. So site provisioning, developing those tools to quickly provision sites, maintenance and author autonomy. So from a maintenance perspective, you really wanna take on those central features to give authors that autonomy. Let them be able to manage their content. Let them to be able to manage their own websites while you're really providing those central features and providing those optimizations. So site reporting, that's really just keeping track of what features are used the most. How are users actually interacting with it? How are authors interacting with it? And my favorite site retirement, I like the tow truck. That's when we're looking to retire, export or archive websites. So if a faculty member leaves, for instance, you may want to get rid of that website. And this might not be something that you need to worry about so much with 20 websites, but when you're managing 1000 websites, 1000 plus websites, it's something that you really wanna put in the foundation of your platform so that you're able to manage that. You're able to see how stakeholders are using their content. And yeah. Yeah, so a quick story about our lifecycle management and when we had to upgrade from Drupal 7 to 9, when we were looking at the number of websites we had in Drupal 7, there was many, like over 1000. And what we realized is that a number of these websites were just dead, dormant, or the person didn't even work at the university anymore. And so it was a painful process to go through each site and just determine its viability. And so we wished we had built in more lifecycle management from the get-go. And so today we've built in a process where we're gonna regularly prune the dead, dormant sites or the ones that the person doesn't even work here anymore. So that's just a key takeaway to build it in from the get-go. We also don't make any throwaway websites so people do ask us, can I just get a website to just try and play and test with? Well, we didn't wanna deal with a whole hassle of managing that and throwing it out on a regular basis so you don't get a throwaway website. We'll tell those people, look, we'll either have a conversation and we'll do a demo for you and we'll show you what the website can do or we'll tell them, look, if you wanna try it, go to the training class or we'll just give them access to the training website but we're not making repetitive throwaway websites just for trying, so we made that decision. We think of our lifecycle management where we routinely patch and enhance the platform so I was describing our monthly release process. It's never done. And we do plan for things like popular features. So in our Jira backlog, we put them in there so we remember to do them. Things like, you know, CK Editor updates, switching to the Claro theme, things like that. They are maintenance type things and we wanna stay on top of that and make sure we don't fall behind the platform. We also want to try and know which are the popular features and measure how many and how much usage because this will help us direct our efforts to working on the things that most people use. I think, though, that just the big takeaway with lifecycle management, think about it early, write it down, ideally write down some sort of terms of service. If it's inactive, remove it and then have a process to do that because retiring sites is just important. You don't wanna run a whole bunch of cars that just shouldn't even be sitting in your parking lot they should just go to the junkyard. Yeah, and so, we talked a lot about those foundational pieces but really getting into scaling your multi-site, getting to that next part, like you have your multi-site, how can we scale this now? And Jill, your team's actually doing a great job of this so I'm just gonna let you take that away. Yeah, so this diagram shows you, we started as a group at Princeton in 2008. We were a team of nine people and we were supporting about 53 websites per person, including me. Today, we're a team of 15 people and we're supporting over 100 per person. So scaling, we knew we're just, you don't get infinite staff. I don't know anybody who just kinda gets infinite staff. If you do, tell me what's the secret. So the multi-site, the efficiency win for us was great because there's no way that we could have supported 110 websites per person if they were all unique, different things. With the multi-site platform, it's not like there's just this limited amount of things that people can do, people get kinda creative with their websites and do things you're like, I didn't even know you would wanna do that in the site but at least there's some of those guardrails and so we can support that many because there is a common amount of things that people can do. It's not small because we have a lot of flexibility but at least we're supporting the same Drupal and we're able to scale. I do wanna say though that like, I think of the efficiency in a multi-site as like an investment too. It's people's time and I think that's important to protect. So another point about efficiency, is remember I said we have those distributed IT people so like that IT person that's in the Department of Geosciences, well that person might support 10 different websites and the efficiency they gain from being in our multi-site platform is that they don't have to learn how to edit 10 different websites in 10 different ways, they just need to know one. Yeah and you wanna be able to protect that investment so making sure that you're constantly adding to your backlog, things like theme configurations, how can you continue to optimize the design over time? Accessibility, so continuing to run V-PAT tests or continuing to run site improvement reports, like this can really be helpful to make sure that you're continuing to maintain that front end piece for your users and for your authors. Help with wayfinding, things like that. Version security patch upgrades across my fingers, we won't have to go through another like D7 to D9 like big, huge upgrade again but if you're keeping up on these versions and these security patches it makes multi-site management a lot easier and making sure that when you have those custom components, those custom modules that you're continuing to update those things, put them on the calendar, make sure that you're continuing to go through this and we always put a lot of that type of stuff within our strategy as we're building these sites out to make sure that it is maintained after launch which is such a huge part. And the last piece, just the change management and emergency responsibilities. Again, this sometimes seems like, of course we would have that but you wouldn't believe how many times we've had a client say to us like, yeah, he was supposed to update the SSL but he didn't. So because there wasn't, that person didn't know that they were supposed to do that piece for the multi-site overall. So just things like that, just have it written down like Joe was saying, I think can be so helpful to protect that investment overall. So I think of like platform maintenance, so going with the car analogy, how many people get like the reminder to do your oil change? It's time to do it, maybe it's on your dashboard. So you got to change the oil on your multi-site, the air filter, rotate the tires and eventually you got to plan to buy new tires. So just like that, our biggest maintenance, I don't even know if I could call it maintenance but it was getting off of Drupal 7, that was a big maintenance plan to do that. Put your maintenance things in the backlog, we do that. I mentioned me of the JIRA backlog. We do plan for like major things. So Drupal Core updates and CK-5 Claro theme I mentioned. We plan them around our team's availability too and around like the campus calendar. So there are certain times of the year where we want to roll something new out and there's certain times of the year where we're not going to get people's attention and so we don't plan that maintenance then. And then we're proactive when it comes to maintenance. We try to like survey the environment and look ahead. What are people going to need? What's the university going to ask of us to do? A good example of this was like during the pandemic we had people coming to us and saying, I need an alert on my site, like something big and prominent at the top to give some kind of notice to people. So instead of building that one off for each one of our websites, we just built an alert feature into the platform and then pushed it out and then everyone could take advantage of it. I'm measuring that performance. So just like car manufacturers are doing, they're looking at all of the features that people are buying into and all of the things that we want to continue to buy into and all of the things that we're predicting that people will want in the future, reporting and measuring those things are really going to help you in the long run. And some of the types of metrics that we always recommend when building multi-sites is just this list here. But then on top of this, you start adding your marketing analytics on top of it and your advertising analytics and you can have like a really powerful, robust set of metrics that can help you not only track the users of your website and how people are actually measuring, like actually using it and you can measure that performance, but then you can see how users are using it as well. So if a particular feature is heavily used but it has a terrible user experience, that's something I know I would want to know. So you can really combine those things and be able to make those optimizations. Yeah, and so I think Mandy mentioned a lot of the good metrics. In addition to them, Princeton will look at metrics such as the number of new websites that we're asked to create so that we can have enough support staff to actually get all those requests fulfilled. We do look at annual growth and the number of websites and their size, the database size and such and so we want to plan for scaling up the hosting environment for those. We look at training class attendance. When do we hold classes? When don't we hold classes? We know people take vacations at a certain time of the year and so we plan around that. And then of course we get peak times for support requests to make sure that we have enough people on hand to do that. Yeah, and just hoping leadership understand that investment. A lot of times when I worked in higher ed, I always saw like kind of platform teams would come and say, hey we worked really hard on this one feature and we really want you to know about this one thing that we worked on. But what leadership really responded to was talking about the cost savings and the efficiency that you were able to add by having that multi-site and that consolidated support. You want to have that single point of upgrade and development and being able to talk about that to leadership and be able to show those cost savings and that efficiency can really go a long way and help you be able to grow your team and grow that platform overall because then they're gonna start recommending it as well. And Jill, I know if you could do it all over again, what would you do? So in addition to getting leadership buy-in, so efficiency and cost and so forth, what I would do again, if I could, is I would, of course you want to look at the comment denominators and feature sets and we did that. But what I would have done was had the team look at them, spend more time looking at them. So what our plan was, we actually rolled out like a beta version of our multi-site and then when we went to add in additional features, we had to do some refactoring of the code whereas if we kind of built them in from the get go before we had too many websites running on them, it just would have been easier and there would have been less refactoring of code. It would have been a good idea to start with a design system that can help you with planning the theme before you get too many websites using a theme and again, refactoring a theme and the code can be a lot of work. We would have built in metrics from the get go. Like this story I told about us thinking we had hundreds and more sites to upgrade than we really did, so building the metrics and some mechanism to prune those sites. Change management, that should also be part of it, so documenting how we're gonna do changes and then plan to build a proof of concept, plan to show not just tell the greatness of your website, multi-site, to get people on board. Yeah, and if you do already have a multi-site, never stop optimizing. I think that's kind of the main takeaway here and strengthen those design configurations, build features that make development easier and don't take developers away from their day to day tasks. If you build those in over time, it makes that a lot easier and enhance those tracking abilities. I know we've been talking a lot about that lately. Just being able to have that analyst collection strategy can be super helpful. Yeah, I think we can take questions. It's the developers. I was actually gonna just point to someone way in the back, but he left. So our lead architect, Brian, is responsible for the automated testing and they do try to write that and build that in as much as possible. You gotta make time for it when you are doing the multi-site, yeah. So we wish we had more automated regression testing built in. They will report things to us. They're usually not screaming. If it's one site that we just happened to miss and we didn't really understand that they did something creative that they probably weren't supposed to do, they'll come to us and usually we'll say, okay, we'll talk through it and we'll work it out. Usually we try to catch the large scale of things that we break with testing, both manual and the automated testing that we wrote. But we really wish, and that's what, if you're starting with a new multi-site, build in visual regression testing from the get-go so it'll help you in the long run. Can you add that separate environment I noted that you guys were doing a lot of testing. We're gonna wave the front to the back. Yep. Okay, go. So whenever a thousand websites migrated from T7 to T5, T9, I sort of froze and got the chills. Think about how do your migration strategy. Can you just talk a little bit about how you noticed that? I could talk about that for like an hour, but I'll keep it really short. So we had a thousand plus websites. They were in like three different environments. We had a custom Drupal 7 environment. There was like 40 snowflakes in there. Built all sorts of ways in all over the years. We had an open scholar environment. And then we had our multi-site environment, the first one we built. I'll say really briefly, it took a lot of planning to figure out what we were and weren't going to do when it came to the upgrade. Just months of discussion to tailor what it is we were gonna do and then communicate it out to the campus. A heck of a lot of planning. That's all I can say, yeah. But I wish we had a mechanism to prune those sites in an automated way because it would have made it, I wouldn't have froze, I froze too, like I don't know how we're gonna do this. Because there would have been a lot less, yeah. And then we did partner with FFW to get the actual upgrade done. Went very well, yeah. Is there another question? There's 15 people to manage, you know. So I'm curious, is it like a next ticket up type of situation or are people broken up into teams to serve as types of websites or how does that work? Yeah, so yeah, so we have teams. So we have the multi-site team and that's all they do. They do work on some other things but their primary responsibility is the performance and enhancement of the multi-site. And then we have two project teams and these are the teams that work with all the departments on campus to do a traditional website project. So we do work in that way as a four feet and you can like hire us as an agency in Princeton and we work with you to like construct the website. And so we do have project teams. Two in the back. Yeah, right now it's like, it's per job. So the biggest job was getting us off Drupal 7 and onto Drupal 9, yeah. Sure. Yeah, and so for the recording it is prune your sites. So I'm like, so we've got the wrap up now so I'll be around to take my question, thanks. Yeah, thank you Carol, I appreciate that, yeah. Thank you.