Most nonprofits are already in the cloud without thinking of it that way. You use Google Workspace, Stripe, and Salesforce. But plenty of organizations still run old servers in closets: file shares on a local box, email on an Exchange server, databases on machines you have had for six years. Cloud migration is less about being modern and more about avoiding a painful reality, because running your own server means you own the backups, the security, the patching, and the disaster recovery. That is not your mission. This lesson walks through planning a migration that does not crash your operations.

Why Nonprofits Delay Cloud Migration

The first reason is fear, and it is not irrational. Migration sounds scary because the failure modes are vivid: you will lose data, things will break, staff will not know how to use the new system, and downtime will hurt programs. Nobody gets thanked for a migration that goes fine, and everybody hears about one that goes badly, which quietly biases every conversation about it toward doing nothing.

The second reason is inertia. The argument is that the current system works, so why change it. Except it kind of does not work. It is slow, it crashes, backups fail silently, and updates take weeks. Because it has not catastrophically failed yet, leadership concludes that it should not be touched, which is precisely the reasoning that keeps an organization on infrastructure it cannot recover.

The third reason is cost, usually phrased as the observation that cloud software costs money while the server is already paid for. Except your server requires someone to manage it, carries annual electricity and cooling costs, and sits one hard drive failure away from data loss. The true cost of keeping on-premises infrastructure is often higher than the cloud equivalent once you count the labor honestly. The real risk here is not migration, it is not migrating: every day you keep old infrastructure is a day your data is at risk.

What You Are Actually Moving

Cloud migration is not one project. It is several projects that happen to share a name, and treating them as one is how organizations end up with a scope nobody can manage. Break the work apart before you plan anything.

• Email: if you run Exchange on your own server, the destination is a hosted suite such as Google Workspace or Microsoft 365.
• File storage: if you have shared drives on a local server, the destination is Google Drive, OneDrive, or Dropbox.
• Database and CRM: if you host it yourself, the destination is the software as a service version, such as Salesforce or HubSpot.
• Websites: if you host on your own server, the destination is managed hosting or a headless CMS.
• Backup and disaster recovery: if you have one backup drive, the destination is cloud backup with versioning and off-site copies.

Sequence them deliberately. Email and file storage go first, because they are the easiest and deliver the highest immediate value. Databases and CRM come next, since they are more complex but sit at the core of operations. Specialized systems come last, and which ones those are depends entirely on what your nonprofit does. Each migration you complete makes the next one easier, because your team learns the pattern on the low risk systems before applying it to the ones that would hurt.

The Migration Framework: Six Phases

Phase 1: Audit and Plan, 2 to 3 Weeks

Start by answering what you are actually migrating. What is on your servers, what is the current data size, who uses what, and what dependencies exist between systems? Almost every organization discovers something in this phase that nobody remembered was running.

Build a written inventory covering, for each system: the application name, version, last update date, and who uses it; the data size, backup frequency, and whether the backup has actually been verified rather than assumed; the integration points, meaning what talks to what; the security and compliance requirements, including whether any of the data is regulated; and your current downtime tolerance, meaning what an acceptable outage looks like for that system.

Then choose the approach for each system. Lift and shift moves it as-is to the cloud equivalent, which is fastest but leaves existing problems in place. Lift and optimize cleans data and settings during the migration, which takes longer but means you exit cleaner. Replace means abandoning the old system entirely for new software, which is riskiest if the old system has unique features you depend on, and best if you have simply outgrown it. As a rule, email and files are fine with lift and shift, while databases usually reward lift and optimize.

Phase 2: Prepare the Cloud Destination, 1 to 2 Weeks

Set up the cloud accounts properly before any data moves. If you are moving to a hosted email suite, provision accounts for everyone and configure email forwarding, security settings, and data retention. If you are moving to a hosted CRM, configure users, security roles, and customizations first. Then test everything: can users log in, do the integrations connect, does the backup actually run?

Create a rollback plan in this phase, not later. If something goes wrong, how exactly do you get back to the old system? This is your safety net and it needs to be written down while nobody is panicking. For email, keep the old server running for a week after migration. For databases, keep a copy of the old data accessible. A rollback plan that exists only in one person's head is not a rollback plan.

Phase 3: Data Migration, 2 to 4 Weeks

This is the technical heart of the project, where data moves from the old system to the new one. For email, use a migration tool, since the major providers each supply one. Migrate a batch of test users first, and if their mailboxes come across cleanly, move the rest in waves rather than all at once. If something fails mid-migration, those test users are what you debug against.

For files, start with a sample folder and check three things: does everything copy, are permissions maintained, and do shortcuts and links still work? Only proceed to the full migration once those answers are yes, and plan for the largest files to take the longest. For databases, export from the old system, clean and transform as needed, then import. Verify record counts to confirm everything came over, spot-check random records to confirm the data is intact rather than merely present, and run whatever validations the new system offers.

Keep detailed logs throughout: what moved, when, what failed, and why. When you are debugging a missing record weeks later, those logs are the difference between an hour of work and a week of it.

Phase 4: User Training and Testing, 1 to 2 Weeks

Train people before you go live, and train them on the specific differences rather than on the software in general. Write short guides for the things that actually changed: how to send an email in the new suite when your staff learned email in Outlook, or how to share a file with someone outside the organization when your staff learned sharing through permissions on a network drive.

Have staff use the new system in parallel with the old one during this phase, so they discover the pain points while the old system is still there to fall back on. For critical functions, do a genuine dry run. Actually send a donor communication from the new email system. Actually run a report from the new database. A dry run that stops short of the real action tests only the parts nobody was worried about.

Phase 5: Cutover, One Day With a Week of Support

Cutover is the moment you turn off the old system and go live on the new one. Timing matters more than people expect. Migrate on a Thursday afternoon, not before a major event and not before year-end close, so you are choosing a calm window in which you can actually watch for problems rather than firefighting during your busiest week.

• Confirm all data is in the new system by running one final validation.
• Update all connections and integrations to point at the new system.
• Tell staff clearly: we go live at 3pm, and the old system becomes read-only.
• Do the cutover.
• Verify that users can access the system and do their core jobs, not just log in.
• Keep the old system running as read-only for a week as a safety net.
• Have support staff on call for questions.

Plan for 10 to 20% of people to have trouble with the new system immediately. That is normal and it is not a sign the migration failed. What matters is that the escalation path is clear: when something does not work, everyone should already know who to call, because the alternative is people quietly working around a problem you never hear about.

Phase 6: Optimization and Closeout, Weeks 2 to 4 and Ongoing

You have moved. Now optimize. Users find better ways to work in the new system, processes change to match it, security settings often need tuning, and backups may need adjusting once you see real usage patterns. Schedule a 30-day retrospective covering what went well, what went badly, and what you would change, then a 90-day check on whether the new system is meeting needs and what unexpected problems have surfaced.

After 30 days with zero issues, decommission the old system. Archive its data if compliance requires it, then turn it off. Leaving the old server running indefinitely because nobody wants to make the call is how organizations end up paying for and securing two systems at once.

Common Migration Mistakes and How to Avoid Them

Migrating everything at once. Move email and files first because they are straightforward, get that working, then move databases. Breaking the work into phases reduces risk and lets your team learn on the systems where mistakes are cheap.

Not planning for downtime. Even a migration billed as having no downtime has rough periods. Email may be delayed during sync and files may be slow during transfer. Plan staff coverage for the disruption and have a list of non-urgent tasks people can pick up when email is crawling.

Assuming the new system works like the old one. It does not. Google Drive is not a shared drive and Microsoft 365 is not Exchange. Train people on the actual differences, because the frustration that sinks adoption usually comes from small mismatches between what someone expects and what the software does.

Forgetting about integrations. Your CRM connects to your accounting system, which connects to your email. Migration breaks those connections if you are not careful. Map every integration before you start and test each one afterward, rather than waiting for a finance person to notice that gifts stopped syncing.

Migrating dirty data. If your database is messy now, it will be messy in the cloud, and you will be paying cloud costs to store bad data. Spend the time cleaning before migration, which is also the argument for choosing lift and optimize over lift and shift on database systems.

Budgeting the Project

Migration costs split into project costs and ongoing costs, and they behave differently. Project costs are one-time and cover planning, setup, training, and support, which are the four line items to price for an email and file migration in an organization under 100 people. A small database migration is priced by complexity rather than by headcount, and a major ERP system is priced by scope, which is why those two are quoted rather than listed.

Current figures for those three tiers are not listed here, so do not treat the shape of the estimate as a substitute for a quote. Price it locally, and price all four components rather than just the setup, since training and post-launch support are the parts most often left out of an optimistic estimate and most often needed.

Ongoing costs are the clearer part of the picture. Ongoing cloud costs are lower than ongoing on-premises costs once you account for server maintenance, electricity, and the in-house expertise a server requires. The return comes from eliminated server maintenance, reduced security risk, improved disaster recovery, and less specialist knowledge needed on staff. For most nonprofits, cloud is cheaper and safer after year one.

When to Hire a Consultant

Hire a consultant when your data is complex, your integrations are interdependent, or you hold regulated data. In those cases outside expertise prevents expensive mistakes, and the mistakes it prevents are the kind that surface months later in a compliance review rather than immediately. Do not hire a consultant to migrate email and files, which is straightforward work with abundant public documentation. Do it yourself, or bring in a contractor for the hands-on hours, rather than engaging a consulting firm for a project that does not need one.

Anti-Patterns

• Treating "it has not failed yet" as evidence that it works. Silent backup failures and unpatched servers do not announce themselves until the day they matter.
• Skipping the inventory. Migrating without knowing data sizes, dependencies, and who uses what guarantees that something important is discovered at cutover.
• Writing no rollback plan. If the answer to "how do we get back" lives in one administrator's head, you have no safety net.
• Migrating all users at once. Waves exist so that a failure affects a test batch rather than the whole staff, and so you have somewhere to debug.
• Verifying record counts and stopping there. Counts prove records arrived; only spot-checking proves the contents survived intact.
• Cutting over before a major event or year-end close. The calm window is a real requirement, not a scheduling preference.
• Decommissioning the old system on cutover day. The read-only week is what turns a bad surprise into an inconvenience.
• Leaving the old system running forever. Once the 30-day period passes cleanly, archive what compliance requires and switch it off, or you pay for and secure two systems indefinitely.

Practice Prompts

• Build the inventory for one system you still run in-house, filling in every field: version, last update, users, data size, backup frequency, backup verified, integrations, compliance requirements, and downtime tolerance.
• Pick one of your systems and argue the case for each of the three approaches, lift and shift, lift and optimize, and replace, then decide which you would choose and why.
• Write the rollback plan for an email migration in enough detail that someone other than you could execute it.
• Draw the integration map for your CRM: everything it sends data to and receives data from, including anything that runs on a schedule.
• Draft the staff message announcing a cutover, including the time, what becomes read-only, and who to contact when something does not work.
• Check when your current backup was last restored from, as opposed to last run. If nobody knows, that is the finding.
• Write the agenda for a 30-day migration retrospective before the migration starts, so the questions are set while you are still objective.

Reflection

Think about the infrastructure your organization depends on but nobody owns. There is usually one machine, one spreadsheet, or one integration that a single person understands, and everyone else has agreed not to think about it. Migration is uncomfortable partly because it forces that knowledge into the open, and that discomfort is exactly the value. Ask yourself what would happen tomorrow if the person who knows your server left, and whether your answer is a plan or a hope. The organizations that migrate well are usually the ones that answered that question honestly first.

Glossary

• On-premises: software and data running on hardware your organization owns and maintains, typically in your own building.
• Lift and shift: moving a system to its cloud equivalent unchanged, prioritizing speed over cleanup.
• Lift and optimize: cleaning data and settings as part of the move, which takes longer and leaves you with a tidier system.
• Replace: retiring the old system entirely in favor of new software rather than moving what you had.
• Cutover: the moment the old system stops being authoritative and the new one goes live.
• Rollback plan: the documented route back to the old system if the cutover fails.
• Read-only period: the window after cutover during which the old system remains available for reference but cannot be changed.
• Downtime tolerance: how long a given system can be unavailable before it damages operations, decided per system rather than organization-wide.
• Versioning: a backup capability that retains previous copies of a file, allowing recovery from corruption or deletion rather than only from hardware failure.

Related Lessons

• Data Quality for Nonprofits: The CRM Hygiene Guide
• Integrating Your Tools: APIs, Zapier, and Manual Processes
• The Nonprofit Technology Assessment: Where Are Your Gaps?
• Cybersecurity for Nonprofits: The Essential Checklist
• Third-Party Vendor Risk: Protecting Data Across Your Tool Chain
• Building Your Nonprofit Tech Stack on a Budget
• Nonprofit Data Strategy: Building the Foundation for AI and Analytics

Closing

Cloud migration is a project, not a catastrophe. Plan it carefully, execute it in phases, keep the old system as a safety net for as long as it is useful and no longer, and support your staff through the transition rather than assuming they will figure it out. On the other side you have less infrastructure to worry about, better disaster recovery, and money that used to go to server maintenance available for the mission instead. The organizations that struggle are almost never the ones that moved too fast; they are the ones that moved everything at once, skipped the inventory, or never wrote down how to get back. Start with email and files, learn the pattern, and let the next migration be easier than the last.

Key Takeaways

• The risk is not migrating. Every day on unmaintained infrastructure is a day your data is exposed, and the true cost of a server includes labor, power, and single points of failure.
• Migration is several projects. Sequence email and files first, then databases and CRM, then specialized systems.
• Six phases structure the work: audit and plan, prepare the destination, migrate data, train and test, cut over, then optimize and close out.
• Choose an approach per system. Email and files suit lift and shift; databases usually reward lift and optimize.
• Migrate in waves with test users first, verify record counts, and spot-check contents rather than trusting the count alone.
• Write the rollback plan before you need it, and keep the old system read-only for a week after cutover.
• Expect 10 to 20% of staff to hit trouble immediately, and make the escalation path explicit before go-live.
• Budget planning, setup, training, and support as separate line items, and get a local quote rather than relying on a published estimate.

Frequently Asked Questions

What if our data is sensitive or regulated, for example under HIPAA? Cloud services exist for regulated data, and the major providers hold compliance certifications such as HIPAA and FedRAMP. Your data may well be more secure in the cloud than on your own server, since these providers employ more security expertise than most nonprofits can. But the responsibility does not transfer automatically: you must choose a provider certified for your specific regulation and ensure the data is encrypted. If you are unsure whether a configuration meets your obligations, hire a compliance consultant rather than guessing.

What if we lose internet connectivity? Will everything break? You will lose access to cloud services, yes. But you would also have lost access to an on-premises server if the building lost power, so the comparison is not as one-sided as it first appears. The advantage of cloud is location independence: if your office loses internet, staff can work from home, whereas with on-premises servers they are stuck. For genuinely critical functions, many cloud services offer offline modes, where documents sync and remain editable, then reconcile when you are back online.

How long is typical downtime during migration? For email, 30 minutes to 2 hours. For file shares, it can be done with zero downtime, since the new system runs in parallel with the old one. For databases it depends on size: a 10GB database might be down for 4 hours, while a 100GB database might be down for 12 hours or more. Plan against your own data sizes, which is what the Phase 1 inventory is for, and schedule the work during low-activity periods.

After we migrate, do we need someone to manage the cloud? Less than before. The vendor manages the service itself, so you no longer need a server administrator. You do still need someone to manage user access, security settings, and integrations, which is usually a quarter-time IT responsibility rather than a full-time role. That person needs to understand your provider's control panel well enough to create users, reset passwords, and adjust security settings confidently.

Should we migrate everything at once or gradually? Gradually. Email and files first, then CRM and databases, then specialized systems. Each migration teaches lessons that make the next one cheaper, and all-at-once migrations carry too many moving parts to control. Phased migrations take longer in calendar time but are far more manageable, and they let you stop and reassess between systems instead of discovering a problem when everything is already in motion.