 So, welcome to this conference. I hope you're having a great time up to date at Drupal North. This conference is a conference I have given at the Drupal Camp Montreal as well. And I'm pleased to say that a couple weeks ago, Akwi actually took the blog version of this conference and put it on their own blog, so this is also published on Akwi as an official blog. So, should you upgrade from Drupal 7 or should you migrate over to Drupal 8? So, if you have an existing platform or website on D7, should I be continuing to upgrade it or should I be migrating over to Drupal 8, which is basically the question we want to have answered today. So, the sequence of this conference is going to be... I'm going to talk about my company, why I'm allowed to talk about this, why this question is important for you as either website owners, business owners, or maintainers. The differences and similarities between Drupal 7 and 8, what factors can influence your decisions to looking really at the risks and benefits, and the conclusion. The goal for this conference is to be really more businessy as opposed to tech. I'm going to get into the advantages technologically, but I'm going to explain them as benefits and risks of migration or not, as opposed to showing lines of code or any other types of scenarios. So, first of all, give you a little background on Symmetris, who we are. We've been around since 2004, which is a bit more than 13 years ago now, 13 and a half. We're 17 people internally, and our team has the most Drupal certified developers in Quebec in our team. We've known Drupal since Drupal 5, which is I think 2008 or something-ish around there, 2009. We are regular Drupal camp and Drupal North presenters and sponsors, so I'm glad to be here and talk with you as I've often come, but members of the team as well. I'm president at Symmetris. This is a cool little photo of our team at our offices in Montreal. I'm president there. I founded the company. I have been involved for a while in the Drupal community in giving talks and sponsoring and stuff. I also love traveling, love philosophy music in my family, my little girls. I brought them over to Ottawa and we're going to spend the rest of the weekend to have some fun around here and meet some friends. So, Chapter 1, staying with Drupal 7 or moving to Drupal 8 and why should we be asking ourselves this question? Why is it not a no-brainer? Should we automatically do one or automatically do the other? So, first of all, I'm going to start with a few assumptions that you've already invested in Drupal 7. You have a website and you want to make this website evolve and I don't need to convince you that Drupal 7 or Drupal in general is cool. I'm guessing people around the room here are already working with Drupal 7 at least, potentially already Drupal 8. That this website or web application that you have, you're looking to make it evolve. So, if it's just a static website or a static application and that there's a completely revamped version coming up, then that's not necessarily the context. So, what we do is we want to have something that already exists and bring it forward and enhance it. And that you guys are okay with me being more like business speak as opposed to saying, well, hey, look at this function, how that can integrate with your database, their API or whatever. Just kind of as a show of hands, has anybody in this room already made the decision to either upgrade Drupal 7 or Drupal 8? So, who has already moved over to Drupal 8? Anybody in the room? One, two, cool. So, the rest of you I'm guessing are still with Drupal 7. Is that am I correct? Are you even assuming? They're kind of nods. Okay, great. So, great. So, you guys are the right people I want to talk to. So, here are elements that are going to impact this decision that we're going to make. So, what's the best return on investments? So, the cost, the time. How much time again? How is this, the time it's going to take to implement is a factor? How quickly do you need the evolution made for your application or website? Are there going to be any changes? Now, you have an existing website, an existing application. What type of changes to the flexibility of it, to the stability of it, to the durability of it are going to impact your decision? Is there going to be, because you guys are owners of the website, but there's usually a lot of people who are interacting with this website. So, the people who are interacting with this website, what's the impact on them? Are you going to have to have somehow a new kind of training for these people because you're migrating over? Is that some factor you have to consider? Are there a lot of people involved or not? And your development team, so the guys internally who are maintaining the existing website or your external team, is this easier for them, more complicated for them? These are all different things that can impact the decision of moving to Drupal 8 or just staying with Drupal 7. So, not really spoilers here, but the answer is it depends. Okay, so the goal of this talk is to, based on your specific context, so each of one of you people have a specific context, and what I'm trying to do is kind of flag elements that in your context are important, that those elements are going to make you say, oh, based on those three criteria, I should be moving over to Drupal 8, or wait a minute, that's a major kind of red flag, I should be staying with Drupal 7. So, let's get into it actually. So, the differences, before we get into actually why or whatever, just kind of have a high level overview of what's the difference between Drupal 8 and Drupal 7, like as a really bird's-eye view. So, first of all, one has a number that's higher than the other, which means it's younger. So, Drupal 7 is now six years old-ish, six and a half, and Drupal 8 is fairly, it's not almost two years old. So, that's five years apart, so that means one of those two systems has a lot more work that has been done by the community over time, has a lot more modules, has a lot more updates and stuff like that have been done to it, but it also means that the main core code is more of a legacy type code because we're Drupal enough, we're behind it, or investing much more heavily in Drupal 8 now. So, it's kind of a, you have to understand that these two contexts where oftentimes we're going to start a Drupal 8 website and we're used to, oh, we're going to use this module we used to use all the time and it's either not stable yet or there's an alternate version of it and we have to adapt to that. So, those are things we have to consider when we're moving on the new system and the old system has a lot, a lot of stuff going on, but there's stuff that Drupal 8 fixes that was kind of buggy or difficult to do in Drupal 7. There's three main categories of technical enhancements that Drupal 8 brought to Drupal 7 at Drupal 7.5. So, first of all, managing the configuration. One of the main pet peeves anyway that my team went on and on all the ways about is that Drupal 7 and previous versions of Drupal had a mix of configurations of the system in the database and in the code. Now, in Drupal 8, the reason why it's a pet peeve is that when you're updating a new version of the website or adding a module or doing some tweak to a Drupal 7 website and you have live content on the website, which is also in the database, when you're kind of pushing that to the live version, you kind of have to have a code freeze or another code freeze, I mean a content freeze where I stop inputting content because now we have to migrate the configuration and then you have to kind of click on all these configurations manually and then, okay, now you can start working on the website. There was kind of workarounds, but that's basically how you had to do it and that was one of the main issues with why configurations were in the database as well as in the code. In Drupal 8, it's structured so that you can deploy configurations as code. So that means you can have the live site going on and updating content and adding new content or whatever and then deploy the code of those configurations onto the live website and not have to kind of freeze your content inputting or managing tasks. So that makes deployments much easier to do and it makes them much more sophisticated so that you can do a lot of more frequently made deployments of time little things and it's not going to impact the live site. So that's a main enhancement in Drupal 8, so taking those configurations out of the database. I'm sure Omar knows these things and there's probably configurations still in the database but they're just exported into code and then kind of re-imported. Am I correct in saying that? I'm correct. So secondly, the code itself of Drupal is cleaner. It uses symphony and twig which is object-oriented frameworks I guess which makes standardized code. The code in Drupal is more standardized so different developers are going to work on it but they're going to use kind of object-oriented which is more logical in a way structured so it's easier to manage that code and it's cleaner in general. It also requires by the way for developers to be familiar with object-oriented programming which is a step up from people who kind of worked around stuff and now they have to really know how to program when they're working on Drupal 8. And finally, there are more modules that were integrated into the core of Drupal in Drupal 8. So by default and probably all programmers when they set up a new Drupal website are going to automatically include a bunch of modules which are like every time I set up a site I'm always going to kind of put this, this, this, this, this, this, this. Well and those are not automatically included in the core we have to add those on top of the installation then we just kind of add it to our workflow when we start a website. In Drupal 8, some of those which are the most important and popular modules have been integrated into the core. Mainly from our point of view, views and multilingualism. So views is basically the module that allows you to view content in different lists or whatever in Drupal. Most of content display from what we create uses views. And multilingualism which used to be in the past internationalization and localization and other kind of modules that had to be mixed around that that had added to the website and there was different ways of approaching multilingualism and this and that. Well now there's a core structure of multilingualism built into Drupal 8 so it's much more standardized and the fact that it's in the core that means that Acquia is the company behind the core of Drupal you know has a specific set of teams that are dedicated to upgrading those modules so there's kind of a guarantee behind them more than there was in the past. So those are the three main I'd say business advantages of the technical enhancements in Drupal 8 and why Drupal 8 is better as a platform than Drupal 7. Business wise what that means is that it's easy there's also other things that come included which are not technical which means it's easier to edit content. So on the fly you kind of go in there the management of pages there's a module called paragraph which makes it easier to have pages that have lots of different types of content and manage those. You can manage content on the mobile the back end is mobile friendly so you can kind of get this conference up in your Drupal website blah blah blah post the thing which was more complicated in Drupal 7 unless you had the right theme for the back end. As we said earlier since the multilingualism module is now part of the core the whole language support aspect of Drupal is much more fluid and standard so there's a better multilingual support and being in Canada basically every site we work on has multilingualism so we're real happy that that is set up. Now there's a typo there, more digital ecosystem integrations but by default Drupal is integrated with all kinds of different external tools and there's APIs for those tools to link to Drupal and vice versa and there's a couple of them already set up. I know I was talking with the guys at AQUI a couple weeks ago and they were saying also that there's going to be if it's not already set up there's like this big integration with actually Drupal and Magento for e-commerce even though there's a Drupal commerce module but they're trying to integrate more with external tools which is kind of a trend in general right now to say that hey like you know I'm guessing like if you guys know Slack which is like this texting thing it's always integrated with all these things like MailChimp is integrated with all those things and Salesforce is integrated so Drupal already has all those kind of connections set up and they're adding to those. As I mentioned before since the way the configurations of Drupal are made you can deploy them in the code the deployments themselves are much faster to do and you can do them more frequently so you can have different versions of the website or corrections that can be brought to the website and it's much easier to implement them and they're less risk prone as to when you're kind of working with different content. There's a better performance and scalability in general every kind of version of a software usually adds in performance and scalability enhancements so Drupal is no exception to that the nitty-gritty of that honestly I'm not that aware of what that means but I know that in general it's good the impact is more often on really large scale sites that have a lot of integrations of data and every kind of page view is integrating with all kinds of data and database calls that's one case the other case is sites that have like phenomenal number of page views and then again performance is always a mix of the application itself the Drupal, the way it was programmed and the server and the configurations of that server so there's all kinds of difference there's hosting providers that are set up specifically for Drupal and then there's different sizes of RAM and whatever it is that you can set up so performance is not only related to how you're using Drupal or how you're coding your website it's also related to the infrastructure upon which it is set up but those together make for a better setup in Drupal 8 as opposed to Drupal 7 and content as a service is a concept that was called Headless Drupal in Drupal 7 and now I'm hearing a lot of decoupled Drupal which is kind of the word now basically what that means is that you can use Drupal as a content management system but not a content display system whereas let's say you want to manage all a bunch of let's say you have a cooking empire whatever and you have a bunch of recipes and you want to manage all your recipes in that system or you can do them all in the Drupal system but you can then have that Drupal back end where you added that content and managed that content export the API or JSON or whatever to external systems that are going to display those recipes in different formats it could be a web app it could be a mobile application it could be a website but those are not necessarily need to be in Drupal Drupal is basically your content repository where you put all your stuff and it has connectors that other systems can connect to so that's in Drupal 8 approaching Drupal in that fashion where you're using it just to manage content and not the way it's displayed it's better set up it also means that even if you are displaying content with your Drupal it can be fetched from other systems as well let's say you want to have a newsletter where it automatically gets the latest article and blah blah blah it's an easier to do so those are all the main enhancements I would say that Drupal 8 has as opposed to Drupal 7 in general now that doesn't mean because all these cool new doodads are there that you absolutely need to migrate over to Drupal 8 so now I'm going to go through different factors that can influence that decision that you guys are going to be making up to date everything is clear? yeah so factors that are going to influence that decision your current Drupal setup what does that mean? it means that you might have a very simple website very simple setup to your Drupal and that's going to be easier to migrate to Drupal 8 than if you have a lot of custom modules a lot of content interaction a lot of advanced synchronization with other systems all that stuff was kind of custom built took a lot of hours of development and that means a part of those hours would have to be redone for Drupal 8 because it's not structured exactly the same way so if your Drupal 7 let's say is a website that displays a list of events and that's about it then that is probably a more interesting candidate for migrating over to Drupal 8 if your website has those events plus a login plus an integration with another system then it's just that you have to kind of add it into your ROI calculation to say okay well how much time is it going to take to migrate over or not secondly the quantity and complexity of your data so I'm kind of answering my second question already with my first one I was explaining is that the more your data is complex the more complicated it's going to be to migrate to the new system so if you have a long click migrate like I love that but there's all kinds of differences and everything is done custom sorry if everything is done custom it's going to be more complicated to move over obviously your own budget is going to be a factor here so if you have a lot of time and a lot of money well hey go ahead like why not be even nice new shining Drupal 8 as opposed to that being said sometimes functionalities that do exist in Drupal 7 are not 100% existing in Drupal 8 and need to be custom made so there's some situations where that might not be correct I'm going to get into in about 5 minutes I'm going to give you like scenarios and one of the scenarios is related to this budget aspect what's the scope of your upcoming enhancements so let's say hey you know what I want to do I want to add a new field in my contact form that might not justify an upgrade to Drupal 8 since your site is working it's in Drupal 7 you have a contact form great you're going to add I don't know would you recommend this field that doesn't work why it's like 5 hours of not even programming so it's not worth it to transfer to Drupal 8 if you have a significant enhancement saying hey I have a website and I'm going to add a new e-commerce component to it or I'm going to add a login system where people can view their their profile or something well that's a significant enhancement to a website and that instead of doing it in Drupal 7 and then having to in a year or two or three redo that in Drupal 8 it might be a good time to move to Drupal 8 right now if that second part of your next phase of the website is a significant enhancement to the website how long do you want to have this website in the future so in that sense is if you're planning for a redesign let's say you know you're going to have a rebranding you just merged with another company or you're thinking of having a completely new version of your brand or something blah blah or well those types of situations are going to require programming in any case so in that sense if you know you're going to be doing a redesign of the website within a year or two well stay with your Drupal 7 now because within a year or two when you do that whole redesign or first minute or whatever well then that's the time when you should migrate over to Drupal 8 instead of spending that money twice and finally if you're looking to build a completely new project that's completely standalone then obviously go with Drupal 8 because Drupal 8 right now is stable enough like if we were three months after the launch of Drupal 8 right now I'd be like you know let's see how it goes whatever and I've talked with actually it took us a while here at Symmetris to adopt Drupal 8 and we're kind of happy we did because we were talking with a lot of companies and in the first year after launch people were having a lot of difficulty setting up Drupal 8 and we thought we could do this with Drupal 8 but it's not ready yet and blah blah but right now the Drupal 8 version that exists is very stable, has a lot of modules in it so any new website I would definitely recommend that Drupal 8 the one case where I wouldn't would be is let's say you have a whole fleet of websites or a multi-site or something like that and you'd have like this one site that you want to integrate with the others while you probably want to keep that same technology that the other ones are in or have the same backend as the other ones just to kind of maintain the cohesion of how everything is set up technologically and how your team is updating the websites let's say you have like ten sites that are being updated that have different kind of frame that they're all linked together by content or whatever in that case I'd stick with the technology that you guys already have and if you're going to be migrating to a completely new multi-site version then that's when you would transfer to a multi-site Drupal 8 in the future so you just have to consider your digital ecosystem because it's really difficult for site maintainers to have one site in WordPress one site in Drupal 7, one site in Drupal 8 one site which is linked to some kind of you know JavaScript thing linked to a Salesforce it's like every new site is just like a new set of things to do so just to streamline your team's productivity I'd say use the same platform for all your content delivery so that in general are different elements that are going to impact that decision so so that's basically kind of the gist of what needs to be taken into account and now I'm going to give you stay with Drupal 7 in these cases stay with Drupal 8 in these cases obviously each context is specific and different but these are kind of examples of times when I think you should be going with Drupal 7 and should be going with Drupal 8 I'm going to be sort of repeating myself but it's just to really be clear about which scenario we recommend which direction so stay with Drupal 7 if you are not planning any major enhancements so if any broke don't fix it in a sense why spend money to move something that's not really going to be evolving stay with Drupal 7 if you're planning a complete redesign within the next two years and at that point move to Drupal 8 if you have a lot of custom developed modules custom workflows workflows are a big impact rules I'm not sure I think it's now works with Drupal 8 but it took a while to be a 100% functional Drupal 8 if you have interactions with external systems be it a CRM an internal database inventory stuff or whatever those are all programming heavy elements you would have to decide to be rebuilding the whole thing if you're going with Drupal 8 and that's a lot of investment stay with Drupal 7 if you really want to deploy something quickly because if you have a project say hey it would be cool to move to Drupal 8 of my whatever website which is let's say the scale of I don't know it took 500 hours to build or something don't say hey great we'll have our new version of Drupal 8 in November you're going to have to test it and this and that so if you have something that needs to be done because you have a product launch in like early October and you have a month and a half frame well don't move over to Drupal 8 because it's still there's a lot of uncertainty the people you're working with internally or externally have to kind of translate whatever was done in Drupal 7 into Drupal 8 so you have to have the time to do it when you're moving over and if you need to keep the budget as light as possible in the short term then stay with Drupal 8 it's kind of like a it's not technical debt maybe it's like business debt or something in the sense where you're going to have to migrate over to Drupal 8 one day so if you don't want to spend too much now you can not spend too much now but what's going to happen is that the pattern I see often is that I won't spend too much now I'm just going to patch up this thing now I'm going to do Drupal 8 like next year and then January comes like yeah well I'm just going to repatch that other patch and then what happens is like within a year and a half we're going to have this in French we call it Zinagales but it's like this website that you have no idea what's linked with what it's super complicated and the things that are you know you're going to be fixing this thing and then that thing is going to break and then there's going to be an emergency that you have to move over to Drupal 8 and blah blah blah so ideally if you're migrating over at Planet and kind of keep to that because otherwise you're just going to be patching patches and then it's just going to break and then you know pointing fingers and blah blah blah it doesn't necessarily get to that now one should you move to Drupal 8 if you have a new important feature to add so this big kind of let's say I'm going to add e-commerce to my website that's a big feature if you need to guarantee support for more than five years because Drupal historically has maintained the current and the last version of Drupal when they do security patches and upgrading stuff like that so when Drupal 9 is going to come out Drupal 7 probably will stop being maintained within a couple months of Drupal 9 coming out and based on calendars usually it's about four or five years between Drupal versions I'd say again I don't have a magic crystal ball but so if you're aiming that this website that you have you want to maintain support on it for the next five years or more then you should be migrating over to Drupal 8 now if you regularly update content like super frequently and use multiple languages just the workflow of all that is easier in Drupal 8 so it's like regulated by the time saved and productively by your team if your website is low complexity and you know you're going to be using it in the future just migrate it over because it won't be that much of an investment to switch it over if you can right now invest more time and money up front to reduce the cost down the line of maintaining this website great I love all my clients to say that but life happens but ideally it's all about maintenance and prevention it's like kind of a vaccine as opposed to you know having to as I was saying earlier you're going to patch and patch and patch and then you're going to have to kind of put it on the respirators and have emergency teams come in but ideally you're kind of exercising and eating well which is basically upgrading to the latest version all the time if you're deploying all the time and you have all kinds of new versions your app is really kind of theoretical agile sprint approach where every two weeks you have like a deployment of this thing well move over to Drupal 8 which is going to save some time and frustration to your team because it's really complex to deploy in Drupal 7 as opposed to Drupal 8 if you have higher requirements for performance scalability again I mentioned those earlier I'm not as knowledgeable about these concepts but Drupal 8 is better and that's really with larger scale websites and again as I mentioned if you're starting a new project like jump into Drupal 8 no hesitation there so that basically covers my recommendations of should we be staying with Drupal 7 moving to Drupal 8 I'd like to find out if any of you in the room have any questions and just before that I'm just saying if you guys are in the Montreal region and you know people who are developers I'm super interested in finding new developers for our team we're actually looking right now for an additional developer so if you do please get in touch Any questions? Cool, any back? Have you taken your time through very large scale depends on how you define large scale usually what happens when we're talking really large scale we take the opportunity to say well do we really want to reproduce exactly what's in the Drupal 7 website or take this opportunity to rethink the DH website and say we're going to keep the kind of the business objectives that it attains and the content that it has but maybe this module is not really required anymore maybe we can approach it this way so when it's larger scale we usually approach it as a new project that has really kind of a really good base on which to work the danger that we or not danger is probably a too big word the situation that arises often is that a client is going to say well I have all this in my Drupal 7 website I want to find it in my Drupal 8 like why would I remove this thing it's already there but you have to think of it as saying well it's not because it's there that we're going to click a button 20 hours to migrate it over maybe we should invest those 20 hours in a module that really is an added value for your client as opposed to just kind of because it's there let's continue using it but often times that mentality is it's there already, sticks I don't know about that I have a specific question this certainly do you point that the clients that you have their expectations are more operated rather than so large and that's the problem the situation about it's supposed to bring life well usually it boils down to what I was explaining in the context so either I have a client who says well look I don't have that much of a budget and I just want to do this tweak or this fix and like okay and you know we can recommend and go over but again they won't be able to unlock the amount of time it takes I'll tell you if they have a reason to know that they come to you asking for features and that's when we apply the logic that it is this work I haven't had the case where a client says oh I want to relate because it is the latest thing and if that's what I'm saying then you can still answer the ideas for that and yes and often since it's such a major thing you know that's to move over to Drupal especially with complex websites the reason why I say that is that Symmetres are special to these more complex websites so it's very rare that we're going to do the website for a restaurant across the street we do workflows and internets so it's always going to be this major investment moving over so it's like hey let's take some time to do an analysis phase and discovery phase and then we have the opportunity to re-conceptualize this project and attain those business needs as opposed to let's say we're just migrating to kind of migrate in that sense what we do is just we just say to the client well if you don't have any business needs that are additional to achieve let's just continue updating and upgrading you know we do a monthly we call it a prevention plan so we update all the models on the website and we've got a very large complicated one of the websites that would make more sense to migrate to the part where we're slowly migrating to make more of the points in one phase of reputation as well that's an interesting question I would say more just to break this side apart we already have a lot of tasks we have just written four or five so sort of thinking like new features coming up let's say one make maps for sites make like a maps by service and just connect to that via REST rather than maybe once we were running that so perhaps in our case we would be able to because in that context we're saying it's just using the content in the new Drupal and then connecting it it might be an easier way to approach it if it's really a full fledged site it's going to be weird to have like when you're clicking on this link you're going to the Drupal way when you're clicking on this link you're going to the Drupal 7 and then just linking it all together and then when you're going to be completely it's going to just take too much time I think you're going to spend a lot of time managing these two versions that are side by side and all the impacts that that could have so I'd say probably no it's a kind of a reverse kind of like 2-3 kind of models one sense of people is like 30-40 copies of the site and certainly features might break other features we implemented and created and that's one of the great reasons too for people to simplify so much more than we might for the extent with the core recipes for doing it when you use that recipe for images and mass recipes we have one people suddenly want to go through the recipes when they get into what they want to do whereas if you play it's going to be one of the main ones because it's in core and it's going to be more centered and you're not going to have 300 different models that you can have so they could try to be like 100% of the site the bare essentials can save all the models they don't need that sounds good I always like the idea of minimal viable product because often times a website has the 80-20 rule where 20% of your features or whatever it is or functionalities are 80% of the time used and the rest are basically kind of dragging on but not that many people use it so removing stuff from your existing website often times seems like you're backtracking but often times it's like just focusing on the right stuff if I could just move it which is I think it's absolutely the right thing to look at what is the minimal viable product problem I've played before and so what will it be in the future way actually when we're moving it when you're creating a link for yourself and why when you have it in the way it will have that stuff with the real reason to work at reducing the stuff if you want to keep it for something you realize that it's making you it's very mature that's the reason to work at reducing it so that you save something if you are going to switch to the way you don't want to go into the way you're working on it just go ahead and do it and explore it with this simple file I think a lot of times when we're migrating websites we're going to be 67.1 if they're websites you'll have fields, functionality, work flows that meant something in that sense to go they need to know what they need which is a patching it's called a spaghetti code I like that and just a thought on the final I think we should really be flexible be forced to be able to evolve I think 9 is going to be about 6 months out really? I remember waiting for Drupal 7 and waiting for Drupal 8 and never having it kind of like being announced being announced and push 6 months and then push 9 months again I wouldn't of course I remember like 5 as well I remember how long it was but I think because of that we're trying to have a whole lot of kids so I think that's the plan and I think the move from 8.49 is going to be like that it's going to be a lot of issues yeah I think there was a major evolution from 7 to 8 and I don't think 8 to 9 is that going to be that significant look it's going to be a big it's going to be a reversion but I don't think they're going to completely re-read the database I think the promise is that if Drupal 8 so that's something that we're going to send a website and Drupal 7 and 8 this will happen some time next year really? well that's the case yeah right that's something bigger okay well then we're going to just re-read the database very interesting so non-technical question more from a business standpoint that may be technical over here a new project that are sold on Drupal that want to make sure that they're making the investment moving forward but are using other technology such as CIPI CRM that are not currently supported on D8 what is the act like I'm trying to talk to some of the clients about can you hold on for a little while if you really want to go to D8 or is it better to go to D7 but you might have to upgrade that in a couple of years what is the actual thought among people on this right now I mean for somebody that's not a developer well the CIPI CRM is a specific case in the sense where from my experience of CIPI CRM it's kind of branded as an extension or a module to Drupal but basically it's like a CMS in itself that kind of connects to Drupal it's kind of like saying I'm adding Salesforce to Drupal you know I don't think that like CIPI CRM could almost exist as a standalone thing apart from Drupal so in that specific case I'd say do we what type of integration they need between the CIPI CRM and the Drupal because I'd just say go with Drupal 8 and then have the CIPI CRM kind of stand alone on the side and I think it pops into a Drupal 7 to do the Drupal version but then just don't customize that Drupal leave the CIPI CRM kind of so try it with the two systems try to separate them for now because that's the way CIPI CRM from my experience works anyway it's kind of like trying to take over your Drupal and do it their way as opposed to kind of do it the Drupal way so if they're working they're really adamant on Drupal I have no hesitation to recommend Drupal 8 because based on our experience and the fact that it's almost two years you know running time the modules that we felt were missing are now there so it's stable enough to build new sites and it has all the advantages that Drupal 7 didn't have so yes I highly recommend Drupal 8 as opposed to 7 and again that's another reason Drupal 7 within a year won't be supported so you know again probably to be realistic I'd say within half to two years but still that's in that investment time if they're going to be building this it's going to be launched in 2018 so that's a year, year and a half that's why CIPI mentioned that it could be coming up like the end of life sooner than that that's why I just instantly thought that kind of changes right because I assumed again as I was mentioning it would be another four to five years window but if it's a two through year window it's we're going to be talking about issues so nice and we're going to have spring but it's going to be another year right but is it going to come out for real is it going to be like a beta or a full nine just out of curiosity just out of curiosity where did you see the all of you I understand cool alright thank you is any other questions I don't have one last question a lot of these things a lot of logic here was client facing logic but a lot if you're a triple shop or a service provider you're at one center to actually start planning a triple aid earlier develop that expertise play with the funky new toys and with the new release every minor point release you're actually getting new features every one one point two there's actually new stop coming with it that it is coming so you get used to playing with get familiar with selling to other people working with other people so if you're a service provider there's been more ways to play you should be starting to move your own to those sites we're definitely planning the aid the standalone sites are all going up that way it's just more for those people that are using the CPCRM to manage all of their clients and their donors I think what you presented was the exact way to do that hey how much can you afford to to hold off on this if you can afford or if you're ready for an investment again in a couple years that's the logic of the phrase yeah thanks thank you very much at a good end of a triple look