 We're going to be talking a little bit about the full process of making a migration. For the most part, I think this talk will go between sort of business topics, lessons learned, best practices, more of a consulting and how to in executing a large project than it is a technical. Are we doing okay on audio? How's that? Is that working now? Okay, great. All right, we'll pass back and forth. Okay, we'll do a game show style. So we're going to mix it up a little, make it fun. All right, cool. So we've already done introductions so I don't feel the need to belabor this point. But I do want to talk a little bit about what a migration is. But before I do that, a note about our slides. We have a very talented designer on our team who doubles on the weekends as a character artist. So she's done a great job of illustrating all of our slides. They're all custom drawings from her. It's really cool what she's able to do. So first of all, a migration. So one of the things that we struggled with a little bit is what do we mean by migration? What we really mean is what anybody in a large sense is doing in most of these sort of big Drupal platform builds, which is take some set of assets, some set of property that they have intellectual property and a business model and moving it from one platform to another. There are technical aspects of that. There's literal content migration. There are business aspects of that. There's stakeholders. There's project processes. There's communication. And we're going to talk about all that stuff. And so when we say migration, we mean it's literally a migration like moving the whole herd of cattle from one pasture to the next. So just some of the things we're going to cover. One of the things we'll talk about is the people associated with the project team. So who do you involve in migration? Who are the stakeholders? What is the makeup of a project? What's the partner landscape or the other vendor landscape that you're working on in a project? We're going to talk a little bit about how you set expectations around what a migration is going to entail, the needs of the migration, and what you really have to get done. This is on both sides. We want to look at both the client side and also the vendor side. We're going to talk about preparedness. This is a little bit more of the nitty gritty around what you do to get ready for it. The process, so how you take people through it when it happens from the initial idea of, hey, we're going to go launch a new Drupal site to launch day. And then we'll talk specifically about the launch a little bit and the transition that that entails. So when you actually are ready to press that button and go live with your new Drupal site, what does that look like? So one of the things that we want to make sure that we clarify with this is that when you're talking about people in a migration, you're not talking about just engaging one person or engaging one aspect of the team. We're talking about engaging an entire organization. There is no single migration that should ever take place with just a project team being involved. You need to talk to your stakeholders. You need to talk to your other vendors. You need to work very intimately and make sure that you're talking about how you engage with the entire group and get a really good picture of everybody involved in the migration and who it impacts. So we're going to go through a few of those roles. Okay, so first role to consider in any migration like this is the content maintainers. Content maintainers can take a lot of different forms. As these projects get larger and larger with Drupal, you need to not assume that a content maintainer is someone who is sitting there with the Drupal interface, editing interface open and working within the WYSIWYG. In a lot of the larger configurations that we're working with today, you've got upstream content maintainers, people that are responsible for content channels that they're putting into another system that are being imported into Drupal or large-scale content repositories that are sitting behind Drupal. And Drupal is interacting through an API with those. And you also need to think about these people as owning a channel of content that's potentially multi-channel downstream as well. So these people aren't just interested in necessarily putting stuff into a Drupal website that's going up, a Drupal editing interface that's going up to a website. They're interested in how that's going to show on mobile or how that stuff is going to be consumed as through a feeder and API downstream. So these people are very concerned with the asset that is inside of our content management system, which is content. In a lot of cases, they have a lot of consternation about this move. To them, this is moving all of their property to a new house and they're very concerned about that house and whether their property will be maintained well there. So they're very important people to consider in terms of your coddling. You need to make sure they're comfortable with the content that they understand how this is going to go. And at the end of the day, you have to deal with the fact that ultimately these are some of the most important stakeholders and they may not be entirely pleased with the interface that you provide them initially, but your goal is to improve their business in terms of how that content is going to serve its purpose. So they may have a little issue up front with using the Drupal interface, but remember that downstream it's really about improving their ability to deliver that content to a wider audience. The next group is technical owners. Technical owners used to be the traditional group of people we thought about when we talked about site migrations. We were always all about, are we going to be able to work with the IT departments at large organizations to be able to cut over from one system to another? That's not really the case anymore. It's a lot wider than that. The function of IT is more about risk mitigation and vetting of technology than it is about owning a CMS project. And in most organizations, that's a really good thing. You want the technical people to be there to make recommendations about technical things and to mitigate the technology risk associated with the platform move. So you're no longer asking these people, like, do you like Drupal? Most of the time, they won't even really have a strong opinion about Drupal. To them, it's one component of a much larger solution and you need to be able to speak to them in terms of mitigating the risk for an organization. There are some other things here in terms of development and nuance if you're dealing with an internal project team. That might be under the IT department. We're also seeing it happen more and more frequently. The developers are actually working for marketing because marketing are the people that are controlling those sorts of CMS builds. But oftentimes, you will interface with IT on the development side of things, specifically around DevOps and pure integration. And really for IT, it's about making them understand what is comfortable about this CMS move and also painting the broader picture of how this fits into a much wider solution. Okay. Who's the sort of the bad guy in this scenario? We call them the saboteur. And the saboteur may be known or the saboteur may be unknown. But rest assured, if you're working in a large project to migrate CMSs, there is a saboteur out there waiting to stick that little bomb underneath your project and blow it up. So keys to this are understanding who those people may be. Some cases, these are people who have a vested interest in, say, job security. In the open source world, we do a lot of moving people off of licensed software. Well, guess what? Those licensed software vendors were pretty smart. They got people trained and certified, and those people are getting their job security out of that old system that you're migrating out of. They have a vested interest in making sure that your project fails so that it stays on their platform that they're certified on. That's one type of saboteur. A different type of saboteur is someone inside the organization who might not agree for whatever political reason with your project stakeholder. And they don't want to see their career succeed by virtue of having a successful project. So they may love Drupal, but they may hate the idea that your project's going to work and make their nemesis look good. So your job in any internal group as a project manager or as an external consultant, particularly if you're an external consultant, is to try to identify these saboteurs early and try to mitigate the risks that they have on the project. How do you do that? Well, you do it by ensuring that you understand what their hot buttons are, what their issues, what their needs are, and that you're catering to those effectively in terms of making them feel comfortable. Your job is to get them to buy in. It's not to alienate them from the project. They can make more trouble from the outside than they can from the inside. So what you really want to do is figure out what aspects of the project they would try to sabotage and try to get them to buy into it. Think of their interests. It's very important that you get buy-in from these people as well. This is actually my favorite one. The project champion is a really interesting concept. So a project champion is that person who's usually highly invested in the project. They have a lot of skin in the game. They're likely either putting their reputation or their career on the line. They've had a lot of input into the selection process and they really believe, they need to believe that they've chosen the right people and the right technology to implement for business. A project champion is a really great asset to have inside of an organization because they're going to be the ones who make volumes about you and go and promote you and work through an organization to make sure that there's buy-in. But they can also be almost as damaging as the saboteur. And a lot of it is because they set unrealistic expectations of what you're able to accomplish. In addition, a project champion might not actually have buy-in from everybody inside of the organization. There could be political rifts. There could be fiefdoms. Oftentimes, I know Jeff has had this happen to him. He's walked in a project ready to start developing and the project champion says, yeah, I'm really sorry, but our board said that we can't do this project. That's been known to happen. And oftentimes, these people are running in surgencies, right? Large organizations don't think about technology in terms of we're picking Drupal to do every site that we're ever going to do ever. Oftentimes, you have a project champion that's like, I'm going to take these five handful, this handful of five sites that I own as a part of this greater 1,000 site company and I'm going to make these Drupal. And they don't oftentimes have the buy-in. They need to really make that happen. So you have to really be careful of project champions. You want to build them up. You want to make them feel like they're doing the right thing and you want to make them feel again comfortable about their choices and the fact that they have skin in the game. You want to be aware of being dishonest with them and you want to help them set expectations inside of a company. And by dishonesty, I mean, you want to make sure that you're very upfront about where potential problems might be coming from because these people are putting so much of their own investment in it that they're often blind to things that might be happening in the project. And I guess the last thing with that is, you know, when it comes to these folks, they tend to have a lot of pride in the type of work that they're doing and what they're trying for the company. And you want to build them up as people that look good in the organization. Be willing to step back and let them lead. When you reach a major milestone, let them present it to their company as, look, this is my success and you share in that success together. And that's a great way to forge a relationship with these people. Yeah, in terms of setting expectations, I want to go back. That picture says it all, right? Expectations can be set for the better and the most important aspect of setting expectations is determining globally amongst everybody in the project what the success criteria are. And those stakeholders need to be accountable for those things. You need to be able to go back to a list of things and say, this project will be successful or determined to be successful by management when dot, dot, dot, these five things have occurred. And if you have that buy-in, then you do a much better job of setting expectations amongst the whole project team. So the other way we do it is with roles and responsibilities. So the key to roles and responsibilities is knowing the swim lanes of every single person on the project. And what I need by swim lanes is literally think about who's doing what in parallel with each other and making sure that they're not crossing over. You don't want roles and responsibilities that are ambiguous because you end up with project churn. You end up with things that are being done maybe ineffectively by more than one person on the team. The key to doing that is upfront being very, very critically clear on what everybody's doing. A set of bullets under each person's name that says, I'm this on the project. These are my responsibilities. This is how I will be judged in terms of success on this project is very, very important. And another key aspect of that is making sure that there's a good understanding between the stakeholders or the people on the project and their roles and responsibilities, what their deliverables are to each other. Remember, dependencies within a project are often as damaging to the schedule as dependencies outside the project. So if I'm the themeer and I'm waiting on the information architect to provide me wireframes and it's a week late, that affects me and impacts me. And the damage that it does to the schedule is bad. The damage that it does to our working relationship responsible or accountable for my own failure can be even worse. Maybe later on it stirs this sort of sense of intrateam competitiveness or backstabbing or something like that which can really endanger the project. So ensuring that those roles and responsibilities are defined and actually written down in the project charter upfront helps cut through a lot of that tension between those people. So let's look at some elements of a project team. These are some very high level roles. Project teams can be a varying size but you almost always have at least these four roles represented. You want to have a project manager that's capable of liaising with clients that does that management of a client and also oftentimes will liais with a counterpart on the client side of things. So you oftentimes have project managers that are really the glue of everybody within a particular project. They're really the ones that own a lot of the end work product but they also typically don't have a lot of control over the actual development of resources. They're not the ones that are going to be sitting there typing code into a project. They're going to be the ones that are talking to the client about the progress, about the updates. I kind of like the idea of a project manager being the one responsible for everything but the master of none of them. And that's a very interesting role to play in a project. The project manager relies most probably on the functional and technical architects. There's two sides to this. The functional side is the person that gathers requirements, that talks about the business requirements behind a project. They're typically in an analyst role or they're typically the ones that are engaging more strategically with a client about the big picture ideas of what do you want to do. Tell me about your vision and what it's all about. That's a good question. That feeds very much into the technical folks. The technical folks tend to be the systems architects. The people that are saying, let's take this vision that we have and these functional requirements and let's figure out how we're going to build a system that meets those needs. And then the last piece and this is often really overlooked is compliance. When we talk about compliance we talk about a lot of things that companies like Akwia there's code audits, there's reviews of different aspects of the project to make sure that they're actually meeting what a client has said. User experience design reviews, user testing. Oftentimes there's independent verification and validation through a third party company, but that compliance role has to be filled and it's a really key role. I think it's supposed to be a Mountain Dew, but I'm not sure, yeah. Well, the project manager would have a bottle of scotch in that case. The other side of the coin is the stakeholders. This can be a really diverse group of people. These are the people that you're ultimately responsible to and it's their domain knowledge that you're there to represent. They're the ones that have that vision and it's their vision that gets translated into technology. Oftentimes you have people that are independent project owners. They're the senior vice president of blah, blah, blah, or they're the director of technology for blah, blah, blah. There's all sorts of different groups that might be represented here, but you usually have a senior manager that represents that project ownership. Typically you also have somebody in marketing or more the business side of development. This person is responsible for ensuring that the business needs of an organization are met and they're usually relied upon by the project owner to represent things like content editors, to represent things like branding, the mission of a particular technology project. And then lastly you have editorial and editorial means multiple different things. Editorial if it's a new site can mean the content owners. Editorial if it's a simple site or a social site can actually be representative of a much wider larger group of people. These people are community managers. So you have these different aspects represented in the stakeholder group that you're ultimately there to have a high level of communication with, define success criteria with and serve as part of the development of this project. The last group you really have to take a good look at as partners and there's a reason why the images are the same here. Partners oftentimes are very representative of stakeholder groups because they're another piece of a project that has domain knowledge. In very large projects, it's really unlikely that one single company is going to be able to deliver all the services required of a major organization. And so you're going to be working with partners. And one of the things you want to be very, very careful with these folks is not creating contentious relationships. You want to nip that in the bud. You want to understand that you can't do everything for a particular client and you need to have a positive relationship with these people. They may have similar project teams to you. They may be of similar size. They may be a subcontractor to you. You might be a subcontractor to them. You may have a very tight working relationship where you may be very disparate in terms of what your responsibilities are. But you have to make sure that you work with them because that holistic vision of a project is really important. And it gets back to the stakeholders in a large way too in that having good vendor relationships, being able to present that unified front of we understand the total technology picture to a stakeholder group is going to help ease conflict with them as well. Yeah, so let's talk a bit about how to prepare for a big migration. One of the most important aspects is communication and planning. So it's absolutely essential up front that you establish some kind of a communications plan amongst everybody on the team that stipulates not only how you're going to communicate amongst the project team members but who communicates with whom. Now, in a lot of cases, projects in the beginning tend to become a bit of a mess communications wise. The first 20 to 40% of a project is where the vast majority of the miscommunication occurs. And that's incredibly important because if you end up with the wrong people talking to the wrong people in the beginning and you allow that process to stick throughout, you're going to end up with too many communication channels that potentially don't keep the project going in the right direction. So how do you do it? Well, first and foremost, you rely on tools. Establish up front what are the ground rules around IRC, chat, instant messaging? Do you want people, project stakeholders, instant messaging the developers? Or is it crucial to your project that developers remain totally independent for those people in terms of real time communications for distraction purposes? We've seen it, we run it both ways. There's pros and cons to both. The key is that you establish that jointly amongst everyone up front in the project before it just becomes something someone starts doing halfway down the road and someone else isn't. It's also incredibly important that you don't rely on email. Everybody gets too much email. It's a really bad habit to have anything about a project at all done via email. If you have to send an email about something, you should be referencing a link in a Wiki or in a communications portal or something like that where you have a canonical place that everyone can reference for that piece of information because these days people aren't gonna go back through their email and look for that thing the project manager sent them five weeks ago. It's gonna get lost, it's gonna get buried, particularly when people are working on projects that are outside their regular job. So what we recommend, what we do in our organization, we use Open Atrium, which is a distribution that we maintain on Drupal, which we are by the way moving to Drupal 7 since everybody keeps asking that question and it's up on the website but they don't know it. Anyway, something like that, Basecamp is a perfectly good tool that does the exact same thing, very inexpensive, you can set up an account right away. The key to doing this is not necessarily what tool you have or what features it has. It's about where that information resides and the fact that all the information surrounding any one note or piece of information is about your project. It's not mixed in with a message from your boss about expense reports or something like that. You need that kind of clarity when you're working on the project. Other things have a lot to do with in-person versus phone calls versus Skype versus Google Hangouts. It's very important that you establish the manner in which you're gonna communicate with all the people that Chris was referring to, the stakeholders and all those partners and all those people. Establish all that in communications plan up front. Expect that it's gonna change but at least agree on it and agree to change it as the project proves that those aren't the best methods. Other very important tools obviously include ticket management. So we used JIRA from Atlassian which is a tiny little company here in Australia that you may not have heard of but that's a joke but nobody lasts though. Anyway, we did start working with JIRA actually about 2003 so we watched them grow from maybe 15 people or something when we were using it and now it's a fantastic tool. Whether you use that or Red Mine or Bugzilla or something else, open source doesn't matter. The key is that you have some place in which people can actually have some transparency and some visibility into what tasks everybody on the team is working on and that helps a lot with the communication amongst the team because people tend to understand when someone else is swamped or busier, better when they can see a backlog for them than just feeling like they're picking up on their stress or something like that. So communications and planning, probably the most important aspect up front, communications plans, tools and team agreement on how you're gonna communicate with each other. One last thing on the communication front. You know, I talked a little bit earlier about stakeholders. Your communication is your way of reaching higher up in the organization to make sure you're not working with somebody that hasn't secured buy-in from their boss. Having that communication be able to reach upward inside of an organization is your pathway to making sure that you're working on the right project and that you're defining success criteria that are representative of the organization, not just the needs of that project owner. That's a really key piece of the communications plan. Estimating. Estimating is a really, really big topic. It could be an entire presentation and often is. And I would recommend that you, if you're in the position where you're doing project management or you're doing consulting to a client, take advantage of some of the great talks that have been given at Drupalcons and Drupalcamps around this. What I will say is running a professional services organization for the last 12 years that we've been in business, our ability to estimate as it's matured has contributed directly to our ability to mature the professionalism and growth of the company. And that's because essentially, that's how we set our price. We set our price by estimating a project in many ways, whether it's time and materials or it's fixed price bid or something like that. It doesn't really matter. Your still, your currency is determining how much time your team is gonna take to do that work. So it's absolutely essential. I will say that even if you're working inside an organization, I think it's equally important. One of the things I've seen contribute to project failure a lot is professional services organizations like ourselves come in and we have a high degree of rigor and expectation around how we estimate everything from the ticket level where we insist that the developer or the person doing the work is actually doing the estimate and we're rolling all these up, sort of a ground up process. We often also do a top down. So we do two things to meet in the middle and get two data points. We have a project manager do it from the top. Developers and everyone else on the team do it from the bottom, it gets rolled up. And the third data point is often a related project. So we go into our project repository and say, what project have we done in the last five years that looks most like this? And not what did we estimate that at but what did it actually take? And now we have a real data point and those three data points, if they're correlated around something give you a pretty good sense of where things are gonna end up. What we've seen contribute to projects failure is the internal team, the internal group that's working on the project doesn't have the same rigor and customs and culture around doing estimates. As a result, what happens is their estimates tend to be driven more by what their project stakeholders and their project manager thinks is gonna take. It's just a top down. So they get out the Gantt chart and the project manager says, we think we can do it in this long and they push that down to the developers. And developers don't get a chance to estimate their own tickets and bring that back up for a reality check. So if you're dealing with a project where maybe your estimation processes has a lot of rigor but the other side of the group doesn't, watch out, that's a sign for failure as well. So when you talk about migrating this site, what are you talking about? There's all sorts of things and it's not just content. It can be everything from the actual nodes in a site to a bunch of documents in a repository. It can be multiple different databases that are all having to change over as a part of a site build. It can even be something like, we're moving from SVN to Git and we need to migrate all of this code data from one sort of repository to another. There's also lots of different proprietary data formats and things that you have to think about when you're doing a site build. The other part of this that isn't really listed here is social. So what happens to all those Facebook comments that are tied to something in Campfire? What are all, or wildfire, excuse me, what about all of the tweets that referenced old articles? What about all of these things that you've done to publish this content across the web? How do you take that into a new site? This sort of inventory process is really important because it's a two-stage thing. You first wanna say, all right, let's look at everything that we possibly can move and then you wanna pair that down to what do we need to move to make this successful? And so that's where the inventory side of this becomes a really important part. Once you have that, you also wanna do a second step which is refreshing and reorganizing. Jeff actually came up with a really great analogy for this. When you are moving houses, so you're taking all your furniture, all your possessions, and you're going from one house to another, do you arrange the furniture the exact same way in the new house as you would in the old? You know, do you give it an opportunity, do you take everything with you or do you give an opportunity to have a yard sale and sell off some of the stuff you maybe don't want anymore, maybe it doesn't fit in the new house? It's really important that you take the time once you do that content inventory to decide what you need to move and also to make modifications to the types of content that you want to change when you get to the new site. So again, I'm getting all the topics that could be their own presentation. Architecture, and this is not a technical talk, so keep in mind architecture to us is as much about business architecture and business logic as it is technology stack. Architecture is an incredibly important activity that tends to get rushed through or tends to be done by the wrong people. The people doing architecture ought to be the most experienced people in the project. If they're not, something's wrong. Your tech lead, your most senior person needs to be involved and in our case, all the way to the CTO is gonna have an oversight and a review of that architecture for every single client because that right there is your reputation. That is the moment of purity that you're providing to that client in terms of technical thinking and it has to be right. And if it's not right, that's okay but you have to have a process to modify it and fix it along the way. The way I think of architecture is you have to completely understand the future requirements as well as the current requirements to get it right. And that means really understanding what aspects of it need to be flexible, what parts need to be modular, and don't just assume that the tool set that you have, the way that other people have used it is the right way. Look around and find out how other people have used that tool set to make sure that there aren't better ways to set it up. Yeah, or I said delivering to the client, really not selling to the client, but yeah. So it's great to have all these things that we need to think about when we're doing it but what's really the process for getting from that inventory stage all the way to a pre-launch? So these are kind of a quick series of slides of packaging those things that we talked about in the previous section into a more cohesive process for going live. I think that this sort of speaks to very similar topics to what we've covered but it'll show a way of implementing these in a real chain of events to get to an end result. So moving data in most larger enterprise integrations, this is gonna be an automated process. Hopefully you've got people on the team or a person on the team at least who's capable of scripting stuff, understands database schemas and structures, and understands Drupal and how to use the Drupal API. There are good modules out there. Again, I get every topic that could be a full presentation but this one, no, this is good, I like it. Given the CEO, all the tech ones. So in our shop, we use things like the Migrate module which allow you to help migrate content into Drupal. We also do a lot of database scripting. We do a lot of cleansing along the way so cleaning up content, I'll talk about that in a minute. But consider this to be a vital thing, a vital decision that you're gonna make. We have had, I don't know how many clients tell us, you know what, don't worry about that. It's expensive, it's difficult, it's risky. We don't wanna pull that off. We're just gonna re-enter the content ourselves. Bullshit, they're not. They're gonna end up relying on you to do that anyway. So whether or not you think this is gonna be a part of your process, plan for it to be part of your process. If you don't have the skillset in-house to do it, go out and get someone that can do this process. Don't assume that the content owners are actually gonna re-enter the content by hand. They're just not gonna do it. Again, just like Chris said earlier, use it as an opportunity to clean up. A lot of times content that you're bringing over isn't just coming over from one platform, it's coming over from three platforms ago. And that stuff might have been late 90s. It may have had a lot of embedded HTML stuff that you wanna clean out. It could have been scraped off of word documents and been dropped through WYSIWYG's in which all kinds of nasty, nasty, proprietary encodings has been dropped into the database. That can cause you a lot of problems and a lot of pain. And again, as Chris said earlier, this is your opportunity to clean it up. So look at transformation processes, look at cleansing, script out the JavaScript stuff that's in there, out. Get any bad tags and things that WYSIWYG's and word processing programs and stuff have put in there out during this process. And for God's sake, make sure your content is just as clean as possible. Yeah, so once you have that content up there, you wanna make sure that you take a look at it. Have a keen critical eye to what's gone up there. A big part of this is context, right? When you have new content in a new system in a prototype way, you wanna be able to take a look at this content then in context and understand what it's gonna look like in the new site. And that's really what the review is all about. Engagement around the entire organization is again really important at this phase because you don't want content to just look good to editors. You want it to look good to users and other folks that are going to be interacting with the site. So if anyone that saw Dries's keynote, you know, or most of you probably already know from firsthand experience, Drupal has some difficulties in terms of the way that the deployment process works. Again, this isn't a technical talk, so I'm not gonna talk around sort of how Drupal 8 may fix that or what tools are available. But if you are responsible for planning or managing any kind of project in which you're gonna be using Drupal in any kind of large scale, understand that A, you're gonna need different environments, so you're gonna need to direct your content people at a specific environment that's dealing with just content. You're gonna have some kind of a staging or maybe an integration environment for your developers. And of course you're gonna have production, which is gonna be a sacred place. Understanding what these different environments are, how they're used, how they're procured upfront and educating your whole project team on how to use them effectively is a really important part of limiting the friction on the project. Can't tell you how many times people are just testing on the wrong server, putting content in the wrong server, something like that. And it's just a really painful part of sort of the friction of the project that you wanna try to eliminate. It's very important that you think about that upfront and you come up with the scheme that your project is gonna use to manage the deployment process. That goes as far as potentially having automated continuous integration processes and things like that. If your project is mature and you have that kind of software maturity in your organization, you're gonna wanna do that. If you don't, you need to make that decision up front and decide if you're gonna do it the old fashioned way, get on the same page so that you don't have those arguments down the road at three quarters of the way through the project. There's another piece of this too, social integration. This is a huge, passionate thing that I have here. When you talk about content these days, you're not talking about consuming content in a well browser. You're talking about consuming it on mobile devices and mobile apps. You're talking about looking at it in terms of feeds and Facebook and LinkedIn and Twitter. All of these different channels that we look at for our content now are incredibly important to understand when you're about to migrate a site. If I am going to publish an article, what does that article look like when I tweet about it? How does it get into Facebook? Do I have micro data and metadata formats? Am I needing to consider the semantic web stuff when I look at this? There's all sorts of aspects of integration here that are very often overlooked, and this is what the web is becoming. People want social, they want mobile, they want this way of sharing and consuming information on their own terms, and if you don't have a site that supports that and you haven't tested that as a part of your migration, you're overlooking a huge portion of where your users are gonna be interacting with you. Can't say enough about the importance of code review. This is about quality, it's about having a process internally within the team to determine when code is okay to go into a production environment. On our teams, we tend to have a hierarchy, so we have multiple people looking at code. We'll do random checks, we'll do planned code reviews. We use tools like Crucible and FishEye, also from Atlassian, to make this part of our process. So this is all integrated with our JIRA tickets and things like that. It's incredibly important that you establish upfront how that's gonna happen, and you filter that down to all your developers so that if you've got two or three different developers with different skill sets, that they each understand how their code's gonna be reviewed and what kind of feedback and what kind of expectations are gonna be put upon them by more senior people on the team. More and more larger enterprises are dealing with proprietary customer information. You have various compliance laws in the United States. We have stuff like FISMA and HIPAA and all these other large sets of compliance standards that we have to meet in order to protect people's information. A website hack on a scale that releases a tremendous amount of people's personal health care information is something that as a business you don't really recover from. It's something that damages your credibility and your ability to even work in that space again. Security is a paramount concern for enterprise and it's one of those things that if you don't have an independent verification and validation process, get one immediately. It's incredibly important that you use outside people to independently verify your assumptions around security. I cannot stress enough the need to understand how to write secure code and moreover to have somebody else that is not a part of your team tell you that yes that code is secure. It's a really critical piece of making sure that you have a successful site launch. Now we're gonna talk a little bit about the transition itself. So how do you go from all these different pieces into a new live site? The plan is pretty simple. You go through all that content preparation stuff. You have that QA feedback, verification side of things. We've talked about most of the pieces of those two aspects of this plan. What we really wanted to focus a little bit more on is the people prep side of things. So once you have this idea of my content's ready, my code's ready, how do I get my people ready for this site to transition? And then right leading up to site launch, what are the tasks that you have to do to ensure that you're going to have a successful launch? Content prep right before launch is an amazingly important aspect of making people feel comfortable and happy about the launch. It's really actually kind of funny. When you launch hundreds or thousands of websites, you watch and you think well, this thing's gonna be up here for years and every single day there's a decision on what's gonna go on the homepage. But that first day, oh my God, is it important because the whole world is watching, right? So be sensitive to that, understand that that may not seem, especially as a technical person, like the most important thing, you know that there's other things that need to happen to go live. But for those content maintainers in particular, this is a very important first step to feeling comfortable with the launch of the site. You also have to look at a QA and feedback process. Make sure that you're still doing your fundamentals of development. Because you've got a launch deadline that's a week away, don't compromise your QA and feedback process. Make sure that you have the right people reviewing things. Make sure that you get those final sign-offs. Make sure that you look at those success criteria you talked about earlier and that you hit every single one of them. It's really important that you not compromise this. It's much better to move a site launch than it is to launch with a site that's not gone through the process of QA and validation that you've set up as a part of the project. This is not an official statistic, but I'd say over the last 10 years, we've launched literally thousands of Drupal sites. And I'd say maybe somewhere between 60 and 70% of our launches are pushed back by the client. And I remind my team that all the time, for not because I want them to slack on the deadline, but because I want them to pay attention to that last slide, which is don't compromise your quality to meet a deadline that the client's gonna move anyway. Do a good job. And if you end up going live that day, you're gonna be happy for it. If it ends up getting pushed, you're gonna be glad that you didn't cut corners to hit a deadline that didn't happen. Oh, I get to talk about training, cool. All right, training, yeah, is a huge topic that you could do a whole presentation on. The training is an enormous part of what happens with any CMS build. A lot of it is about the psychology of getting people to understand the new system. It's some button pushing. We talk a lot about the interface in Drupal and how it's not always client friendly, but guess what, you can change a lot of that. If you have that built into your project and you've got the time, you can modify aspects of the administrative screens to be whatever you need. It doesn't matter at the end of the day if people aren't fundamentally comfortable with it well before you go live. So if you start that training process and you even integrate it in as sort of testing training, it's okay to mix those two on the content side. If you're dealing with contenters, it's okay to do iterative reviews very early on and just tell them, hey, this is me teaching you how to use the system and you telling me what's wrong with the system and we'll just mix it all together and we'll just make tickets as we go. Start early, do it often, don't wait to the end and have this big training process. Because guess what, rest assured, guaranteed if you do it waterfall and at the very end, before you go live, if you do one big set of trainings, you will find so many bugs, so many problems in that process. You will be kicking yourself so hard. So it's better to mix them up. I know it sounds like it's not a good process. It's kind of like why would you mix testing and training? Well, really honestly, it's so that you get feedback earlier in the process and you get them sort of gradually accustomed to it. It's better to get sort of slowly accustomed to the temperature change than it is to sort of do it all at once. It's the same philosophy. So I think training as many aspects to it, that's the one I feel is most important and relevant for this presentation. But if you wanna talk more, we can talk for days about that alone. This is one of the most interesting things because people think about launch day as walking into mission control during the moon landing. And they've got 25 people all in rows saying check, check, everything's good, everything's good. The reality is that the planning for that day starts well before launch date. You wanna pick a date that's reasonable, that's something that you're sure your team can be prepared on. You wanna have a launch checklist. You don't wanna get into the habit of setting expectations around a launch before you have any idea if you're actually gonna reasonably able to attain that goal. Lots of people look at, I have a site build that's gonna take a year and I'm gonna launch January 1st, 2014. Sitting here today, we would have no idea if that's a realistic date or not. We can say that we can take the project to a point but requirements change, things change with clients, things change with the way that you move forward with things. I would say very much try as hard as you can not to set a launch date in stone because if you're building a project to a date, you're always ultimately compromising what you wanna deliver. If you're basing a date based on what you're able to deliver, you're going to have better client satisfaction of better launch and things are gonna go much more smoothly. All right, so the launch itself, done, easy. What do you really need to do? From a technical perspective, you need to prepare for traffic. But that's also a business user thing. So having a really good picture of what you expect to happen on launch day and post launch in terms of visitors is really important. So are you gonna get a whole bunch of new authenticated users because now you're offering a login mechanism that wasn't there? Is that the kind of profile that you're gonna have for launch day? Or is it gonna, something that your PR department or marketing group or somebody's gonna manage to get into mainstream media and your traffic spike is gonna be 200% your normal day? And you didn't know about that because nobody told you that marketing was gonna get that out into some mainstream media circle. Those are really important things to understand because you may have designed this site to handle a certain amount of users, but they really, really have a way of blowing it up on day one. Some sites are quite the opposite. You've got a real slow launch. It's really important to you guys, but the rest of the world is just a random Tuesday. So I think it's very important that you understand that profile. There's a lot of things that you need to do technically, obviously. You need to be thinking about caching, technologies and CDNs and all that to manage that. But really that launch day is the most important time to handle your traffic because you can go down six months from then for four hours and you won't get smacked as hard by your client or management as you will if you go down for four seconds on launch day. And congratulations. You've made it. You've launched a site. You know, it's a great feeling when a project goes well and it's a really terrible feeling when it doesn't. And you want to make sure that you follow the techniques and the things that we've talked about in order to have more positive launch days. You want to have that confidence to hit that button. And that's really what this talk is all about. You know, a successful launch leads to client satisfaction, referral work, more projects down the line and success stories that you can tell for your company. And that's what you're trying to build. Never plan a project that ends on launch day. Think about that for a second. Never. It's the absolute worst end to a project plan. Every project plan should end at some point after launch day. Maybe it's two days, maybe it's a week, two weeks, two months. But what happens immediately after launch is just as important as immediately prior launch because that's when all those new content, those content editors we were talking about are actually using the system for real. And that's also when they're gonna discover the 25 things they never understood about the training process. It's when all those traffic patterns that we talked about are gonna start to become apparent. It's when the CEO finally looks at the website that you've asked him to review 10 times prior to going live. You know, he looks at it that weekend on his iPad and goes, oh, this thing doesn't look right, you know, or whatever. So, you know, it's really about understanding your true endpoint and your endpoint with any website is never, right? It's always gonna be an improving thing. But your project can't end the day of the website a lot. You know, launches. It's gotta be some point thereafter. And I think it's a really important thing for all of us to remember. But obviously it will continue from there as well. So that's just a different part of this and we don't have time for it. So, questions. So the question for the recording and for those that couldn't hear is having specific, I think, to phase two, right? Having done a lot of builds over the years. Do we have some kind of a custom admin interface that we use that handles the way we do the content process and things like that? The answer is no. We've done a lot of different custom content interfaces. We don't tend to reuse them a lot even when the client's given us permission or is willing to contribute them. And the reason is that they were typically done with something unique to that organization. We did one for the Thompson Reuters Olympic site. So on Reuters.com, we did the Olympics process. They were adamant that the users don't have to know or think about or understand Drupal and they didn't want them to see the Drupal interface. They wanted them to see an interface that looked Reuters-ish as if they had built it themselves. So we changed colors and styles. We changed workflow and layout. We used the Workbench module. We tend to use Workbench. That's one answer, I guess, to your question. Which allows for a better content administrator sort of queuing process and things like that. But we made it look more like Reuters and it was orange and they called it drop which was a code word for Drupal and it even had the Drupal logo. But they didn't want their editorial team going out on the internet and being like, oh, shit, I'm going to Drupal. What's Drupal? And then going through that process, they just wanted to obscure a lot of that to avoid the politics. In other cases, we have distributions that we use and those distributions have, in many cases, tended to alter the admin interface a little bit for certain functions. But typically, it's different for every project. Other questions? We didn't open enough subjects for questions. It's like, why don't we just touch really lightly on a lot of things that could be a talk? Xena? Yeah, yeah, sure. Yeah, so we have people in-house, oh, I'm sorry, your question is have we had a lot of success with getting people either internally or externally on a retainer basis that can do content transition? Okay. Right, so internally, have we had success finding someone who could do the content migration, right? We've done content migration a lot of different ways. We tend to have kind of a rotation amongst our development team so that no one person is like the go-to, you know, always has to be the content migration person. We think it's a skill set that everybody on the, you know, all the developers should have so they understand a lot about the content. We have clients who have trained people in-house to do it. I'll be really honest, it typically fails. I mentioned earlier, if a client tells you that they're gonna move the content themselves and don't bother with content migration, there's like a 90% chance they're gonna change their mind. If the client says they're gonna do it themselves and their DBA is gonna learn the Drupal API and migrate that data, there's like a 65% chance they're not gonna work and they're gonna come back to us or call someone else in. We just don't tend to see people that haven't done Drupal and haven't done large migrations even if they understand database stuff and schemas and all that, they just typically aren't successful in doing it. It's a shockingly technical and tedious process, I think. You know, it's deceptively hard. Yeah. Okay, I guess I get all the questions today. There's a good rant on this one. Yeah. Yeah, the question is, if we've had any experience going from SharePoint to Drupal, we have and we're expecting a lot more of it. We're gearing up to have that experience. It's my personal contention that the wave of proprietary CMS is being destroyed by Drupal on public facing websites that Dries was referring to in his keynote. It's my personal contention that that same wave will occur on the internet side and eventually SharePoint will be deposed by Drupal and others. We are steering actively our open atrium distribution into that space so that it would be a flexible replacement to a SharePoint instead of more or less a base camp. We want a tool that will do that because we think that that will happen. Our experience on SharePoint has been good in that users are typically more satisfied with what we can build these days on Drupal because keep in mind, it's not a fair fight because you're dealing with usually a SharePoint implementation that's five years old at this point so it's kind of crappy to begin with. It's not like they just decided it yesterday but when they come off of that, they typically have a much better experience. They really enjoy a lot of the interface things we can put into Drupal. The downside tends to be A, in any kind of weird custom integration stuff they've done with other Microsoft, things like calendaring or contacts or active directory or other binary file stuff that they do. So that kind of Microsoft's got its chocolate and its peanut butter mixed up. Do they have that in Australia? Do they have those commercials in the 70s? Reese's Pieces or Reese's Peanut Butter Cups? All right, never mind, never mind. Are you American? No. Okay, yeah, yeah, yeah, all right, all right. Yeah, I mean, at the end of the day, SharePoint's probably using SQL Server, right? And you've got a relational database scheme and you can script it out of there and move it. I'm quite certain that the times we've moved stuff out, we've done it in an automated fashion. I can't remember specifics of a project on that but yeah, we have. The other thing I was gonna point out about that is it does come back, most of the places we've seen, particularly US government, it does come back a lot to that sort of job security thing and licensing. So typically once people get the bug to move, they do it but there's a lot of resistance internally based on that allegiance to a platform like DBAs and SQL Server or people who've been MSC trained or whatever. Now I'm hoping that Jeff and Chris will be able to stick around after this session a little bit for potentially for more questions. I'm sorry, we ran out of time for questions. Is that okay with you guys? Fantastic, yep. In fact, I'm thinking that we should maybe have another conference next week and you can expand on each of those topic areas for us with a session each. Yeah, yeah, yeah. So would you please welcome Chris and Jeff. Thank you very much, fellas. Let's show them our appreciation. Thank you.