Same vendor. New system. And ten years of reports to rewrite.

Around 2017, we moved from one CRM to another. Here's the part that still gets me: both were from the same vendor. If any migration should have been smooth, it was that one. It wasn't.

The data model underneath had changed. Fields meant different things, records related to each other differently, and the shape we'd organized a decade of work around simply wasn't there on the other side. Ten years of reports, the ones the operation actually ran on, had to be rebuilt more or less from scratch. The work didn't carry over. Worse, the meaning didn't carry over.

I kept coming back to the same thought: there has to be a better way. If even a move within one vendor's own family costs you your reporting history, then something underneath is broken, and it isn't the software. It's that the meaning of the data was welded to one system's model, so the moment the model moved, the meaning didn't survive the trip.

Once I started paying attention, I saw it everywhere. Migrations are where advancement data goes to break. We've all heard the stories, and a lot of us have lived them: the million-dollar migration that reaches go-live with no working reports, or with a user experience so bad the team quietly goes back to spreadsheets.

The price tag is staggering and the failure is always the same shape. The data's meaning was tied to one system's model, and when the model changed, the meaning didn't come with it. Everyone pays for that, over and over, and the smaller the shop, the less it can afford to.

So I started building one. The first version of what's now the Advancement Common Data Model (ACDM™) was barely more than a set of raw SQL tables, a stubborn attempt to write advancement data down in a way that didn't belong to any single CRM. You could map a system to it and back out of it without losing what the data meant.

Over the years, at Rigason, it went through version after version. What shaped it most wasn't theory; it was listening to people in the industry about what they actually needed, and watching the gap between that and what the vendors actually shipped. Every iteration closed a little more of that gap. The raw tables grew into something far more careful and complete, and it matured into the model it is today.

For a long time the plan, to the extent there was one, was that this would be my edge: a better foundation under a better product. Then a question I couldn't shake. Keeping it to myself made one product a little better, but the problem I'd hit wasn't mine. Every shop had it. And the shops that had it worst, the small, understaffed, underfunded ones doing work every bit as worthy, were exactly the ones who'd never get the time or budget to solve it themselves.

A foundation only really works when everyone can stand on it. Locked inside one company's product, even a good one, it just becomes one more thing you can't get out of, which is the very problem it was supposed to fix.

I opened it up. The model became an open, vendor-neutral standard that belongs to no single company, plus the free education to actually use it. It maps to and from the CRMs you already run, so your data stays portable and means the same thing everywhere, and the next migration stops being a rewrite. Rigason funds and stewards the work, but it doesn't control it, and anyone, including the alternatives you might pick instead of us, can build to the same standard.

That last part is the point, not a concession. I want leaving to be easy. If your data is genuinely portable, then you stay because the thing works, not because you're trapped, and that's the only kind of staying worth having. It's also the only honest way to ask a whole sector to trust a foundation: make it something they can walk away from and choose anyway.

It's early, and it's built in the open. Treat what's there as drafts that get better the more people use them and tell me where they're wrong. That's not a disclaimer; it's how a commons is supposed to work.