Moving to the Cloud: A Nonprofit Migration Guide

Most nonprofits are already in the cloud. You use Google Workspace, Stripe, and Salesforce. But some still run old servers in closets: file shares on a local box, email on an Exchange server, databases on machines you've had for six years.

Cloud migration is less about being trendy and more about avoiding painful reality. Running your own server means: you're responsible for backups (did they work?), security (did someone hack it?), updates (when was it last patched?), and disaster recovery (what happens if the hard drive dies?). That's not your mission.

This lecture walks you through planning a migration that doesn't crash your operations.

Why Nonprofits Delay Cloud Migration

Fear. Migration sounds scary. You'll lose data. Things will break. Staff won't know how to use the new system. Downtime will hurt programs.

Also, inertia. "Our system works. Why change?" Except it kind of doesn't work. It's slow. It crashes. Backups fail silently. Updates take weeks. But since it hasn't catastrophically failed yet, leadership says "don't touch it."

Also, cost. "Cloud software costs money. Our server is already paid for." Except your server requires someone to manage it, it has annual electricity/cooling costs, and it's one hard drive failure away from data loss. The true cost of keeping on-premises infrastructure is often higher than cloud.

The real risk isn't migration. It's not migrating. Every day you keep old infrastructure is a day your data is at risk.

What You're Actually Moving

Cloud migration isn't one thing. It's multiple things:

• Email: If you run Exchange on your own server, move to Google Workspace or Microsoft 365
• File storage: If you have shared drives on a local server, move to Google Drive, OneDrive, or Dropbox
• Database/CRM: If you host it yourself, move to SaaS version (Salesforce, HubSpot, etc.)
• Websites: If you host on your server, move to managed hosting or headless CMS
• Backup/disaster recovery: If you have one backup drive, move to cloud backup with versioning and off-site copies

Prioritize this way: email and file storage first (easiest, highest value). Then databases/CRM (more complex but core to operations). Then specialized systems (depends on your nonprofit).

The Migration Framework: Six Phases

Phase 1: Audit and Plan (2-3 weeks)

What are you actually migrating? What's on your servers? What's the current data size? Who uses what? What dependencies exist?

Create an inventory:

• Application name, version, last update date, who uses it
• Data size, backup frequency, backup working (verified?)
• Integration points (what talks to what?)
• Security/compliance requirements (is data regulated?)
• Current downtime tolerance (what's acceptable?)

Then identify the migration approach:

• Lift and shift: Move as-is to cloud equivalent. Fastest but might not optimize.
• Lift and optimize: Clean data/settings during migration. Takes longer but you exit cleaner.
• Replace: Stop using the old system, move to new SaaS. Riskiest if old system has unique features, best if you've outgrown it.

For email and files: lift and shift works fine. For databases: lift and optimize is usually better.

Phase 2: Prepare Cloud Destination (1-2 weeks)

Set up your cloud accounts. If moving to Google Workspace, provision accounts for everyone. Configure email forwarding, security settings, data retention. If moving to Salesforce, configure users, security roles, customizations.

Test everything. Can users log in? Do integrations connect? Does backup work?

Create a rollback plan: if something goes wrong, how do you get back to the old system? This is your safety net. For email, keep the old server running for a week after migration. For databases, keep a copy of the old data accessible.

Phase 3: Data Migration (2-4 weeks)

Move your data from old system to new. This is the technical heart of the project.

For email: use a migration tool (Google has one, Microsoft has one). Create a batch of test users and migrate their mailboxes first. If successful, migrate remaining users in waves (not all at once). If something fails mid-migration, you have test users to debug with.

For files: start with a sample folder. Does everything copy? Are permissions maintained? Do shortcuts/links work? If yes, proceed to full migration. Plan for the largest files to take longest.

For databases: export data from old system, clean/transform as needed, import to new system. Verify counts (did all records come over?). Spot-check random records (is the data intact?). Run any validations the new system has.

Critical: keep detailed logs. What moved when? What failed? Why? When you're debugging later, these logs matter.

Phase 4: User Training and Testing (1-2 weeks)

Before you go live, train users on the new system. Create a guide: "How to send an email in Google Workspace" (different from Outlook). "How to share a file with someone outside the organization" (different from permissions on a shared drive).

Have staff use the new system in parallel with the old one during this phase. Let them discover pain points before you've cut off the old system.

For critical functions, do a dry run. Actually send out a donor communication from the new email system. Actually run a report from the new database. Does everything work?

Phase 5: Cutover (1 day, 1 week support)

This is the moment you turn off the old system and go live on the new one.

Timing matters. Migrate on a Thursday afternoon. Not before a major event. Not before year-end close. Choose a calm time when you can watch for problems.

Steps:

1. Confirm all data is in the new system (run one final validation)
2. Update all connections/integrations to point to new system
3. Tell staff: we're going live at 3pm, the old system will be read-only
4. Do the cutover
5. Verify: can users access? Can they do their core jobs?
6. Keep the old system running as read-only for a week (safety net)
7. Have support staff on call for questions

Plan for 10-20% of people to have trouble with the new system immediately. This is normal. Have clear escalation: if something doesn't work, who do they call?

Phase 6: Optimization and Closeout (ongoing, weeks 2-4)

You've moved. Now optimize. Users will find better ways to use the new system. Processes will change. Security settings might need tuning. Backups might need optimization.

Schedule a 30-day retrospective: what went well, what went badly, what do we change? Then a 90-day check: is the new system meeting needs? Are there unexpected problems?

After 30 days with zero issues, decommission the old system. Archive data if required by compliance, then turn it off.

Common Migration Mistakes and How to Avoid Them

Mistake 1: Trying to migrate everything at once. Migrate email and files first (straightforward). Get that working. Then migrate databases (more complex). Breaking it into phases reduces risk and lets you learn.

Mistake 2: Not planning for downtime. Even a "no-downtime" migration has rough periods. Email might be delayed during sync. Files might be slow during transfer. Plan staff coverage for disruption. Have a list of non-urgent tasks people can do if email is slow.

Mistake 3: Assuming the new system works the same as the old one. It doesn't. Google Drive isn't a shared drive. Microsoft 365 isn't Exchange. Train people on the actual differences. This prevents frustration.

Mistake 4: Forgetting about integrations. Your CRM connects to your accounting system, which connects to your email. Migration breaks these connections if you're not careful. Map every integration before migration. Test them after.

Mistake 5: Migrating dirty data. If your database is messy now, it will be messy in the cloud. Spend time before migration cleaning data (see previous lecture). Otherwise you're paying cloud costs for bad data.

Cost Estimate for Migration

Nonprofit email/file migration (under 100 people): $5,000-15,000 including planning, setup, training, support.

Small database migration: $10,000-30,000 depending on complexity.

Major ERP system: $50,000-200,000 depending on scope.

These are project costs. Ongoing cloud costs are lower than ongoing on-premises costs (no server maintenance, electricity, expertise required).

The ROI: eliminated server maintenance, reduced security risk, improved disaster recovery, less expertise needed on staff. For most nonprofits, cloud is cheaper and safer after year one.

When to Hire a Consultant

Hire a consultant if: your data is complex, your integrations are interdependent, or you have regulated data. A consultant costs $100-200/hour but prevents expensive mistakes.

Don't hire a consultant if: you're migrating email and files (straightforward, many tutorials online). Do it yourself or hire a contractor, not a fancy consulting firm.

Key Takeaway

Cloud migration is a project, not a catastrophe. Plan it carefully. Execute in phases. Keep the old system as a safety net. Support your staff during the transition. On the other side, you have less infrastructure to worry about, better disaster recovery, and money saved on server maintenance. It's worth doing well.