Adopting ACDM Without Rigason: The Zero-Vendor Blueprint

Here is a common, skeptical question from sophisticated IT leaders: “If the founding sponsor of the Fundraising Commons is Rigason, is adopting the Advancement Common Data Model (ACDM™) just a back-door setup to lock us into their proprietary CRM?”

It is a fair question. The short answer is: no. In fact, the entire standard is designed so that you can adopt it, run it under full load, and build a world-class analytics and AI operation on it without ever using a single Rigason product.

In this guide, we layout the “Zero-Vendor Blueprint”—showing how you can implement ACDM using open-source utilities on top of your existing CRM.

The Architecture: Standard vs. Product

To understand how to adopt ACDM without Rigason, it helps to understand where the standard sits. ACDM is not software; it is a schema definition (specifying tables like constituent, gift_commitment, and gift_transaction) and a set of open metrics calculations (defining how to calculate active donors, retention, and churn).

Because the standard is published under an open license (Apache-2.0 for code, CC-BY-4.0 for content) on GitHub, the core data model belongs to the public domain. Rigason’s software is simply one implementation of this model. You can build your own custom implementation on any system you choose.

The Zero-Vendor Tech Stack

If you want to adopt ACDM today without touching Rigason, your architecture will look like this:

┌───────────────────────────┐
│ Your System of Record     │  (e.g., Salesforce NPSP, Microsoft Dynamics, or Blackbaud RE)
└─────────────┬─────────────┘
              │  1. Extract
              ▼
┌───────────────────────────┐
│ Open ETL Pipeline (dbt)  │  (Maps your CRM's custom objects to neutral ACDM tables)
└─────────────┬─────────────┘
              │  2. Standardize
              ▼
┌───────────────────────────┐
│ SQL Warehouse (DuckDB/PG) │  (Stores your history in the open ACDM schema)
└─────────────┬─────────────┘
              │  3. Analyze
              ▼
┌───────────────────────────┐
│ BI & Analytics (Metabase) │  (Runs reports that everyone trusts)
└───────────────────────────┘

This stack is composed of three neutral layers:

1. The Source CRM (System of Record): You keep your existing CRM (such as Salesforce NPSP, Microsoft Dynamics, or Blackbaud Raiser’s Edge). Your gift processors, gift officers, and annual fund managers continue to use the screens they already know.
2. The Open Translation Pipeline (dbt / SQL): Using open-source ETL/ELT tools like dbt (data build tool) or custom SQL scripts, you query your CRM’s raw tables and map them to the corresponding ACDM schemas. For instance, your Salesforce NPSP Opportunity records are transformed into the standard gift_transaction table.
3. The Local Analytics Warehouse: You load the standardized ACDM tables into a database you control (such as a local PostgreSQL database, a serverless DuckDB file, or an enterprise Snowflake warehouse). Since the data here is defined in neutral terms, you can query it with standard BI tools like Metabase, PowerBI, or Tableau.

Step-by-Step: The Adopting Workflow

Adopting the standard on your own CRM involves three phases:

Phase 1: Define Your Core Entities

Before writing any code, map your current CRM’s data structure to the six core objects of the ACDM standard:

• Constituents: Map your contacts, spouses, and organizations.
• Gift Commitments: Separate your pledges and recurring agreements.
• Gift Transactions: Track the individual payments.
• Campaigns: Line up the appeals.
• Designations: Connect transactions to restricted or unrestricted funds.
• Pipelines: Track major-gift officer portfolios.

Phase 2: Deploy Open-Source Mapping Connectors

You do not have to write these mappings from scratch. The Fundraising Commons hosts open-source translation profiles and pipelines on GitHub (see the Ecosystem Registry):

• For Salesforce NPSP: Use the open-source dbt package to automatically transform Contacts and Opportunities into constituent and gift_transaction views.
• For Microsoft Dynamics: Deploy the Dynamics 365 NCDM-to-ACDM mapping pipeline to convert Microsoft Nonprofit Common Data Model entities into ACDM analytics tables.

Because these pipelines and mappings are pre-packaged, you don’t need a dedicated data engineer or an external agency to write integration code. An advancement services analyst or database administrator can run these templates using standard SQL or command-line tools, keeping your setup simple and your Total Cost of Ownership (TCO) low.

Phase 3: Run the Portability Drill

The final step is to test your independence. Run the portability test: export your data from your local ACDM database and confirm it maps to a standard CSV structure. If you can query your data, run reports, and feed an analytics model using this export, you have successfully decoupled your data logic from your CRM vendor.

Why Do This? The Zero-Vendor Payoff

For an IT Director or CIO, adopting ACDM on your existing infrastructure has three massive benefits:

• Zero License Fees: You do not buy any Rigason software. The standard, the dbt packages, and the SQL schemas are entirely free.
• No System Disruption: You don’t have to retrain your staff or undergo a painful CRM migration. You keep the CRM you have, but escape its analytical limitations.
• Immediate Portability: If you do decide to switch CRMs in the future, your migration cost is cut in half. Your data is already structured in the neutral shape that the next system can import.

Adopting ACDM is about ownership. By mapping your data to an open standard, you ensure that the meaning of your fundraising history is yours—not a proprietary secret locked inside a vendor’s black box.

To see the list of open-source connectors, certified CRMs, and partners supporting the standard, visit the Ecosystem Registry. To read the governance rules that keep the standard neutral, see How an Open Standard Stays Neutral.