What actually moves, and what does not
Planning Center will import people from a CSV file on its own, and it does that part well. Names, contact details, addresses, birthdays, custom fields, membership status — all of it goes in through the People importer, and Planning Center's own documentation is worth reading in full before you start.
Four things have no native import path at all. If nobody plans for them, they stay in the system you are leaving:
- Giving history. Donor records, contribution history, fund assignments and payment methods. This is the one churches assume will come across and the one that most often does not. It comes out of your old system transaction by transaction, not as a donor summary.
- Pledges. Active and historical commitments, matched back to the right donor, campaign and fund.
- Group memberships. Small groups, ministry teams and volunteer rosters, with member and leader assignments preserved. Depending on how clean the source data is, a fresh setup is sometimes the better call.
- Pastoral notes. Years of care records and follow-up history, moving with the profile rather than staying behind in a system nobody can log into any more.
This is the gap Port exists to fill — we built it for our own migrations because there was no other way to move giving history at scale, and it is now available to churches directly. If you are migrating yourself and your giving history matters to you, this is the part to solve first, not last.
And a third tier, which nothing moves
Below the data that needs a tool is the data that simply does not come across. Exactly which of these you lose depends on the system you are leaving, but the shape is consistent:
- Attendance history. Moving it is manual work, every time. Decide early whether you need years of it or whether a clean start plus an archived export is enough.
- Photos, documents and attachments. Bulky, slow, and rarely worth the transfer. Cloud storage — OneDrive, Google Drive — is usually the better home, with the link on the profile.
- Communication history. Sent emails and texts generally stay in the system that sent them.
- Registrations data. Past event registrations do not carry over unless someone stored them on the profile as a custom field.
- Church metrics and counts. Rolled-up numbers — weekly counts, historical trend data — are reports, not records. Export them before you lose access.
None of that is a reason not to migrate. It is a reason to decide, deliberately and in advance, what you are keeping — because the decision gets made for you the day your old contract ends.
The one field that decides whether it works
If you take one thing from this page, take this. Planning Center has a special field for the import process called the Remote ID — a unique identifier for each person, carried over from the system you are leaving. In your current export it is probably called Individual ID, Person ID, or just ID.
The Remote ID is what lets Planning Center recognise that the row in your giving export and the row in your profile export are the same human being. Without it, Planning Center's matching algorithm has to guess — and when it is unsure, it defaults to creating a new profile rather than updating an existing one. That is how a migration ends with hundreds of duplicates for people who were already in the system.
Know this one thing before migrating to Planning Center goes through this in full, including what to check in your export before you rely on it.
What your system calls it
Every system names this field differently, and finding it is the first practical step of any migration. This is what each one calls the person identifier in its giving export:
The exception is worth calling out. Realm's giving export has no reliable person identifier — it requires name, email and phone, and treats the person ID as optional. If you are coming off Realm, matching falls back to exactly the fuzzy comparison that produces duplicate profiles, and that has to be solved before you import rather than after. Church Windows is a milder version of the same problem: no Remote ID as such, but its Giver # can be used as an internal reference for deduplication.
The table above is read off Port's own giving parsers rather than compiled by hand: a parser exists for a system because a real church's export has already been through it. Column-by-column requirements for each of these live in Port's provider documentation.
Import in layers, not in one go
You will not get one tidy file. Almost every church management system needs several separate exports to get everything out — profiles here, giving there, custom fields somewhere else again — and how many depends entirely on which system you are leaving.
Most churches respond by trying to force those exports into one enormous CSV, and most churches fail at it. The files rarely line up, and the spreadsheet work to make them line up is exactly where the errors get introduced.
With the Remote ID in place you do not have to. Planning Center will stack imports: bring in the basics first, then run a second import for custom attributes, then a third for membership status or campus. Each file needs only the Remote ID, first name and last name to tie back to the right person, and each one merges into the existing profile rather than creating a new one. Several exports stops being a problem and becomes the plan.
What to do before you export anything
A migration is the one moment when cleaning your database is cheap, because you are touching every record anyway. Once the data is in Planning Center, the same cleanup is a project nobody schedules.
- Confirm your current system exports a person ID, and that it appears in every export you plan to use — not just the profile one.
- Decide who is not coming. Records for people who left a decade ago cost nothing to drop now and clutter every list you build later.
- Merge the duplicates you already have, rather than migrating them.
- Tell your staff and volunteers the timeline before it starts, not during. The technical work is rarely what derails a migration.
How to know the migration actually worked
Test on a small slice first — twenty or thirty people, including the awkward ones: the household with two last names, the person with no email, the family that gives under one name and checks in under another. Look at what Planning Center made of them before you import 4,000 more.
After the full import, reconcile against the source rather than eyeballing the result. Count profiles. Total the giving by fund and match it to the year-end figures from your old system. Pick five people and walk their whole record. A migration that looks right on the dashboard can still have quietly dropped a fund.
What going wrong actually looks like
We know the failure mode because we caused it. Before Threefold existed, our own church moved to Planning Center, and we did what every first-timer does: reviewed the exports, cleaned the data, loaded one big CSV, mapped the fields and hit go.
What came back was a flood of duplicates and missing and incorrect data — thousands of changes to the database with no obvious way to undo them. Then the import stalled and People ground to a halt. We had not just imported bad profiles; we had taken down part of Planning Center, and their team had to back us out of it. They have since changed their systems so it cannot happen that way again.
Everything on this page comes out of that afternoon. It is also why the advice above is so insistent about testing on a slice first: the failure is not loud while it is happening. The progress bar looks completely normal right up until it isn't.
The other thing worth hearing early: new software is an accelerant, not a cure. If a process is broken now, Planning Center will run it faster and more visibly. A migration is the best opportunity you will get to fix the process first — get the people closest to the current system in a room, list what actually frustrates them, and sort the platform problems from the process problems before you move anything.
How long a migration takes
Two clocks, not one, and conflating them is how projects slip:
- Getting your data in is our job, and it is bounded. Under 30 days, guaranteed — profiles, giving history, groups and check-in data, cleaned and correct. If it runs long we keep working for free until it is done. Your team stays in your current system right up to the switch, so there is no window where nobody can look anything up.
- Getting your church onto it is your job, and it is not bounded. Up to six months, in our experience, before Planning Center is genuinely embedded in how a church operates. Nobody can guarantee this one, because it does not depend on us.
The second clock is the real answer to "how long does this take", and it is the one that gets left out of the plan. Moving the data is a technical problem with a known solution and a date on it. Changing the habits of a staff team — getting everyone working the same system the same way, and getting them to stop maintaining the shadow spreadsheet they trust more — is the part that takes the longest, every time.
Plan for it the way you would plan the import: name who is responsible for each app, write down the handful of procedures your team runs every week, and expect to be supporting people for a season after go-live rather than a weekend.
Guides for your current system
Every church management system exports differently, and the useful detail — which fields it gives you, what it silently leaves out, where its giving export breaks — is specific to the one you are on.
