By 2018, I could see three forces converging to shape how nonprofits approached data. First, cloud infrastructure had become simpler and cheaper, opening doors for organizations that once found these tools out of reach. Second, as more systems came online, the urgency for a shared language for data became a strategic priority. And third, the sector was moving away from dependence on a single vendor toward an ecosystem approach combining platforms, partners, and integrated tools that had to work together. 

I'd seen the problem up close. At roundCorner, we partnered with hundreds of nonprofit organizations to consolidate their disparate systems into a single Constituent Relationship Management platform (CRM). Implementations were expensive, nuanced, and often hinged on the knowledge of a few key people. By every measure, we successfully consolidated and connected the systems. But getting people to work with those systems remained a major challenge because each team - fundraising, grants, programs, finance – understood the meaning of the data through their own lenses. Put simply, consolidation wasn't enough to achieve the intended outcome.  

We needed a better way to go beyond connecting the data so people across teams could share the meaning of their work through data. The central question became: How do we preserve meaning as data moves?  

Across the sector, many of us were asking some versions of that question. One of the brightest points of progress was the NGO Reference Model – developed as part of a larger movement to introduce Enterprise Architecture into the NGO sector. It brought the sector together to define, for itself, a common understanding of how nonprofits operate from context to impact. 

"Having a common understanding of how NGOs operate is critical when NGOs have internal discussions, collaborate with peers, and conduct business with suppliers and supporters. The NGO reference model provides this high-level, consistent business process language abstracted from the specifics of the International Development, Humanitarian Response, and Conservation sectors."  

But it stopped at an important boundary: it described how nonprofits operate, not how data moved through and supported those operations. This limitation became more consequential as computing moved to the cloud, more data came online, and software rapidly shifted from purpose-built applications to interoperable platforms. 

Out of this sector-wide conversation, the Common Data Model for Nonprofits began to take shape. 

what a common data model means

"Common data model" sounds more technical than it is. 

Every system that holds nonprofit data decides for itself what data means: what counts as a program, whether a donor and a participant are the same kind of record, how a grant links to its outcomes, etc. When data moves between systems, someone must translate, and meaning gets lost along the way. 

The Common Data Model for Nonprofits is a shared design for those decisions. It describes the core beings and things nonprofits work with, such as programs, people, participants, transactions, and outcomes, and how they relate. It isn't software; nobody installs, buys, or logs into it. When systems are built from the same design, they share a language. 

There was tension in that, and we felt it from the start: a common language can easily flatten differences and result in parties claiming, "my common language is better," or "I had a common language first." That was never our aim. So, we committed to designing the CDM so organizations could keep their own words and ways of working while preserving meaning as data moved between platforms. 

If we got it right, it would reduce implementation and integration costs, lessen reliance on the one person who knows how everything fits together, and give organizations the agency to change systems without starting from scratch. 

why Microsoft showed up 

The way I see it, the people at Microsoft at the time learned from the challenges other cloud platforms faced and chose a different path: they built the infrastructure in-house rather than expanding through acquisition, and they grounded that infrastructure in an extensible, industry-agnostic common data model. This left room for the ecosystem to own its reality.    

The nonprofit ecosystem had both the expertise and the urgency but lacked the seed capital. Microsoft stepped in to fund the work and leverage its scale to bring nonprofits and partners together. Microsoft started with an invitation, not a mandate. Two steering teams formed, one for customers and one for partners.  

The design centered on one question: how do we preserve meaning as data moves through nonprofit operations? What followed was a series of deliberate choices, shaped by people from the sector, driven by a shared commitment to answering this question. 

a choice to start with mission 

At the time, most of the nonprofit technology ecosystem revolved around fundraising and donors. The tools and data were more mature, and investments were following the money. We learned from the NGO reference model and decided to put programs first and fundraising last.  

Funding matters, but it exists to serve the work of programs. By starting with programs, we began with the change an organization exists to create. We chose to start with mission, not money. 

a choice to keep it open and within reach 

One question that surfaced repeatedly during the work was: Who can use this? Contributing steering team members brought their perspective from years working in places where information supports decisions made under urgent, difficult conditions. They understood that good ideas only matter if they reach the people who need them, when they need them. 

One member said: “A model written down on paper is like having a vaccine that doesn't get distributed. You're not protecting anybody.” If this work was going to matter, people needed a way to find it, understand it, use it, and contribute to it. It had to be available to organizations beyond those with the largest technology budgets.  

 Keeping the work free and accessible reflected a core belief: if preserving meaning mattered to the sector, then the benefits should be available to all of the sector. So, Microsoft and the contributors published the model open source and made it free.  

a choice to allow more than one way to be right 

The CDM was never meant to be prescriptive; it's a suggestion. Common doesn't mean uniform. A humanitarian organization isn't the same as a food bank, and a local nonprofit isn't the same as a global NGO. How program team members operate in the field isn't the same as how headquarters aggregates outcomes.  

The goal was to create enough shared structure for meaning to travel, not to force one structure on everyone. And because the CDM is a design, builders retain the agency to adapt it as needed for their contextualized use.  

a choice to build with the community 

Version 1.0 went public in a Microsoft keynote at the 2018 NetHope Global Summit in Dublin, the same event where our company, threshold, was introduced. Microsoft announced that the model was available online, invited people to contribute, and stressed that applications could be built on Microsoft or other platforms.  

No single organization could have created the Common Data Model for Nonprofits. Even competing platforms were invited to contribute, because a common language only works if everyone can understand it. The shift was from ego-driven to ecosystem-driven. 

Microsoft described it for what it was: a community-driven contribution, stewarded by and invested in, but not owned by Microsoft. And today in 2026, they can stand by that promise. 

The result belonged to none of us alone and depended on all of us together. 

a choice to build it like it matters 

What launched in Dublin in October 2018 was not another nonprofit software application. The sector already had plenty of those. It was infrastructure: shared, open, and free to be bent into shape by whoever needed it. And it carried the values that shaped its creation: community participation, openness, accessibility, flexibility, and a commitment to put mission before money. 

For the first time in the cloud era, the sector built what it needed most: its own shared data language. 

In 2026, the question is no longer whether we can create common meaning for nonprofit data. It's what becomes possible now that we have it. 

-Dan