Moving Your Database to the Cloud: Key Considerations to Prepare Your Move

This blog post was originally published on the NTEN Blog.

Over the last few years my organization has migrated close to 500 nonprofits to the cloud — from very small nonprofit organizations (sometimes all-volunteer-based) to large national institutions. It does not matter if you are small or big or if you are moving to the cloud to manage your donors, volunteers, dogs, cats, or trees: there are some things that you should keep in mind. Here are my top ten (and a bonus one at the end).

1. Do your homework – You might never be able to debate the merits of Apex code (the programming language that executes on the Salesforce platform), for example, and that’s okay. However, before you start your migration to the cloud, figure out what you want and what is possible; reach out to other nonprofits in your sector, consult with volunteers and board members, and read related publications.
2. Build a team – To a small nonprofit organization with limited resources, the term “project team” may sound intimidating. But it doesn’t take a huge team, you just need to cover the following key roles (and the same person can cover more than one role):
   • The executive sponsor lends his or her influence to the project by becoming its champion. Having that person’s full support and participation—from the planning stage until the go-live date and beyond—is absolutely critical.
   • Choose a cloud hero. Selecting the right project manager and administrator for your organization is critical because the administrator will play the most important role in making your CRM implementation successful.
   • To make sure that the migration meets the needs of your end users, it is essential to involve key users in the planning process.
3. Vision – Every successful implementation project starts with a clear vision of where you want to be as a result of the project. It’s very important that your key executives are involved in defining this vision, that you document the vision, and that it is understood by everyone.
4. Plan – Just as you wouldn’t build a house without a blueprint, you don’t want to start an implementation without a plan. A plan will help you communicate with everyone, do things in the right order, identify key resources, and keep a clear end date in mind.
5. Distinguish between need and want – Indicate what your most urgent needs are, what is important to have, and what would be nice to have in a world with no budgetary restrictions. For example:
   • Must have: Track every gift we receive, including grants, single donations, and major gifts
   • Important: Capture donations from the website
   • Nice to have: Integration with our volunteer management system
6. You need a timeline – “We would like to have this project done as soon as possible” –is the second most common answer I receive when I ask a client “what is your timeline for the project?” The next-most common answer is “two years ago.” A lack of timeline may indicate to us (the vendor) that the potential client did not do any preparation and/or that the organization does not have a budget approved for the implementation.Your timeline should indicate at least the deadline for choosing the cloud vendor, a date for the beginning of the discovery, and the date you would like to have the solution fully implemented.
7. Share your budget – Always include your budget in your plan (and RFP). You may be thinking that you should not disclose your budget to the vendor because it does not leave room for price negotiations. I disagree. A budget estimate allows me, as a technology provider, to evaluate whether we are a good fit. Furthermore, it shows me that you are serious about the project, aware of its complexity (you did your homework!), and that you have the budget to execute it. Here is what you should not do–create your project’s budget based on the proposals you receive.
8. Take baby steps – Don’t try to do too much all at once. It is easy to get carried away in the midst of the excitement of building a new system. However, remember that complex projects should be broken down into manageable and measurable phases. Slowly, slowly. Rome was not built in a day.
9. Test – Before embarking on a “big bang” switchover approach, make sure that you have fully run the new system using sample real data from your existing system. Have different employees or members of your organization serve as “testers.”
10. Provide fast results – Don’t build a system that might not be relevant by the time you go live. Concentrate on getting the correct basic functionality and data, and then go ahead.

Bonus tip – remember that most people are resistant to change. Bearing that in mind, it may take some time before people are willing to switch over to a new system—without complaints and with a smile. Be prepared and patient.