How to Run a Cloud Migration for Nonprofits: A Security-First, Step-by-Step Guide

Scottship Solutions runs cloud migration for nonprofits using a 5-phase playbook (Assess, Design, Pilot, Cutover, Stabilize) drawn from years of cloud migration work across regulated environments including military systems. The playbook moves small and mid-sized nonprofits from on-premises servers to Microsoft 365, Google Workspace, Azure, or AWS with zero scheduled downtime as the cutover target. A typical nonprofit migration runs 6 to 10 weeks. This guide walks through each phase, what it costs, and the security checklist the playbook is built around.

I’m Josh Bass, Cybersecurity Consultant at Scottship. My background is cloud migration work across regulated environments including military systems, and I lead Scottship’s cloud migration practice for nonprofits holding donor PII, client case files, and HIPAA-regulated records. The security-first framing in this guide is the one thing I want every nonprofit director to take away. Most migration guides treat data protection as a step near the end. We treat it as phase one, before a single mailbox moves.

If you are still deciding whether the cloud is the right move, start with our cloud technology for nonprofits overview. If you are scoping budget at the strategic level, start with our IT cloud services for nonprofits guide. This post is the step-by-step execution playbook that follows both.

What You’ll Learn

1. How much does cloud migration for nonprofits cost?
2. What are the 5 phases of a secure nonprofit cloud migration?
3. How long does a nonprofit cloud migration take?
4. Which cloud platform is best: Microsoft 365, Google Workspace, AWS, or Azure?
5. How do we protect donor data, PII, and HIPAA records during migration?
6. Do we need a consultant, or can we DIY it?
7. What is the Scottship cloud migration checklist?
8. Frequently asked questions
9. Your next steps

How much does cloud migration for nonprofits cost?

A nonprofit cloud migration typically runs between $5,000 and $50,000 in project cost, depending on headcount, data volume, and compliance scope. The biggest single variable is not the destination platform. It is how clean the source environment is when the project starts.

Published pricing is rare in this space. No page-1 Google result for “cloud migration for nonprofits” publishes real ranges, which makes it hard for a nonprofit operations lead to budget the project before a sales call. Here are the ranges Scottship works from when scoping nonprofit cloud migration engagements. Treat them as typical, not fixed, because the final quote depends on data volume, legacy system complexity, and compliance scope.

The project cost breaks into six components. Discovery and assessment is usually 10 to 15 percent of the project. License setup and tenant configuration is another 10 percent. Data migration tooling and execution, which includes the actual mailbox and file moves, is the largest line at 40 to 50 percent. Consulting hours for architecture and security review run 15 to 20 percent. End-user training is 5 to 10 percent. Post-migration support for the first 30 days is the remaining 5 to 10 percent.

Nonprofit discounts offset a meaningful portion of the ongoing license cost, though they do not reduce the project fee itself. Microsoft 365 Business Premium is available to qualifying nonprofits at a steep discount through the Microsoft Nonprofit program. Google Workspace for Nonprofits offers the Business Starter edition at no cost for eligible organizations. AWS provides a $1,000 Promotional Credit through the AWS Migration Acceleration Program for qualifying nonprofits, and Microsoft Azure offers nonprofit credits through its philanthropy program. Treat these as cost offsets on the ongoing license budget, not as a reason to skip the migration planning work.

What are the 5 phases of a secure nonprofit cloud migration?

The Scottship 5-Phase Nonprofit Cloud Migration Playbook moves a nonprofit from on-premises servers to the cloud in a defined sequence: Assess, Design, Pilot, Cutover, Stabilize. Each phase has a clear entry criterion, a clear exit criterion, and a named deliverable. No phase starts before the previous one is signed off.

Most migration failures I’ve seen in cloud migration work trace back to one of two things. Either Phase 1 (Assess) was skipped and the team started designing before they knew what data they had. Or Phase 3 (Pilot) was skipped and the team tried to cut over the whole organization in one weekend. Both are preventable.

Phase 1: Assess

We inventory every server, mailbox, file share, line-of-business application, and SaaS subscription in use. We classify data by sensitivity (public, internal, donor PII, HIPAA-regulated, financial). We map which staff roles touch which data. The deliverable is a risk register that names every sensitive data set, where it lives today, and what happens to it during and after migration. Assess is phase one because data protection is load-bearing, not an afterthought.

Phase 2: Design

We select the target platform (Microsoft 365, Google Workspace, Azure, AWS, or a hybrid), design the tenant architecture, and document the identity model. MFA rollout happens here, before any mailbox moves. Backup strategy is designed here too, because a cloud tenant without an independent backup is not a backed-up system. The deliverable is a migration design document that a different engineer could execute from.

Phase 3: Pilot

We move one department or roughly 10 percent of users to the new environment. We validate mail flow, file access, shared calendars, mobile sync, and any line-of-business integrations. We capture lessons and fix gaps before touching the rest of the organization. The deliverable is a pilot sign-off from the department lead plus an updated runbook.

Phase 4: Cutover

We move the remaining users in waves, not a big-bang weekend. Data syncs continuously up to the cutover moment. DNS records are pre-staged with low TTLs. End users experience no scheduled downtime because the new environment is live before the old one is turned off. The deliverable is a completed cutover log with every user migrated and validated.

Phase 5: Stabilize

We run user training, monitor the new environment for 30 days, perform post-migration security validation (access review, log review, DLP configuration, MFA enrollment audit), and decommission the old servers on a documented schedule. The deliverable is a closeout report and a handoff to ongoing managed services if the client is on retainer.

How long does a nonprofit cloud migration take?

Timeline is a function of user count, data volume, and compliance scope. Below 25 users, most migrations run 4 to 6 weeks. Between 25 and 100 users, 6 to 10 weeks is typical. Above 100 users or with regulated data in the mix, 10 to 16 weeks is realistic.

Here is an illustrative scenario we use with prospects to show what a typical mid-sized engagement looks like. Consider a 40-person human services nonprofit running on-premises Exchange, a file server, and a legacy case management system. Assess takes 1.5 weeks to inventory and classify everything. Design takes 1 week. Pilot takes 2 weeks with the finance department as the test group. Cutover takes 3 weeks in two waves. Stabilize runs 30 days in parallel with go-live. Total elapsed time: about 8 weeks of active engagement plus a 30-day stabilization window. This is illustrative, not a named client engagement.

Three things compress the timeline. A clean user and device inventory, a strong internal project sponsor who can make decisions without committee, and a willingness to retire legacy applications rather than re-platform them all. Three things stretch the timeline. Legacy line-of-business applications with no cloud equivalent, compliance sign-offs that require board approval, and data cleanup that should have happened years ago and finally has to happen now.

Which cloud platform is best for a nonprofit migration: Microsoft 365, Google Workspace, AWS, or Azure?

The right platform depends on what you are actually migrating. Microsoft 365 and Google Workspace are productivity suites (email, files, collaboration). AWS and Azure are infrastructure platforms (servers, databases, custom applications). Most nonprofits need a productivity suite first and a hyperscaler second, if at all.

Pick Microsoft 365 if your staff already live in Outlook and Word, your IT environment is Windows-heavy, or you need Intune for mobile device management. Pick Google Workspace if your staff already use Gmail and Docs, your devices are mixed or Chromebook-based, or you want lower administrative overhead. A hybrid (Microsoft 365 for email and Google Workspace for a specific team) is rarely worth the complexity for a nonprofit under 100 users.

Azure and AWS are not replacements for Microsoft 365 or Google Workspace. They are where you put infrastructure workloads: a custom case management database, a legacy Windows application that has to keep running, a data warehouse for grant reporting. For most nonprofits we work with, the productivity migration happens first and the infrastructure migration (if any) happens 6 to 12 months later as a separate project.

How do we protect donor data, PII, and HIPAA records during cloud migration?

This is the question that should drive the entire project, and it is the question most migration guides skip. A nonprofit cloud migration is a data protection exercise that happens to involve mailboxes. If your organization holds donor PII, client case files, or HIPAA-regulated health records, security is not a phase. It is the frame around every phase.

Here is the security checklist that anchors the Scottship playbook, organized by when the work happens.

Pre-migration (Phase 1 and 2)

• Data classification complete, every data set labeled by sensitivity
• Access audit of the source environment, including service accounts and shared mailboxes
• MFA rolled out to all users before any data moves
• Full backup of the source system verified and restorable
• Risk register signed off by the executive director or operations lead
• HIPAA Business Associate Agreement (BAA) in place with the destination cloud vendor if health data is in scope

During migration (Phase 3 and 4)

• All data transfer encrypted in transit (TLS 1.2 or higher)
• Migration service accounts use least-privilege permissions, not admin-level
• Access logging enabled on both source and destination during cutover
• Pilot group reviewed for unexpected data exposure before broad rollout
• DLP policies configured on the destination tenant before bulk data lands

Post-migration (Phase 5)

• Full access review: who has permissions to what, and does it match the pre-migration plan
• Log review for anomalies in the first 30 days
• DLP policies tuned and alerts routed to a monitored inbox
• Phishing-resilience training delivered to all users on the new environment
• Source servers decommissioned on a documented schedule, not left running “just in case”

As adjacent proof of Scottship’s security posture (not a cloud migration outcome), our Phishing Attack Prevention case study documents a nonprofit engagement where we deployed IRONSCALES and blocked more than 2,000 malicious email attacks in the first reporting period. The security discipline behind that engagement is the same discipline we apply to cloud migration work.

Do we need a consultant to migrate to the cloud, or can we DIY it?

DIY is realistic in a narrow band. If your nonprofit has fewer than 10 users, a single target platform, no regulated data, and an internal IT-comfortable staff member with a clear weekend to commit, you can run the migration yourself using built-in Microsoft or Google tooling. This is the real answer, not a setup for a sales pitch. Small orgs have done this successfully for years.

A consultant pays for itself in four specific situations. First, any organization holding HIPAA-regulated records or donor PII at volume, because the compliance cost of a data exposure dwarfs the consulting fee. Second, any organization above 20 users, where the coordination overhead of scheduling, communicating, and validating the migration becomes a full-time job for weeks. Third, any organization with legacy on-premises systems (old Exchange, Windows Server file shares, custom applications) that need decisions about what to retire versus what to re-platform. Fourth, any organization with a tight cutover window driven by a lease expiration, a hardware failure, or a board deadline.

A Scottship cloud migration engagement combines fractional CIO oversight, hands-on security and cutover execution, and 30 days of post-migration support. Our team’s experience includes cloud migration work across regulated environments including military systems, which is where the security-first discipline in this playbook comes from. Scottship is a Pax8 Cloud Marketplace Partner, which gives us direct vendor relationships for licensing and escalation, and I hold a CompTIA Security+ certification and lead security assessments and compliance audits across client engagements. If you want a broader look at your environment before committing to a migration, the pre-migration engagement most clients run with us is a nonprofit tech stack audit. That audit is usually the cleanest way to decide what to migrate, what to retire, and what to leave alone.

What is the Scottship cloud migration checklist?

This is the checklist that drives the Scottship playbook. It is phase-aligned, so you can map it directly to the 5-phase playbook above. Print it, share it with your team, and treat any unchecked item as a reason to pause the project.

Phase 1: Assess

1. Full inventory complete (users, devices, mailboxes, file shares, applications, SaaS subscriptions)
2. Data classified by sensitivity (public, internal, PII, HIPAA, financial)
3. Access audit complete on the source environment
4. Risk register drafted and signed off
5. Project sponsor and decision-maker named

Phase 2: Design

1. Target platform selected and documented
2. Tenant architecture designed (domains, groups, licensing plan)
3. Identity model and MFA rollout plan documented
4. Backup strategy for the destination cloud documented
5. Migration design document reviewed with the client

Phase 3: Pilot

1. Pilot group selected (one department or 10 percent of users)
2. MFA enrolled for all pilot users
3. Pilot cutover executed and validated
4. Pilot feedback captured and runbook updated
5. Pilot sign-off from department lead

Phase 4: Cutover

1. DNS TTLs lowered in advance
2. User communication sent (date, what to expect, who to contact)
3. Cutover windows booked with clear rollback criteria
4. Data sync verified at cutover moment
5. Every user validated post-cutover

Phase 5: Stabilize

1. User training delivered (live session plus recorded reference)
2. Access review complete
3. Log review complete for the first 30 days
4. DLP and security monitoring configured
5. Source systems decommissioned on schedule
6. Closeout report delivered
7. Post-cutover review meeting scheduled

Frequently Asked Questions

How much does cloud migration cost for a nonprofit?

Most nonprofit cloud migrations fall between $5,000 and $50,000 in project cost. A small organization under 25 users typically runs $5,000 to $10,000 for a Microsoft 365 or Google Workspace migration from on-premises email. A mid-sized organization between 25 and 100 users runs $10,000 to $20,000 when file servers are included. At Scottship, our ranges depend on data volume, legacy system complexity, and whether HIPAA or donor PII is in scope.

What are the benefits of cloud migration for a nonprofit?

The three benefits that matter most for nonprofits are eliminated server and maintenance costs, a stronger security posture through built-in MFA and identity management, and the ability for staff to work from anywhere without VPN workarounds. A well-scoped nonprofit cloud migration commonly pays for itself inside 12 months through reduced hardware, license, and support costs. The security improvement is harder to put a dollar figure on, and is the bigger win for most nonprofits carrying donor PII.

How long does a nonprofit cloud migration take?

A small nonprofit under 25 users typically completes migration in 4 to 6 weeks. A mid-sized nonprofit between 25 and 100 users runs 6 to 10 weeks. Organizations above 100 users, or those with regulated data and legacy applications, run 10 to 16 weeks. The timeline compresses with clean inventory and a strong project sponsor, and stretches with legacy applications and compliance sign-offs.

Which cloud is best for nonprofits: Microsoft 365, Google Workspace, AWS, or Azure?

For most nonprofits, the productivity suite choice is between Microsoft 365 and Google Workspace. Microsoft 365 fits organizations already on Windows and Outlook, while Google Workspace fits organizations on Gmail or Chromebooks. AWS and Azure are infrastructure platforms for custom applications and databases, not email replacements. At Scottship, we recommend starting with the productivity migration first and layering in AWS or Azure later if there are specific workloads that require it.

How do we migrate from on-premises servers to the cloud without downtime?

Zero scheduled downtime is possible when the new environment is live and validated before the old one is turned off. Mail and file data syncs continuously through the migration window. DNS records are pre-staged with low TTLs so the cutover is fast. User accounts are migrated in waves, not all at once. This is the core of the Scottship 5-Phase Playbook, and it is the reason Phase 3 (Pilot) exists: so the cutover pattern is proven before it runs against the whole organization.

Your Next Steps

1. Inventory what you have. Before you talk to any vendor, list every server, mailbox, file share, and application in use. You cannot budget a migration you have not scoped.
2. Classify your data. Identify which systems hold donor PII, client case files, or HIPAA-regulated records. This drives the security requirements for every later decision.
3. Name a project sponsor. Pick one internal decision-maker who can approve trade-offs without convening a committee. Migrations stall without one.
4. Scope a pre-migration audit. A dedicated audit is the cleanest way to go from “we should probably move to the cloud” to a defensible project plan.
5. Get a pricing range in writing. Use the table in this guide to set your expectations before the first sales call, so you can compare proposals against a benchmark rather than a blank page.

Sources

• Microsoft for Nonprofits: discounted Microsoft 365 Business Premium pricing for qualifying nonprofit organizations
• Google for Nonprofits: Google Workspace for Nonprofits Business Starter free for eligible organizations
• AWS for Nonprofits: $1,000 Promotional Credit through the AWS Migration Acceleration Program
• Microsoft Azure for Nonprofits: Azure credits through the Microsoft philanthropy program
• U.S. Department of Health and Human Services: HIPAA Business Associate Agreement requirements
• Microsoft Azure Cloud Adoption Framework: free planning toolkit referenced in the industry

Plan Your Nonprofit Cloud Migration With Scottship

At Scottship Solutions, we help nonprofits move from on-premises servers to the cloud without losing a day of mission work or a byte of donor data. From our cloud services for nonprofits hub to our security-first 5-phase playbook, our team brings discipline to every project. We also provide managed IT services for nonprofits for organizations that want ongoing support after the migration is complete.

Written by

Josh Bass

Cybersecurity Consultant at Scottship Solutions

Josh leads security assessments and compliance audits for mission-driven organizations. He helps nonprofits build defensible security postures, meet HIPAA and state privacy requirements, and respond to threats before they become incidents.

Certifications

CompTIA Security+ Certified

Industries Served

Healthcare & Community Health (HIPAA), Human Services, Child Advocacy, Foundations & Grantmakers

If you want a second set of eyes on your migration plan, or you want the checklist above tailored to your organization, schedule a consultation today. We will tell you honestly whether a consultant is the right call for your size and scope, or whether you are in the DIY band and just need a checklist.

For related reading, see our cloud services guide and our cloud managed services overview. Together with this post, they cover the full decision path from “should we move” through “what should we pay for ongoing support after the move.”