Most membership organisations do not have a system problem. They have an architecture problem. The membership system works. The finance system works. The communication tool and the event platform work. Yet the organisation spends more and more time moving data between them.
Most Norwegian membership organisations run on a dedicated membership system such as Winorg, Lime CRM or EG Membercare, or on a general CRM like SuperOffice, and the systems do the job they were built for. So when the organisation grows, the question is not necessarily which membership system to buy next. The question is which digital foundation the organisation needs.
The short version of our answer: if the current solution supports the organisation's processes well, switching is a cost without a payoff. But as needs grow, the organisation must assess whether today's solution is still the best foundation for everything around the membership: finance, relationships, self-service, insight and automation. The answer may be a larger membership platform, a CRM platform or a combination, and sometimes the answer is to keep what you have. This article gives you a sober way to make that assessment.
What is the difference between a membership system and a CRM platform?
Short answer: a dedicated membership system is built with member administration as its primary domain, and modern solutions often also cover self-service, events, communication and integrations. A CRM platform such as Dynamics 365 with Power Platform is a broader technological foundation where the organisation models its own relationships, processes and data. The difference is not simple versus advanced, but finished domain solution versus flexible foundation.
Neither category is wrong, and modern membership systems are not simple registers. Winorg describes itself today as an organisation platform covering membership, donors, volunteers, events, communication and ready-made integrations. Lime CRM offers a dedicated membership setup with invoicing, courses, self-service and automation, and EG Membercare covers dues, events, communication and reporting. What they share is that the domain is delivered as a finished product, with configuration options within the vendor's domain and data model.
A platform starts from the opposite end. The Dynamics 365 applications are built on Dataverse, Microsoft's shared data service, where the member model is designed around how your organisation actually works: membership types, dues structures, local branches, roles, courses, events and consents. Dataverse can serve as a shared operational data foundation, while Power Platform, Power BI and Microsoft Fabric are used for applications, automation and analytics respectively. Be sober about one thing, though: integrations to finance and other line-of-business systems still have to be designed and implemented. The platform does not give you the integration; it gives you the foundation to build it on. The trade-off is real: more to decide up front, more responsibility, and more capability over time.
This is also why we deliberately use a broader term than CRM. A CRM platform can be part of the answer, but for many larger membership organisations the real question is which operational data foundation should tie together membership, finance, relationships, self-service and insight. How such a foundation carries analytics across the organisation is something we cover in our article on Microsoft Fabric and Dynamics 365.
Weighing your options beyond the membership system? A short mapping conversation gives you a concrete picture of the right architecture for your organisation, with no obligation. It also covers when the answer is to keep what you have.
Six signs the organisation has outgrown its membership system
You have probably not outgrown the membership system because it is old. You outgrow it when the organisation has become more complex than the system's model. The signal is rarely that the system itself fails; it is that the work around it grows. These six patterns come up again and again in conversations with Norwegian membership organisations.
As a rule of thumb: if you recognise three or more of the points below, it is worth assessing the whole system architecture, not just the next upgrade.
1. The integrations no longer meet the need
Modern membership systems often ship with ready-made integrations to banking, finance systems and communication tools. The criterion is therefore not whether integrations exist, but whether they work well enough for your needs. When dues live in the membership system and the ledger in the ERP, and someone still has to export, match and correct between them every month, the integration is not working well enough. We have written separately about why the membership ledger does not belong in the ERP alone.
2. No clear architecture for where data is owned, and which source is authoritative
An organisation can have several systems because it actually needs several specialised systems. The problem arises when there is no clear architecture for where data is owned, how it is synchronised and which source is authoritative. When the membership system has one address, the newsletter tool another and the event platform a third, and a board report yields three different member counts, it is the architecture that is missing, not a better single system.
3. The self-service you want requires custom development or manual detours
Winorg, Lime and EG all offer self-service functionality, so the question is not whether self-service exists. The question is whether the self-service you actually want can be delivered within the current solution without disproportionate custom development or manual processes. If every new self-service flow becomes a development project at the vendor, or an email to the administration, the architecture should be reassessed. We compare the realistic portal options for member scale in a separate decision article.
4. Reporting requires manual assembly from several sources
The membership systems have reports, and several have insight modules. When board reporting still takes days, the problem is usually the data foundation and the architecture, not the reporting function: the numbers have to be pulled from several sources and assembled by hand. The shift from counting members to understanding them is what we describe in our piece on going from member register to member insight.
5. New needs are being squeezed into a model the solution was not built for
In our experience this is the most important sign. Courses tracked in a notes field, political contacts in a spreadsheet, donor flows in a separate tool. When the organisation's actual work no longer fits the solution's domain model, each workaround adds quiet cost and risk, and no amount of configuration changes the model's boundaries.
6. The organisation has more relationships than the membership
One and the same person can be a member, an elected representative, a course participant, a donor, a political contact and a company representative, often at the same time. A membership system can usually store such data. But when the organisation needs to model these relationships and processes as an integrated part of how it works, across membership, finance and advocacy, this is where a broader data foundation has its clearest advantage.
"Organisations rarely switch because the member register is bad. They switch because everything around the register, finance, insight and self-service, has started costing more than the system itself."
Cartagena, based on CRM and Dynamics 365 projects for membership and interest organisations
Membership system and CRM platform: a sober comparison
The comparison below is deliberately even-handed. The columns do not describe simple versus advanced, but a finished domain solution versus a flexible foundation. A dedicated system usually wins on time to value; the platform gives more freedom, and a larger stewardship responsibility. Neither column is the right answer for everyone.
| Need | Dedicated membership system (e.g. Winorg, Lime, EG) | CRM/data platform (Dynamics 365 + Power Platform) |
|---|---|---|
| Member administration | Finished domain functionality | Must be modelled and built |
| Dues | Often built in | Must be modelled and integrated |
| Self-service | Standardised, with configuration options | Can be built more freely around your own processes |
| Events and communication | Often built-in modules | Built or integrated as needed |
| Analytics and insight | Standardised analytics and reporting within the solution | Can gather data from several business domains on the same foundation |
| Integrations | Ready-made connectors and APIs, depending on the vendor | Integration is a central part of the platform architecture |
| New processes | Within the solution's domain and extension model | More freedom to model your own processes |
| AI and automation | Depends on the product's functionality and roadmap | Can be built and orchestrated across processes and the data model |
| Time to value | Usually shorter | Usually longer |
| Stewardship | More of the platform responsibility sits with the vendor | Larger responsibility for your own model, integrations and governance |
Two rows deserve emphasis. New processes is where the platform difference is largest for interest organisations: relationships and processes beyond the membership itself, such as political advocacy work, can be modelled as an integrated part of how the organisation works, an approach we describe in our article on the Political Compass. And stewardship is the honest counterweight: on a platform, the organisation takes on a larger responsibility for its own model, integrations and governance. That responsibility has to be staffed and priced in.
When is the answer to keep the membership system?
Short answer: keep it when member administration is the whole need, integrations are few, and the organisation does not have the capacity to own a platform. A well-run membership system beats a half-finished platform every time.
This deserves honesty, because the platform story can sound like the answer to everything. It is not. A platform must be governed: someone has to own the data model, the integrations and the roadmap. For a small organisation with a straightforward member operation and a tight budget, that ownership cost can outweigh the gains. The general warning signs of having outgrown a system, which we cover in a separate article, apply here too, but in both directions: switching too early is as real a mistake as switching too late.
A rule of thumb from our projects: count the workarounds, not the birthdays. A ten-year-old system with two workarounds is healthier than a three-year-old system with ten.
It is also worth saying explicitly: an organisation does not outgrow its solution because the solution is old, limited or poor. It outgrows the solution when the way member data, relationships and processes connect no longer supports how the organisation actually works. The answer can then be a larger membership platform, a CRM platform, or a combination of systems with a clear architecture between them.
And if the answer is that the organisation has outgrown its current solution, that does not mean building everything from scratch. Cartagena Medlem combines finished processes for membership organisations with the foundation of Dynamics 365 and Power Platform. That gives a path from today's member operation to a broader digital foundation, step by step, where it makes sense.
A move without rip-and-replace
If the assessment lands on a foundation need, the next mistake to avoid is treating the move as one big switch. The pattern we recommend, and use, is staged coexistence: the membership system keeps doing its job while the foundation is built and validated beside it. The principle is simple, and it is how we work: not rip-and-replace. Build on what works, where it makes sense.
- Map: document which member flows, integrations and reports are actually in use, and which workarounds exist. This is where the business case gets real numbers.
- Model: design the member data model in Dataverse around your membership types, branches and dues structures, and plan the finance integration early.
- Coexist: run the platform beside the membership system for a period. Insight, self-service or events can go live on the platform first, while dues stay where they are.
- Move the core: when the new model is validated with real data, move dues and administration deliberately, with proper change management and training.
- Overview: membership systems for Norwegian organisations
What does it cost? The honest answer is that it varies more with integrations and data quality than with member count, and service cost normally exceeds licence cost. We break down the drivers in our article on Dynamics 365 implementation cost. Organisations coming off Microsoft's own nonprofit module face a variant of the same decision: Fundraising & Engagement is being retired, and support ends 31 December 2026. We cover that in a separate article.
Pattern: A situation we often see in unions and interest organisations with 20,000 to 50,000 members: the membership system handles dues well, but member insight lives in exported spreadsheets, and every autumn the administration spends weeks reconciling member lists against the ledger. When member data moves onto a platform with finance integration, the reconciliation becomes continuous instead of annual, and the board report becomes a dashboard. The membership system was never the problem; the walls around it were.
Frequently asked questions about membership systems and CRM platforms
What is the difference between a membership system and a CRM platform?
A dedicated membership system is built with member administration as its primary domain: register, dues, enrolments and withdrawals, and often also self-service, events and communication. A CRM platform such as Dynamics 365 with Power Platform is a broader technological foundation where the organisation models its own relationships, processes and data. The difference is finished domain solution versus flexible foundation, not simple versus advanced.
When should an organisation move from a membership system to a CRM platform?
A good sign is that the cost is moving out of the system: the administration spends more and more time on exports, reconciliations and manual lists because the integrations and the data model no longer meet the need. Based on projects we have taken part in, it typically happens when the organisation has more revenue streams than dues, more relationships than the membership, or needs for insight and processes that do not fit the solution's domain model.
Can Dynamics 365 handle dues and union deductions?
Yes, but it is not standard functionality. Dues runs and member finances can be modelled in Dataverse and integrated with finance and payment systems. For complex schemes, such as union payroll deductions, the process, the integration and the division of responsibility between the systems must be designed specifically. The gain is that member finances sit on the same data foundation as the rest of the member data, so reconciliation can become continuous rather than a manual exercise.
What does it cost to move from a membership system to Dynamics 365?
It depends on data quality, the number of integrations, the scope of processes and how much is moved in the first phase. In projects we have taken part in, focused transitions for mid-sized membership organisations have typically stretched over several months, and service cost normally exceeds licence cost. A mapping exercise first gives a real estimate before you commit.
Do we have to switch everything at once?
No, and you should not. The usual pattern is coexistence: the membership system remains the source of truth for dues for a period, while member insight, self-service or events are built on the platform first. The core moves once the new model is validated. A switch that requires everything to work from day one is an unnecessarily risky switch.
What happens to the member history in a switch?
It comes along. Memberships, payment history, roles, courses and consents are often among the most valuable things the organisation owns, and the history is the basis for insight and attrition work. In a transition to Dataverse the history is modelled in, not just today's member list. Plan data cleansing as part of the move; a switch is the best occasion to tidy up.
Unsure whether you have outgrown the membership system?
We do not primarily sell a new system. We help the organisation find the right system architecture. We map member data, integrations and workarounds, and give a concrete recommendation, including when the answer is to keep what you have. A mapping like this typically takes a few weeks, not months, and gives the board a decision basis with real numbers.
Sources
- Microsoft Learn: What is Microsoft Dataverse?
- Microsoft Learn: Power Platform licensing FAQs
- Microsoft Azure: Pricing for Azure Static Web Apps
- Microsoft Learn: Use the Microsoft Dataverse Web API
Sources retrieved and checked 30 August 2026.