Split the migration into three acceptance questions
First, can the destination represent the required contact information? Second, can it preserve the relevant historical gift records and their meaning? Third, what happens to each ongoing recurring instruction? A single “data moved” statement answers none of those questions precisely. Treat payment credentials as a provider-controlled matter, not an export for staff to manipulate. Do not collect them in this publication, in email attachments or in the anonymous planning tools.
Make the providers define the transfer boundary
Ask the current and destination providers which instruction types, processors, countries and statuses are supported; who performs each step; what requires donor action; and how exceptions are handled. 4aGoodCause documents Stripe and Authorize.net connections, but a supported processor name does not prove that a particular existing arrangement is transferable. Marketing portability claims are not a case-specific migration acceptance plan. Obtain the applicable schedule, responsibilities and confirmation evidence before announcing a cutover.
Agree what happens during the overlap
Use a dated plan for the last old-system activity, first intended new-system activity, read-only reference access and unresolved cases. The responsible providers must establish how they prevent duplicate or missed instructions for the actual setup. Do not improvise a live cancellation/recreation procedure from this guide. Preserve exports and reports according to the nonprofit’s policies, and retain a route for donor questions. An overlap window is a responsibility map, not permission to run duplicate charges.
A fictional partial migration
The destination accepts the contact and historical-gift files, but a subset of recurring instructions remains under provider review. The honest status is “records imported; ongoing-gift transfer partially unresolved,” not “all donors migrated.” Assign the exception list to a named internal role, record the next provider action and delay unsupported promises. Import review covers the record checks; platform fit helps determine whether the benefit of changing software justifies this work in the first place.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- 4aGoodCause contact import — Merchant documentation · help.4agoodcause.com · Merchant-controlled · checked 2026-09-30
- 4aGoodCause donation-history import — Merchant documentation · help.4agoodcause.com · Merchant-controlled · checked 2026-09-30
- 4aGoodCause payment-provider guidance — Merchant documentation · help.4agoodcause.com · Merchant-controlled · checked 2026-09-30