Written by Michael Enos – TechSoup
Step 1: Develop a Technology Plan (Also Known as Your Cloud Strategy)
The purpose of a technology plan is to provide decision makers with estimated financial projections, results, and outcomes. You will create a proposed budget and a proposal of what resources you need. Here are a few questions to ask yourself:
What are our goals?
- How is the cloud going to improve the organization’s security, performance, and availability of technology services?
- How is it going to reduce costs?
- How is it going to improve our impact as an organization?
- How can we accomplish these things with web-based services?
A technology plan relies upon an 18-month “sprint” (or several sprints). A sprint, in software development, moves projects along in a shorter and more digestible period of time.
Software development sprints are usually somewhere between 2 weeks and 2 months, but when thinking about cloud migration, consider an 18-month to 2-year sprint. This time frame allows you enough time for a technology migration project, but also a short enough window that you know the technology might not change within that time.
You will also need to consider a rough estimate of costs based on resource needs and additional head counts, if needed. Break down these costs into capital versus operating expenses, because your organization is likely going to be moving from a capital investment to investing in one or more subscriptions instead. If you have measurements of impact that you can show came from your technology strategy, those measurements would also be really helpful.
Step 2: Create an Implementation Plan
Once you have buy-in for your technology plan, the next step is to think about how to create an implementation plan. You will need to create a series of implementation plans for each initiative, project, or milestone of your technology plan.
For example, one of the milestones might be moving your on-premises fundraising software to a new online fundraising platform. Or maybe you’re moving from your on-premises Exchange Server to Exchange Online, or moving your document management system to Office 365 or Box. Each one of those milestones should be handled as a separate project. And for each one of those milestones, you’ll have to create an implementation plan.
Prioritize the transition efforts based on outcome, cost, and risk assessments. For example, where is the most critical or at-risk data?
If you’ve got 10 different business functions that you want to migrate to the cloud over a certain amount of time, you should assess which ones of those are at the most risk. Then you may want to weigh those findings against cost and difficulty level. You’ll also want to consider technical dependencies, specifically how moving from on-premises to the cloud will impact technologies that are dependent on each other.
Step 3: Get Organizational Buy-In
The next step is to get organizational buy-in. As technologists, we all want the solutions that we are developing for organizations 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 then the organization.
You might feel like you are all alone there advocating that, “We should move to the cloud, because it’s going to be so much better for the organization,” and it may seem like no one is listening. In that case, it’s good to consider creating a technology advisory board, either with volunteers or board members. They can help support your efforts to move the organization to using technology more efficiently and effectively.
It’s really important to explain to everyone that migrating to the cloud will transform how people do their work at your nonprofit. Show people how doing each project will help them be able to do their work better, faster, more easily, and more securely.
You will also want to align your project with budgetary processes and show how it can “reduce technical debt.” One of the best ways to get buy-in is to help people understand what technical debt means. Technical debt refers to the consequence of purchasing or developing a large information system or systems that then require maintenance and support with staff over a period of time. A successful cloud migration will retire or reduce this technical debt.
The other thing that’s really important to emphasize is the improvement in security. When working with major cloud vendors like Microsoft, Amazon Web Services, and Box, the cloud is safe and secure. It is not impervious, but it’s definitely better than if you try to build and maintain systems yourself. Work with the vendors of the software you are considering to provide demonstrations to your staff and key decision makers. They are the experts and can answer stakeholders’ questions.
Step 4: Create Your Go-Live Strategy
This step occurs when you have finished preparations. You’ve got your implementation plan, and the resources you need have been approved. So how do you actually prepare to go live? It’s really important to provide training documentation and support guidelines to stakeholders, ahead of the transition.
You’ll need to figure out whether or not the transition can be a staged cutover, whether it can be performed in parallel, or whether it needs to be a hard cutover. In a staged cutover, you switch to the new system in stages. When you undergo the transition in parallel, you turn on the new system and keep the old one on for a while. And when your transition needs to be a hard cutover, you completely turn off the old system and then turn on the new one.
Depending on the actual function that is being migrated over, you have may have more than one choice. Choosing the right path can reduce risk.
Additionally, your organization should always have some sort of contingency plan. It could be something as easy as making sure that the systems that you had before are still up and running, and you can revert back to them, if necessary. Sometimes when you migrate from one system to another, there is data involved, and you might not want to move all the data at one time.
Step 5: Assess and Iterate
The last step is assessment and iteration. You can use the plan, do, check, adjust Deming cycle as your guide. Organizations should be learning organizations, such that they are always re-evaluating and reassessing the landscape from a technology perspective.
Technology is changing more and more rapidly. It used to be (15 or 20 years ago) that organizations would invest in a monolithic solution that would have many services as a bundle. Or they would pay for add-ons or modules within that large monolithic system.
With cloud-based services, all these things are broken up. You can have a separate system just for payment processing that will integrate with web services. And then you can have a separate system that just does fundraising, and a separate system (like Salesforce) that does the actual customer management.
So it’s best to re-evaluate these tools periodically. When better tools become available, it’s much easier and faster to implement them once you have migrated to the cloud. It’s become possible to work in 18-month to 2-year cycles.
And as you start working with these tools, ensure that there are places for people to share their best practices. Look online for best practices that you can leverage.
That’s one of the benefits of working in the cloud. You no longer need to rely on a homegrown, customized solution. Now everybody in the community is using that same version of that same software, and you can leverage the knowledge bases associated with it and learn from many other organizations about how to use it more effectively.
