Before you migrate: a nonprofit file and records migration checklist

Decide why you’re moving, and what “done” looks like

Write down the reason in a sentence or two. “Our server is old” is a reason. “Staff can’t find anything, and we can’t tell who has access to what” is a better one, because it tells you what to fix along the way.

Then name three or four things that would show the move worked. For example: staff can find last year’s grant report in under a minute, access matches job roles, and the old server can be shut off. Those become your test at the end.

Take inventory before you move anything

You can’t plan a move you can’t see. Before choosing what goes where, list what you have: the top-level folders, roughly how big each is, who uses it, who owns it, and when it was last changed. A spreadsheet is fine. Most migration tools can also scan a source and report problems without moving anything. Microsoft’s file share migration guidance, for example, describes a scan-only setting in its SharePoint Migration Tool for exactly this (Microsoft Learn).

The inventory is also a good time to see how the new home should be organized. Our guide to organizing a nonprofit shared drive covers structure in more detail. Decide the shape of the new space before you fill it, not after.

Decide what not to move

A migration is the one moment when it’s easy to leave things behind, and it’s tempting to use it as a clean-out. Be careful here. Moving less is a good goal. Deciding what can be deleted is a different job, and it doesn’t belong to the migration project.

What your organization must keep, and for how long, is set by its approved retention requirements, its funders and contracts, and its qualified advisors. Our guide to nonprofit records retention explains how those decisions get made. The migration team’s role is to ask the question and follow the answer, not to make it.

A safe way to work: sort content into three piles. Current and active goes to the new home. Content that must be kept but isn’t in daily use goes to an archive area, or stays in a read-only copy of the old system, according to your requirements. Content you’re not sure about waits until someone with authority decides. Deleting nothing during the move is a perfectly good plan.

Treat sensitive data and access as their own workstream

Ask three questions for each area of the inventory. Does it hold client, health, or personnel information? Who can see it today? Who should be able to see it after the move?

If any records may be covered by privacy rules such as HIPAA, handle them according to your organization’s compliance requirements and your qualified advisors, before the move and not after. As one example of why, HHS’s cloud computing guidance explains that a cloud provider that creates, receives, maintains, or transmits electronic protected health information for a covered entity is a business associate, and that a business associate agreement is needed (HHS). Whether that applies to you, and what to do about it, is a question for your compliance lead or counsel.

Access needs its own attention because tools translate permissions and don’t always carry them over. Microsoft’s documentation on moving from Windows file shares says that Full control, Write, and Read permissions map to SharePoint’s Full control, Contribute, and Read levels, that special permissions such as Deny aren’t saved, and that files for users who can’t be matched to accounts in the new system get the default permissions of their destination (Microsoft Learn). In plain terms: a folder that was locked down on the old server could become more open than you intended.

Google’s large-migration guidance suggests setting permissions on folders before adding files, so that files inherit them, and using shared drives for team content instead of individual ownership (Google Workspace). The same idea works anywhere: set up the empty structure and its access first, then fill it.

Check the technical limits first

Every platform has limits, and a migration is when you’ll hit them. The specific numbers below were checked on September 30, 2026. Vendors change them, so recheck the current pages before you plan. Some limits also vary by organization, and Microsoft notes that higher limits may depend on tenant configuration.

For SharePoint and OneDrive, Microsoft’s limits page says, as of this writing:

• File size. Files can be up to 250 GB for upload.
• Path length. The full decoded path, folder names plus the file name, can’t exceed 400 characters.
• Sync. For best performance, sync no more than 300,000 files in a single library.

Those come from SharePoint limits on Microsoft Learn. Microsoft’s restrictions and limitations page adds that certain characters aren’t allowed in file and folder names (the double quote, asterisk, colon, angle brackets, question mark, slashes, and vertical bar), that leading and trailing spaces aren’t allowed, and that some names are reserved, such as CON, PRN, and any name starting with ~$. It also says an organization may block additional file types.

For Google Drive, Google’s storage and upload limits page says each user can upload and copy 750 GB to Drive within 24 hours, and can upload and sync files up to 5 TB. Its shared drive limits page says a shared drive can hold up to 500,000 items, counting files, folders, shortcuts, and items in the trash, and that folders can nest up to 100 levels deep.

Most small organizations won’t come near the size limits. Path length and odd characters are the usual surprises, because a long folder tree built over many years can push a file past the limit even when every name looks reasonable. Migration tools can also have limits of their own, so check the tool’s documentation.

Clean up names on the old side

Names are cheaper to fix before the move, while people still recognize their own folders. Shorten the deepest paths, flatten folder trees that go eight levels down, and remove the characters and leading or trailing spaces the new platform won’t accept. Agree on a simple naming pattern going forward, such as a date first in year-month-day form, then a short description.

Don’t rename in the middle of a move, and don’t rename a file that’s referred to in a contract or a funder’s records without telling the people who rely on it. Keep a list of what you changed.

Pilot with one team, then plan the cutover and the way back

Pick one team, ideally one with patient staff and a manageable amount of data. Migrate their content, let them work in it for a couple of weeks, and ask what broke. Microsoft’s file share guidance recommends the same pattern: a small pilot group first, use of what you learn to adjust the schedule and communications, then a full migration with a single cutover so people don’t end up editing two copies (Microsoft Learn).

Before cutover day, write the plan on one page. It should say:

• When the old location becomes read-only, and who does that.
• Who is on call to answer staff questions in the first week.
• The rollback plan. If something serious goes wrong, what do you do, and who decides?
• How long you’ll keep the old copy, and where it will live. Keeping it untouched and read-only until verification is finished is the simplest safety net. The old copy also protects you if the migration tool skipped something. Microsoft’s guide notes that things like Deny permissions and items over SharePoint’s restrictions aren’t migrated.

Any change to the old copy’s lifespan is a retention question. Check with whoever owns your records requirements before you retire it.

Prepare staff, then check the work

People adapt to new systems more easily when they know what’s coming. Tell them why you’re moving, when, what changes for them, and where to get help. Show them how to find their files, how sharing works, and what to do if something looks missing. Links pasted into emails and documents may still point to the old location. Microsoft’s guide lists converting links embedded within documents among the things its tool doesn’t do, so some links will need updating by hand.

After the move, verify it against your success list from the start:

• Counts. Compare file and folder counts for each area between old and new, and explain any difference.
• Spot checks. Open a sample of files from every major area, including a few of the oldest and largest.
• Permissions. For each sensitive area, have the person responsible confirm who can see it. Test with an account that shouldn’t have access.
• Links. Click through the links in your most-used documents, templates, and intranet pages.
• Reports. Review whatever error or skipped-item report your tool produces and deal with each item.

Write down what you checked and the result. That record is useful if a funder or auditor asks later.

Decide who owns it afterward

A well-organized new space decays if no one owns it. Name a person, and a backup, responsible for the structure: who can create new top-level folders or sites, how new staff get access, how departing staff’s files are handled, and when access is reviewed. Put those rules on a single page and save it in the new system. In a small organization this is often a part-time duty, but it needs a name attached.

A practical first step

Open a spreadsheet and list your top-level folders. Next to each, write the owner, the rough size, the last time anyone changed it, and whether it holds sensitive information. Then mark anything with unclear ownership. That one page will show you where the risks are and who to talk to first, and it’s the foundation for every other step on this list.