Explore Gratona by fundraising goal
Reconcile both views before you leave Raiser's Edge NXT.
A Blackbaud exit is not one spreadsheet. Map web view, database view, gift coding, attachments, active payments, and connected products before your organization selects a destination or a cutover date.
Reviewed and updated 2026-08-16
A query result is not a portable operating record
Query permissions, view-specific fields, saved definitions, security filters, split detail, files, processor credentials, and connected workflows determine what the destination can actually reproduce and reconcile.
Choose the transition architecture before the vendor
Staying, staging the transition, and moving to Gratona require different owners, controls, costs, and acceptance evidence.
Path 1
Remediate the current NXT environment
The Blackbaud ecosystem and enterprise fundraising model still fit, and the main problem is governance, training, reporting, configuration, or data quality.
Require this proof
Demonstrate the real fundraising workflows, reconcile both views, assign administration and release ownership, and price the complete operating scope.
Path 2
Stage a dependency-by-dependency transition
The organization needs to replace its fundraising record but cannot safely cut over forms, payments, finance, prospecting, or other Blackbaud dependencies at the same moment.
Require this proof
Define the temporary system of record, integration direction, freeze rules, duplicate prevention, financial reconciliation, recovery path, and retirement sequence.
Path 3
Move the approved operating record to Gratona
The development team wants connected donor, giving, sponsorship, stewardship, task, reporting, and reviewed-work context with a smaller operating surface.
Require this proof
Run representative Blackbaud exports through the agreed Gratona mappings, reconcile relationships and money, and separately prove payments and connected operations before cutover.
Reconcile the surfaces that a flat file hides
Use official exports as evidence, then account for the views, files, credentials, and operations those exports do not carry.
| Surface | Inspect | Acceptance boundary |
|---|---|---|
| Web view | Web-only query fields, online forms, automated recurring gifts, payment transaction IDs, attachments, workflows, lists, and current user permissions. | Blackbaud documents fields and capabilities that differ from database view. Export and reconcile the web-only evidence explicitly. |
| Database view | Saved queries and exports, report parameters, legacy attributes, packages, code tables, constituent and gift structures, and database-view-only operations. | Treat database view as a separate extraction surface even when the two interfaces share underlying information. |
| Gift coding and credit | Funds, campaigns, appeals, packages, split gifts, soft credits, matching gifts, tributes, pledges, recurring commitments, payments, reversals, and write-offs. | A semicolon-separated fund or appeal list can prove association without preserving the amount and credit detail required for reconciliation. |
| Files and retained evidence | Uploaded attachments, linked files, notes, consent records, receipts, acknowledgement evidence, media, exports, and archives retained outside the CRM. | Blackbaud says web-view attachments do not appear in database view. Inventory, download, identify, and reconcile them separately. |
| Payments and forms | Blackbaud Payment Service, Merchant Services, gateway configurations, forms, transaction review, matching, batches, recurring schedules, retries, refunds, and next charge dates. | Historical records and transaction IDs are not portable payment credentials. Confirm the processor-specific continuity path in writing. |
| Connected operations | Financial Edge, email, wealth and prospect tools, portals, websites, Microsoft tools, SKY API applications, middleware, accounting, data warehouses, and local spreadsheets. | Name each authoritative system, owner, credential, reconciliation test, cutover dependency, and retirement decision. |
Make every extraction and acceptance test auditable
Step 1
Map both views and every connected Blackbaud product
Inventory the NXT web view, Raiser's Edge database view, forms, payments, Financial Edge, prospect and wealth tools, email, portals, APIs, middleware, reports, files, spreadsheets, and named owners. Include apparently unused structures until their dependencies are understood.
Acceptance evidence
A signed system map naming the authoritative record, data direction, owner, credential, dependent workflow, retention requirement, and disposition for every surface.
Step 2
Choose the transition architecture before the export
Compare remediation, staged transition, and Gratona against the same fundraising scenarios, operating responsibility, implementation risk, ecosystem needs, staff capacity, specialist sponsorship workflows, and recovery requirements.
Acceptance evidence
A decision record with demonstrated workflows, written scope, assumptions, exclusions, cost boundaries, risks, accountable owners, and approval criteria.
Step 3
Design an export set around record types and reconciliation
Create governed queries and exports for constituents, organizations, households, relationships, actions, gifts, split detail, credits, pledges, recurring commitments, payments, campaigns, funds, appeals, events, participants, attributes, and source identifiers. Preserve the query and field definitions with every file.
Acceptance evidence
A source register with filenames, query definitions, view, requesting user, permission scope, export time, identifiers, date ranges, row counts, checksums, and known omissions.
Step 4
Retrieve attachments and operational evidence separately
Locate uploaded and linked attachments in both views and on each material record type. Preserve the physical files, source record identifiers, names, dates, tags, descriptions, permissions, and external-link decisions rather than assuming a tabular export contains them.
Acceptance evidence
An attachment manifest that reconciles inventory counts to downloaded files and records every unavailable, external, duplicate, restricted, or intentionally excluded item.
Step 5
Reconcile gift coding, active payments, and online intake
Prove fund, campaign, appeal, package, split amount, credit, pledge, recurring schedule, payment, refund, and batch behavior. Separately confirm gateway ownership, stored credentials, next charge dates, retries, forms, matching, receipts, settlements, and donor communication.
Acceptance evidence
Financial control totals plus a continuity register for every active payment series and intake path, with cutover order, tests, exceptions, recovery, and reconciliation owners.
Step 6
Run representative Gratona mappings and dry runs
Test clean and messy constituents, households, organizations, relationships, historical gifts, split coding, soft credits, recurring cases, interactions, documents, and material custom fields. Gratona support varies by import type and remains governed by the written scope.
Acceptance evidence
Reviewed dry-run results with row outcomes, duplicate decisions, mapping changes, unresolved records, record counts, relationship checks, financial totals, and disposition owners.
Step 7
Accept the new record before retiring any source surface
Run the daily development workflows, verify permissions and reports, reconcile records and money, train responsible staff, freeze changes, capture the final delta, and exercise the recovery plan. Retain source access or archives according to approved policy.
Acceptance evidence
A signed acceptance matrix, final-delta reconciliation, cutover runbook, exception queue, recovery criteria, and documented source-retention decision.
Preserve definitions with every export
A CSV cannot explain its view, query criteria, selected fields, security filter, repeated-value behavior, or exclusions. Archive those definitions and the stable source identifiers so the destination can reproduce counts and investigate exceptions.
Keep payment continuity outside the export assumption
Blackbaud documents processor configurations, stored payment information, recurring attempts, retries, and batches as live operational workflows. Treat credentials and future charges separately from historical gift and schedule records.
Verify the current Blackbaud surfaces before setting scope
These Blackbaud sources define the current view, query, file, gift, and payment boundaries used in this guide. Confirm them again when your organization begins planning.
Questions to answer before a Blackbaud exit
Can a nonprofit export data from Raiser's Edge NXT?+
Yes. Blackbaud documents query exports in CSV or XLSX, with export rights controlled by permission. A responsible exit normally requires multiple governed exports, saved definitions, stable record identifiers, files, and supplemental evidence rather than one spreadsheet presented as a complete database copy.
Are Raiser's Edge database view and NXT web view the same?+
Blackbaud says Raiser's Edge is the database view accessed through Citrix and Raiser's Edge NXT is the browser-based web view. They share underlying information, but Blackbaud also documents differences in fields, query behavior, security filtering, and supported features. Reconcile both before setting migration scope.
Will a database-view export contain web-view attachments?+
Do not assume so. Blackbaud explicitly says attachments added in web view do not appear in database view. Inventory uploaded and linked files from every relevant record surface, then preserve a manifest that links each retained artifact to its source record and disposition.
Can active recurring gifts move automatically?+
Historical recurring records and schedules can be mapped when supported by the agreed scope. Active payment credentials, processor configurations, future charges, retries, settlements, refunds, forms, and donor communications require a separate processor-specific continuity plan. Confirm the exact path before promising transfer or timing.
How long does a Raiser's Edge NXT migration take?+
There is no responsible universal timeline. Scope depends on record types, both views, connected Blackbaud products, custom coding, attachments, gift and credit complexity, active payments, integrations, data quality, testing, training, contract dates, and acceptance requirements. Estimate only after representative evidence is reviewed.
What can Gratona import from Raiser's Edge today?+
Gratona has current supported workflows for donor and recipient records, relationships, historical transactions, interactions, and document mappings, with field mapping, dry-run validation, batch progress, and error review that vary by import type. Exact Blackbaud exports, custom transformations, split and credit detail, active-payment continuity, managed support, recovery controls, and timelines are confirmed after representative files are reviewed.
Bring both view inventories and representative exports
Gratona can review the source structure, test the supported mappings, surface exceptions, and define acceptance evidence before your organization approves a Blackbaud exit.