 Hi everyone. Thank you so much for joining us for our webinar today, Five Steps to Getting Your Non-Profit Cloud Ready. Just a few housekeeping items before we get started. So if you have any questions throughout the webinar, feel free to use the chat box that you should see on your left hand side to ask questions. All callers will be muted so we won't be able to hear you. So use the chat box as much as you'd like during the webinar. If you lose your Internet connection, reconnect using the link that was emailed to you. You can also try refreshing your browser and logging in again if that doesn't work. And then if you want to watch the webinar again, or if you have to leave a little bit early, the webinar will be hosted on the TechSoup website at techsoup.org slash community slash events dash webinars. We'll also be sending an email with the presentation, with the recording, and any relevant links. And if you are on social media, feel free to send us a tweet at TechSoup using hashtag TSwebinars. But like I said earlier, if you want to use a Q&A, that's what we'll be monitoring throughout the conversation. So just a little bit about TechSoup. We are in 263 countries and territories. And we serve over a million nonprofits. So just to kind of make sure that you guys can hear me okay and you can use the Q&A box if you guys want to chat in where you're calling in from. And I can read out a few of those. So we have Utah, Evansville, Indiana, Boulder, Waco, Chicago, San Francisco, somebody nearby, Houston, Texas. So it looks like you guys are calling in from all over the country. And I don't see any international yet, but hopefully there's people calling in from all over the world. So just a little bit about our technology partners. We work with companies like Adobe, Intuit, Microsoft, Symantec. They make our mission possible so that we can offer technology either at a discounted or donated price. If you're interested in learning more about what technology we offer in addition to the ones that I just mentioned, you can go to our website, techsoup.org, slash get-product-donations, and you can explore based on your technology needs what we have available to you. So I'm going to go ahead and introduce the people on the call today. So myself, my name is Seema. I'm the online learning producer here at TechSoup. We have LaShika Phillips who is going to be monitoring the chat box. You might be seeing her name already. And then we have our presenter, Michael Enos. So Michael Enos is the Senior Director of Community and Platform for TechSoup Global. Michael directs DevOps, Enterprise, Infrastructure, Information and Technology Security, and software development teams that build and support platform products and services. Michael Enos' professional career in technology began in 1996, beginning as a system admin for a Bay Area nonprofit that served adults in needs. He transitioned into a role as a technical consultant developing data systems to help measure and track service quality to the individuals being served. Michael has also hired a second harvest food bank of Santa Clara and San Mateo counties in 2000 to manage technology and information systems. He helped transform the organization into a more effective enterprise using sophisticated technology to efficiently distribute food, communicate, raise money, and measure the food bank's impact. As CTO, he also worked at a national level with other enterprise food banks on developing IT best practices and standards as part of the Feeding America Technology Governance Team. So I'm going to go ahead and hand it off to Michael. Great. Hello everyone. And thanks very much for joining us today on this call. I'm very excited to be presenting this topic in my roles, previous roles both working at Second Harvest and also as a consultant and a volunteer for local nonprofits and my community. I've helped organizations prepare for cloud, hands-on, helped organizations move to the cloud and coming to TechSoup four years ago. In my role, I'm helping our organization move the many systems that provide services to our community, to our community, and also our corporate systems to cloud-based systems. What we're going to talk about today, we're going to talk about essentially what is cloud readiness essentially. We're going to talk about how it is to prepare your organization at a high level to develop cloud strategy, to get buy-in, to create an implementation plan to understand what you need to go live, and then also how this is sort of, if your organization wants to be a learning organization, now this is an iterative process. So we're going to go through this in five steps. But first we're going to talk a little bit about cloud readiness. So when we talk about cloud readiness, we're talking about essentially the preparation which includes some of these steps. They include many steps, but see these are some of the main steps that are included. First of all, there's analysis that's involved in cloud readiness. There's a certain amount of subject matter expertise that people need to understand the business functions of an organization and analyze those business functions, and how a strategy to move those business functions to the cloud can be aligned with business goals of the organization. That's also going to involve budgeting and approvals. And a lot of the work that's done in cloud readiness is essentially from a high level strategic perspective is to have an end goal of improving the security, the performance, and availability of technology services while reducing the overhead and costs in all of this through web-based services. So that's sort of a summary of when I'm thinking about what is, the first part of that is about what IT organization serves to function in an organization is essentially improving the security performance and availability of services. And then also because of the cloud, we have an opportunity to do that through web-based services, so we'll talk more about that. So that's a little bit about cloud readiness. So one of the first steps when we consider cloud readiness, well, let me first talk about our journey, and then we'll move into the steps. So I've been with TechSoup for four years now, and however, the TechSoup journey began in 2010 with some high-level visioning that was done in terms of how to move our on-premise systems and also our corporate business systems to the cloud essentially to better serve our community. One of the things we did as part of that was we transitioned our financial system and our earpiece system to the cloud in 2012 and we're leveraging NetSuite for that. I know a lot of the organizations we serve and some of the ones that I've worked with have transitioning to QuickBooks Online and I've helped organizations do that as well. Lots of different choices for some of these transitions. We also began leveraging Amazon Web Services in Microsoft Azure for cloud-based infrastructure. Amazon Web Services we started earlier first in around 2013. We started moving some of our websites and some of our brochure-ware sites and some of our assets essentially of our portfolio to Infrastructure as a Service to reduce overhead and for us to be a little bit more lean. We started using cloud-based customer service technologies in Desken 20. These are just some examples. Other services were actively used are Box for document management, Slack for internal chat. We've recently just last year moved our on-premise, what was our Primus Call Center solution which manages the call center which some of our members call into to Ring Central. That's just one example of what we've been doing as part of our transformation. Right now our digital transformation is still in flight. Right now we're moving a lot of the information systems out of our data centers into Azure to leverage Infrastructure as a Service there. So step one, the importance of having a technology plan. One thing to be clear when I've developed a lot of technology plans for organizations that are helped in two over the years. The way this has looked has changed radically over the years. Fifteen years ago if I was to develop a technology plan I would say when I first came to Second Harvest Food Bank what first thing I did was develop a five-year technology plan because there was going to be a significant amount of work that needed to be done to transform that organization as that organization we knew was going to be growing to 10% year over year in terms of fried and food to the community. So to that extent it was sort of a lofty sort of what we've called back then a waterfall project where what we want to do is essentially plan everything out get everything sort of lined up. It was a huge exercise and it was a very long throw as we say. And the intention however nowadays technology is moving so quickly five years is really a too long window to think about a technology plan. And so what I'm going to be talking about in just a moment here is about how that's changed. But one of the reasons why, first I want to talk about the purpose of a technology plan. The purpose is really to provide leadership with estimated financial projections and results and outcomes. So essentially we want to be able to know for an organization, for budgeting, for resource allocation, for business strategy purposes we want to know how much money we'll need, what's it going to look like, how is that going to improve the security performance and availability to the services that technology is providing. Mostly which is sometimes difficult to measure how is it going to change our end? How is it going to improve our impact? If you have impact measurements and you can tie them to a technology strategy that's golden. The other thing is to, part of this is really understanding the business goals. The technology leaders in the organization really have to be sitting in the same table with the business leaders and talk about how technology strategy can align with business goals especially when we think about cloud migration strategies and business functions moving to the cloud. A couple of important components here is that this is, my recommendation is that this is a broad vision, that for the technology plan itself that we're not actually solutioning at this point. What we're doing is we're actually saying, we're painting with a broad brush, we're saying, look these are the technology goals we have. Ours are things like that we want to move to, we want to have a more secure system that protects the privacy better. We want it to be cloud based. We want it to have a higher availability. We want it to be more resilient. So these are outcome metrics that are associated at the technology planning stage and then you go to the solution and such afterwards and I'll talk about that in a minute. So the other thing as I stress is I think that my recommendation is that when we think about technology plan we actually look at like 18 months what we call sprint. So this is an idea in software development to move things into shorter, more digestible sort of periods of time. Software development sprints are somewhere between six weeks to two months. But when we're thinking about something like this, we can kind of consider an 18 month to two year sort of sprint meaning that's about how long it takes to get something done. That's a technology migration project, but also short enough window that the technology might not change within a period of time. The other key component is to identify what you expect to be the estimate of cost based on resource needs and additional headcounts if needed. That is important as part of the technology plan because it gives the leaders of the organization, the business leaders a chance to sort of see how this fits in with other planning projects and also with growth expectations and other aspects of the organization, the overall organization goals. Another important aspect is to differentiate capital expenses from operating expenses. And this is really important as it pertains to cloud migration strategy because as we've been moving systems and resource technical resources to the cloud oftentimes the cost then move from a financial perspective from the capital budget to an operating expense budget because now we're looking at subscription based services. Back 15 years ago when we were looking at a technology plan, I'd say, look, we need to build a new data center. It's going to cost us this amount of money between servers and hardware and software. We're going to all land at once. That's going to be amortized over a period of time. Now what we're doing is we're saying, okay, all that stuff we want and all that stuff it's been 10 years now. That stuff is sort of at end of life. Now let's move to the cloud. Now it's going to hit our month-to-month operating expense budget. That's really important to lay out because that changes the financial modeling of an organization from a financial perspective. What I have here on this slide and this is sort of just a broad picture. This is an internal document that I did a couple of years ago now but it was when I was formulating what is now. We're at the tail end of our sort of this two-year process and beginning another one as we speak actually for this next two-year vision. So this outlines a bunch of different things that we have which we've characterized as either products, projects, or functions. Most of the things that are on here because this is a larger portfolio view of TechSoup as an enterprise. So we develop products that serve you, products and services that serve our members in our community. And then sometimes we have projects which are relative to just something that needs to get done but it's not really necessary. That's mapped to a technology strategy. Then we have functions. And most of these functions here are areas where we said, let's take this business function and let's move it to the cloud. Or let's develop it as a service in the cloud. And it's a Gantt. It separates out the product, the platform or service, the initiative that ties to the initiative is what should tie to a strategy plan. And then it shows sort of a road map. And then we'll talk about some of the thinking next about each one of these. So each one of these sort of things becomes essentially a separate project or initiative or an outcome that needs to be reached. And so for each one of these we want to break it out into an implementation plan. And that's going to be the next step once you have approvals essentially or once you have buy-in for the technology plan. So this is step two. So you've got sort of a plan in place. You've socialized it. You said this is what we're going to do over the next two years or three years, or two years preferably. That's my recommendation. But that depends on your organization. The next step really is to think about how to create an implementation plan. Now this is going to be something that is going to be broken down per milestone essentially. So if you consider the plan, we'll have milestones. So for example, one of the milestones might be moving your on-premise fundraising software to a new online fundraising software product or moving from your on-premise exchange server to exchange online or moving your document management system to Office 365 or a box or something like that. Each one of those should be sort of handled as a separate project. And for each one of those, as you're moving through these, you'll have to create an implementation plan. These are some things to consider when creating those implementation plans. As I mentioned, these are some examples that are real-world examples of those plans. One of the most important things I recommend people do is to prioritize the transition efforts based on outcome cost-risk assessments. So this is sort of a critical piece here. If you've got 10 different things, 10 different business functions that you're looking to migrate to the cloud over X amount of time, you should assess which ones of those are at the most risk. For example, of providing business disruption in the near future. For example, maybe they're end-of-life. Maybe you're running short on server space. Maybe you're concerned about security. And then it's also, you may need to assess that against cost. Maybe some of the things that are the easiest to do, maybe cost the most. And there isn't a bunching for that, and vice versa. So there's going to be sort of, and then some things may produce a tremendous amount of outcome and maybe pretty easy to knock off, and maybe that should be considered. So there's sort of mapping of this over time, and that's why in that previous in the Gantt chart I showed earlier, some of those things are lined up based on what I saw as being most critical. The last year, as I mentioned, we transitioned using our call center, using Ring Central as a service, as a cloud-based service, because we saw our on-premise call center system starting to really indicate signs of failure, and it was out of life in terms of the support from the vendors. So we made a choice to do that ahead of some other things that we're now doing, because we accomplished that. So the next point here is to map the business functions to current solutions and recommend these solutions one by one seeking approvals and providing analysis of that solution determination at each step. So the point here is that the example that I gave about when we decided to move to our call center from the on-premise solution we had to Ring Central, that was presented as its own sort of project, and I went through a selection criteria matrix with the stakeholders where we sat down and we said, look at these different solutions. This is what they'll provide. I saw it buy-in from them, and we presented that at one time. I didn't present that, and then also the solution that we're going to do for document management and the solution we're going to do for the next project all at the same time. We're doing this in sort of bite-sized pieces so that it could be properly socialized and also that the analysis could focus on that. Now, understandably, sometimes we will have to do things in parallel, but in terms of at least the management of it should try to be concentrated on a per-project basis. The next point is very important to take in consideration is to look at technical dependencies. And what I mean by that is that oftentimes because if you're moving from a world where the business functions are happening within the context of an information system or systems, moving one of those out away from that to the cloud may have implications in terms of the way that interacts or it's integrated with the systems that were on-premise. So to speak. And what I mean on-premise, I mean the things that are within the confines behind your firewall or on your local area network or in servers in your server room to software as a service or to infrastructure as a service environment. So for example, you may have, if you're thinking about moving your QuickBooks to your online QuickBooks, sorry, QuickBooks on-premise to QuickBooks online, there may be places where there's an integration with something in your on-premise file system. And so really have to go through that analysis to make sure that you may want to move one system ahead of the other because that way it's there and able to communicate to the system that you're next migrating to the cloud. So you have to look at the way things are interoperating because it's very often the case that organizations build integrations between their different systems, especially their financial and accounting systems, their donor software donor systems. That's a very common one where there's going to be integrations with some of your other systems. And the other thing is to understand how identity management changes when you move to the cloud and when you're creating a plan. And the reason why I'm bringing this up is because I've seen some organizations start to leverage an online solution and then start using the way that they're authenticating to the online solution, the cloud-based system is using a non-corporate email address or something that then cannot be difficult on the onboarding and off-boarding of individuals in the organization of access to those resources may be difficult to manage the authentication and authorization of what that user is doing online. So there are security considerations that have to be taken into place when thinking about moving to cloud-based services. The next step is to get organizational buy-in. This is really important. What we all want as technologists is that the solutions that we're developing for the organization to be successful, we want them to be adopted and we want to get maximum benefit from those solutions. The best way to do that is to get the buy-in of the users first and the organization so that when you're transitioning those business functions to a new service, oftentimes it's going to be different than the way they were doing their work before. And hopefully it will be because as I'm going to mention here, moving to the cloud is not just an upgrade or migration. It's really an opportunity for business transformation in terms of the way business works. So one of the things I recommend is that whoever is managing this in the organization is to really understand the approval process for the organization and understand who the primary stakeholders are. And if possible, create a – if you're the only sort of person you feel like you're a soldier out there advocating for, oh, we should do this. We should move to the cloud because it's going to be so much above the organization but it may be falling on deaf ears. It might be good to consider creating a technology advisory board from either with volunteers or board members to help support your efforts to move the organization to using technology more efficiently and effectively. And the other thing I recommend is to align it with budgetary processes. So that way if you're – because like I mentioned earlier, there's changes to CAPEX and OPEX modeling for the organization. It might be – it's useful for this to happen when the finance and business leaders are looking at when they're projecting revenue and they're projecting expense and then they can fit this in. So and then as I mentioned earlier, it's really important to socialize this as transformational. It's not just an upgrade or a migration. We're not just migrating our email to Office 365. We're doing this because it's going to make – it's going to help people do their jobs better, faster, quicker, more securely. And it's also going to – it's going to do something that's called reduce technical debt. And I want to talk about that for a minute. One of the best ways to socialize and get buy-in is to help people understand what technical debt means. And technical debt is a term that refers to the consequence of putting purchasing or developing a huge – a large system or information systems that then will require maintenance, care and feeding, and support with staff over a period of time. So right now, for example, a lot of the work that we're doing moving systems to the cloud is to reduce – is essentially we're paying off our technical debt essentially. We had made purchases and made decisions before there was cloud to invest in data centers, to invest in the power systems, to invest in everything that underlies all the information systems that support a network, for example, the routers and switches. But that produces debt. And so what we're kind of trying to do right now very much so is try to remove the technical debt in organization by having the systems that are managed on a day-to-day basis that require this work and this expense to move to cloud-based systems where those are maintained and leveraged through a larger consortium of people who are in those data centers working those systems that are providing that. And the other thing I really wanted – it's really important to stress security improvements. The cloud is more secure than – and I say this with a caveat that the cloud-based systems, for example, that are offering our catalog, Azure AWS, Office 365, Box, these are very, very highly secure systems and they're going to be on top of things like GDPR. They're going to be on top of data privacy changes. They're going to be managing all that. So we as individual operations-based technology technologists aren't in the position where we have to – every time there's a change in privacy law, we have to look at our systems or we're looking at PCI compliance. We have to look at our systems and then add added functionality or upgrade our systems to provide that. And in terms of data privacy issues, as I mentioned, Google, Microsoft, and Okta and all the box, data privacy is first and foremost on their mind. They couldn't have enterprise-based customers if that wasn't first on their mind. And so I know 15 years ago when we were first looking at talking about the cloud, I remember doing presentations where we're debating how secure is the cloud. I let people feel at that time – and I'm sure there are people still feel this way that I feel more secure about I know what's in my server room and I feel like I know that's safe because I can see who's going in and out of it. But I think times have changed and I think that we need to really understand that. The cloud is safe and secure. And it's not impervious as we know, but it's definitely better than if we try to build it ourselves. Work with vendors on providing demonstrations. Lastly, to get by ends, it is helpful to have the people who are providing the service or the organization that's going to help you move to that transition and come in and talk about the product. They're the experts in the product. Yes, they're salespeople, but they also have an interest in helping you adopt and use that product and they can provide and be there to answer questions directly to other stakeholders in your organization. Okay, step four, go live strategy. This step is really about given that you've gone through these other three steps or it's somewhere in the process with those and you're now in a place where you're going, okay, we're ready to, we've actually done all the prep work. We've got the implementation plan. We've got the resources. How do we actually prepare for go live? So I know I've mentioned this before, but it's really important to provide ahead of time to the end users, the stakeholders, training, documentation, and support guidelines ahead of the transition and have them be part of that process. And I've done programs where we offered initiatives for people who went through the webinars, went through the training, we provide them Starbucks gift cards or something, basically say, look, I'm prepared for this transition. And oftentimes this is really necessary because what you don't want to have happen, especially if it's a hard cut over, you don't want people to be all of a sudden going, oh no, I don't know how to operate this business function. And as part of that, one of the steps of analysis that needs to occur is whether or not the transition can be a stage cut over, whether it be performed in parallel or a hard cut over. And I want to talk about that just a little bit because this is an important aspect of transitioning a system over. For depending on the actual function that's being migrated over, you have choices here. And the importance of those choices is that it can reduce risk. Change does introduce risk in an organization. So if you're moving, and sometimes it could provide anxiety as well for the people who are working in the organization, I mean change is hard. You know, change is not easy for people. And if somebody's been working and they've been doing their, they've been putting something, plugging something into a system every single day for the last 10 years and now it's going to look different. There's going to be some adjustment there. So sometimes it's helpful to say, okay, does it have, can we do a stage cut over? Can we do it in parallel? Can we have both systems running at the same time? Now sometimes that's not possible. Generally with transaction based systems such as your financial system or an inventory management system, it's not practical to be operating in two worlds or even in an email system. You probably don't want email going into two different boxes at one time. However, what you can do is you can think about migrating team by team in the cases where it's something like email or it's something like document management. So you can have one team move over. You could test it out with that team. You can fail fast. You can learn. And then you can use those learnings as you move some of the other teams over. It's also important to have a contingency plan if possible. And there should be always some sort of a contingency plan. What happens if that doesn't work? And sometimes that could be something as easy as making sure that the systems that you've had before are still up and running and that you can if necessary revert back to them. We oftentimes will keep things turned on for quite a long period of time after transitioning just to ensure for a number of different reasons. And even though I don't have a bullet point about this, one of the reasons why is because you may have to refer to information. Sometimes when you migrate from one system to another, if there's data involved, you're not necessarily going to make the decision to move all the data at one time. You're going to say, I'm going to move the last three years worth of data. And then because we have 15 years worth of data and the migration would just take too long if we were moving all 15 years, let's keep 12 years in the old system. We'll keep the system running if we have to refer back to that. But then you have to consider how you report year over year. But all these things are doable. And it may be necessary if you only need to be able to move the last three years worth of data and then start from there. These are all the kinds of things that need to be considered. And as I mentioned earlier is that generally when we talk about cloud migration, we're talking about moving business functions to the cloud, at least when it comes to sort of internal IT migrations. If you have websites as part of your business model or as part of how you provide impact to your community, you may have websites, and if you were hosting those websites yourself and you're moving from the cloud, that may be two, for example, the internet is moving them to Amazon Web Service, for example. That may be something different, but mostly the types of things, the types of migrations that I see with organizations are moving to Office 365, moving to their document repository online to SharePoint or to Box, using single sign-on with Okta, moving to QuickBooks, moving to Salesforce, moving to an online fundraising system. These are things that are internal business functions primarily. And so my recommendation is to treat each one of those business functions separately and manage it and if possible with those stakeholders and not have to be part of a larger thing to move three different business functions at one time. The last step I'm going to discuss involves sort of what we would consider sort of assessment and iteration. So this is, of course, many of you have probably seen this, the Plan-Do-Act-Check-Demine Cycle, where this is continuous. I advocate that organizations be learning organizations and such that we're always sort of reevaluating and reassessing the landscape in terms of what is it that from a technology perspective, we know technology changes. We know it's changing more and more rapidly every day. As such, we've seen sort of, as I mentioned earlier through this talk, we've seen how that cycle has shortened from what used to be sort of probably, before I started doing this, probably 10-year cycles or 20-year cycles to five-year cycles when I became really actively involved. And now I'm seeing it sort of 18 months. And the reason is because we have an ability to really leverage cloud infrastructure to develop services and apps and things that help businesses change the way they do things. There's things that we don't know exactly what 12 months now somebody will develop such as a new type of Slack or some new type of way that people work within business or do business. Business at a high level, if I was to say, what is the largest trend that I've seen and why this is so important is that we're seeing things broken down in technology into discrete services. And so we're able to pick and choose each service we want and the best tool for each service. Whereas 15, 20 years ago what we would see is sort of a monolithic solution that would have each one of those services as a bundle, or you pay for add-ons or modules within that large monolithic system. So you'd have, I'm not naming any vendors, but you'd have a large nonprofit financial vendor. You'd buy the base product and then you could buy additionally these modules. And these were on-premise modules that would then fit in with your monolithic system. What we're seeing with cloud-based services now is that we're seeing all these things broken up. You could have a separate system just for payment processing. You can have that that will integrate with web services to a separate system that just does the fundraising to a separate system that does the actual customer management like Salesforce. And within Salesforce you could have within Salesforce different services that are apps within that that then provide discrete services within that sort of framework. And so what that's enabled us to do as solution providers for organizations is to essentially choose from this menu and at a minimum assess those regularly to understand if there's something newer that's less expensive that actually provides a better job. And as we have things in the cloud transitioning from one to the other is easier and easier as well because the data is more normalized and standardized because we didn't have the capacity, the ability to make all the customizations that we used to love to do with those monolithic systems. So sometimes it's painful moving first, transitioning from an on-premise system that has been within an organization for 10 years because there were so many customizations to the data. And now we're having to normalize that data to move to something that's non-premise, you know, a cloud-based version of that. However, once you do that, moving to the next cloud-based version is going to be easier because it's unlikely that you would have made a whole bunch of customizations to the data schema, for example, of that. So as I mentioned, I know it sits over and over again but it's best to reevaluate tools and work in these cycles. And then the other thing is to document the best practices. As you start working with these tools, ensure that there's places for people to share the best practices. Look online for best practices because we always can leverage. And that's one of the benefits of working in the cloud is because unlike sort of a homegrown customized solution that may have been developed where your subject matter experts are the people who kind of worked with people to customize that software, now everybody in the community is using that same version of that same software. And you can leverage the knowledge bases and the Wikis associated with that and learn from a whole bunch of other organizations about how to do that. And so, you know, just to share a few historically, even prior coming to TechSoup, my favorite place is to where I found inspiration for keeping on top of the trends was through N10 Idealware and TechSoup. And so with that, I think we can move on to questions. All right. Thank you, Michael. So if you guys have questions, feel free to use the chat box and Michael has a few minutes to answer them. So I'm going to go ahead. We had a couple come in while you were speaking so I'm going to go ahead and start with those. So Michael, can you tell us, somebody was asking about cloud services that are HIPAA and I guess it's called FERPA compliant. Is a server the only way to go in that case when it comes to that type of data? That's a great question. When you're evaluating the software tools, because of the focus right now on data privacy, the services that are going to be HIPAA and compliant with sort of user rights management and user data management are going to explicitly have that in their documentation. I would like to say specifically regarding Office 365 Suite that you can purchase through TechSoup, when looking at that, if that's a necessity, it is important to understand that, for example, the E3 and E5 versions of Exchange Online, for example, are the only ones that can provide that level of compliance and not just the generic E1 licensing. But that's really spelled out and our customer service agents can help you with that and also can answer questions about other products and services that you have that are in our marketplace. But that's a very good question and that is one trend that I'm seeing is more and more emphasis on ensuring that not just for HIPAA, but also just for general data privacy requirements. Got it. Perfect. So we had a question earlier. This is just a basic 101 ERP you mentioned. Can you explain, one, what that stands for, and two, what that exactly is? I apologize for the use of acronyms. And we've actually been trying not to use acronyms as much because they are becoming less and less meaningful. ERP originally stands for Enterprise Resource Planning Management System. And so traditionally your ERP system would provide the business functions of your financial accounting, also inventory management, sometimes larger organization manufacturing. Essentially these are large tools like SAP or Microsoft Dynamics. Exactly, AX would be ERP solutions. A NetSuite is technically we call that in technical terms an ERP solution because it provides all that, provides a lot more. But that at its core, it provides those business functions. Perfect. Thanks for the explanation. So when it comes to technology debt, how do you help colleagues understand that there are still costs associated with maintenance of cloud services? In other words, they aren't just set it and forget it. That's another good question. There is, if you're leveraging for example, if the way that you're working with cloud services for example using AWS and you're bringing up instances in Amazon Web Services to actually create servers in the cloud and then installing software on those servers, those servers still need to be patched and maintained over time. It is not as you said a set it and forget it. However, that being said, more and more Amazon Web Services and Microsoft Azure are providing many of the things that are needed by those type of traditional boxes as we call them through services themselves that then would be provided. It's not still quite as set it and forget it because of the need for monitoring and for ensuring that the data still needs to be backed up. But there are benefits to moving from for example just bringing up and not all the time you can do this because it may need to be installed software. So what I'll do is I'll differentiate. Then one of the ways that I'll communicate this is that I'll say installed software is installed software. It doesn't matter if it's installed on a box in your data cabinet. But if it's installed in a box in the cloud, yes, you don't have to worry about the technical debt of for example the power supply or the network switching environment. But you still have the technical debt of ensuring that that system is patched. That is provided with OS updates that there's vulnerability scanning that's happening on it. And so my recommendation if that's the model by which you're leveraging cloud resources and even if they are just purely services, there would still be the debt associated to the maintenance and especially monitoring and patching and vulnerability scanning and security and ensure that there's not being breached or that security instances are occurring. However they are less and they're less over time and they actually the iterations and the cycles and oftentimes that can be managed on a less sort of you can budget for this a little bit easier generally than if you are hit every five years with a large sort of oh I've got to change out all these UPS is all these battery backups and we've got to do a complete rebuild of our HVAC system in our server room or something like that. So it is a reduction but you're right, it's not just we're in the cloud now so hooray we don't have to do anything. All right, so somebody is asking in the situation where there's a disaster, they said big quake or zombie apocalypse sorry. So while power or connectivity might be less if it's not available in that situation are there recommended methods to backup data while the Internet is down? So if you have any recommendations on if you are in the cloud and something like that happens what is your recommendation? If the data is in the cloud and depending on the cloud service provider and depending on the way it was architected in the cloud and I think that's going to depend on sort of some of those facets if it's because assuming that the data centers where they're at or they have redundancy built into that then you may have protection that are built in based on if it's for example if when we're developing instances in Azure or in Microsoft we'll use our availability zones where we'll have instances set up in different availability zones so they can fail over to one just in case something happens to that particular data center. Now if you're talking about and I'm not quite sure, maybe clarifications if you're talking about on premise data meaning that you've had a failure or maybe you need to access data but you can't get to the Internet so how do you access the data if you don't have access to the Internet? Maybe I can get a clarification on that. Okay so we'll wait for that clarification there. So I think we said if the Internet is down or to restore should the service provider encounter major damage that helps? Yes there is service providers and there is okay thanks I've got some clarification basically imagine there's a blackout over the US and we did have a situation happen not too long ago where we had an outage of a whole bunch of data centers and so it cut out services for a lot of people probably most significantly noticed when they were trying to watch Netflix and they couldn't watch their favorite Netflix shows but if you were operating a business and your data was in that data center I imagine a lot of the people were very nervous about the quality of the data or what was happening to the data that was in those data centers. Just because your data is in a data center you're working with an on premise solution it is very important that you have a DR strategy in place. So what my recommendation is is that if you have mission critical data and it's for example then and it's in the cloud and maybe this is your customers and the important thing with that is that if you're going to move data around and you're going to store it it's absolutely important to ensure that the transmission of the data and the storage of the data is encrypted even if it's for a DR solution. So I do recommend that if you're working with an online service provider and they're providing a you know and you have your data there and this data is critical to your mission that you have a disaster recovery that you periodically depending on you know what we call your service level agreement what you would expect would be in a worst case scenario that half the quarter of the US went out because of a major earthquake what would you minimally need in order to continue from a business continuity expense perspective what would you minimally need in order to operate business especially if you're in a position where your mission is so critical to the community when as an example when I worked at Second Harvest Food Bank this was top of mind for us because we had you know we were sitting on warehouses filled with food and if there was an earthquake that hit the Bay Area we needed to be able to be in communication with other service providers locally so we went to the extreme of becoming radio operators because we can guarantee that Wi-Fi service would be there and we wouldn't be able to communicate with the Red Cross and local municipalities in order to understand where we could distribute food that was in our warehouse before it was spoiled. So to that extent we thought about for example what we did is I looked at what is the most important data that I need for the business to operate to get food out to people and I made sure that I had local copies of that data and some facility to be able to render that data into a usable form. However, it was a minimal set of information just in order to get through whatever crisis and also to restore business to the activity that we needed and then so that until we can resume that and we actually went through a planning process and exercises to demonstrate that. But as I mentioned one of the benefits of cloud technology is that these service providers the data is encrypted it's accessible not even by the people who are providing the data themselves only to the people who are authorized to access the data and it's encrypted and it's transmitted using encrypted protocols. If you're going to have local copies of your data you have to be for compliance reasons equally as responsible in terms of that data that you're maintaining on premise if that's what you need to do to ensure business continuity in the event of a major event. I hope that helps. Yeah, that definitely helps. I think in terms of disaster response or being on site there's an organization on the call that has to actually go to the area where there is a disaster and then if there's volunteer forms or things like that and they don't have access to cloud-based services does that I guess you have any recommendations around that? Yeah, you know what those are really good questions and we've worked with organizations that have thought through this and I think it's really important to think through that. There are facilities to work with data locally on notebooks. I think you're right you shouldn't assume going into a situation where you're providing support and disaster support that you would have access to the cloud when a case in point when Katrina happened I had the opportunity to volunteer for Feeding America and go out to the area and help restore services for the local food banks there and I didn't make any assumptions about what data was going to be there. So I brought in the first task I had out there was to restore internet connectivity for the food bank and also a few other warehouses that we were spinning up but we also I had local copies of the and I wouldn't assume anything so what I did is I had some tools essentially went back to sort of old school technology about working in spreadsheets and working and having ways to collect information on a local laptop but it was encrypted and so you can encrypt things on a hard drive on your laptop and make sure that you have some security in place in your laptop because especially in a situation like that your device can be compromised and you wouldn't want information that you need and it was sensitive information if it had people's personal identifiable information you wouldn't want that to be jeopardized so but those technologies are easy. Another example that I have is when I was working once again from at the food bank we would go into service areas and sign people up for food stamps and so we had teams of people going out in a van and they signed people up for food stamps and they had laptops and what we did to my point is that we didn't know if the necessary where they went they'd have access, they'd go out the hotspot but we didn't know if the church or the school that they were at had access to the Internet so we would essentially provide the, we encrypted folders on the hard drive and we had sort of forms made that could sort of just take that data and do what we call store and forward. So you could store the data temporarily in an encrypted drive on your box and then in some fashion that makes it then portable and then when you get into a place where you have Internet that you could upload that and batch that information and create scripts to batch that information and forward it and if you're thinking about this if you do that work ahead of time then it will save you trying to figure it out in the last minute because it's an emergency in a crisis. So it's a very good question and I appreciate that because I think it is an important thing to think about. Excellent. Thank you so much. Okay, so I think we have just a few minutes left so I just want to close out a few items before we go offline here. So before we go if you guys could just share one thing that you learned in today's webinar in the chat. It's really fun for Michael, Lashika, and myself to hear your feedback. We also have a post-event survey so if you have any feedback for us you should receive that once you log off the webinar and also in the follow-up emails. If you're on social media we love social media love so Facebook, Instagram, Twitter, give us a like, follow, and heart. I think those are the things that you can do on those platforms. And then also we have our blog so visit us at blog.techsoup.org for tips and tricks and how-to's and things like that. And then we have a webinar coming up on 626. Lashika is actually going to be hosting that one. Excel made easy for beginners. And just lastly I would like to thank Michael for the awesome webinar and Lashika for doing the technical assistance on the back end. And thank you to you guys for attending and spending your time with us today and we'll see you soon.