Meet Port — The Planning Center Import Tool Built for Churches

Port did not start as a product. It started as the internal tooling a consulting team built because it was doing the same painful work over and over.

Threefold Solutions runs Planning Center migrations for churches. Early on, that meant spreadsheets, careful manual reconciliation, and long evenings — the same fund-matching problem, the same duplicate-donor problem, the same pledge-progress problem, on every single engagement.

So the recurring parts got automated. Then the automation got an interface, because handing a script to a church administrator is not a solution. Then churches started asking whether they could just use the thing directly.

That thing is Port.

Why an import tool needs to exist at all

Planning Center is genuinely good software, and this is not a criticism of it. But there is a specific gap between what a church has and what Planning Center will accept.

Planning Center imports people from a CSV, and it has added a donation import for giving history. Both work. What neither covers is everything else a church accumulates over a decade or two:

• Group memberships — the rosters, teams, and leader assignments that describe how your church is actually organised
• Pastoral notes — the record of who visited whom, which family went through what
• Pledges — the commitments behind every campaign you have run

None of those have a native import path. And even within giving, Planning Center’s own documentation is explicit that in-kind donations cannot be imported, refunds and negative amounts cannot be imported, and every fund must already exist before you start.

The gap is not that Planning Center is missing a button. It is that migrations are relational — records point at other records — and a CSV loader is a poor fit for relational data.

Built for church staff, not IT departments

The single most important design decision in Port is who it assumes is using it.

The person running a church migration is usually a pastor, an administrator, a bookkeeper, or a capable volunteer. They are not database administrators, they are doing this alongside their actual job, and they will do it exactly once. Tooling built for engineers fails these people — not because they lack ability, but because it assumes a vocabulary and a tolerance for cryptic failure that nobody should need for a one-time task.

So Port explains what each step is for. Validation runs before anything is written to Planning Center, and errors are described in plain language rather than returned as codes. Export checklists tell you what to pull from your old system. Nothing requires you to shape a CSV to a schema by hand.

What Port actually moves

Four data types, each unlimited on its plan:

• Giving history — years of donations with donors, funds, dates, and payment types intact, including the in-kind and check records the native import rejects
• Group memberships — rosters with member and leader assignments, imported as relationships so people in several groups arrive in all of them
• Pastoral notes — attached to the right person, with original dates preserved
• Pledges — active and historical commitments, so campaign reporting survives the move

It reads exports from 21 source systems directly — ACS, Breeze, CCB, FellowshipOne, MinistryPlatform, Pushpay, Realm, RockRMS, ShelbyNext, Subsplash, Tithely, Touchpoint and more — with Open Import for anything else that produces a CSV.

The features that came from real failures

Three worth naming, because each one traces to a specific problem:

Magic Map matches your old fund names against your Planning Center funds and proposes the mapping. Planning Center requires every donation to land on a fund that already exists; reconciling those two lists by hand is where a giving migration loses a week.

Bulk Create adds the funds that turned out to be missing, without stopping the migration to go and create them one at a time.

Two-way sync keeps Port aligned with Planning Center throughout the import rather than working from a snapshot — which is where duplicate records come from when someone else on your team is still working in the account.

Pricing that doesn’t punish having history

Port charges a flat price per data type, unlimited records, with 180 days of access. A church moving 65,000 donations pays the same as one moving 500.

This is deliberate. Per-record and volume-tiered pricing creates a bad incentive: it makes churches move less of their history than they should, and the churches with the most history to lose are the ones who pay most to keep it. See pricing for the numbers, or the import tool comparison for how that model differs from the alternatives.

Not experimental software

Port is the same tool Threefold Solutions uses on paid client migrations. It was field-tested on real church data, under real deadlines, by people who had to answer for the results — before it was ever offered to anyone else.

That is the whole pitch, really. Every feature in it exists because a migration went sideways without it.

If you are planning a move, the step-by-step guide walks through the full sequence, and the migration FAQ covers what churches ask first. Or just talk to us — if the honest answer is that Planning Center’s own import will do what you need, we will tell you that.