What does it cost to change membership system? Cost picture, timeline and five-year total cost

A worked example: what five years can look like

The question behind the question is usually whether we are talking about a few hundred thousand or several million. Here is one example calculated all the way through. It is an illustration built on the assumptions below, not an offer and not an average. Your own number depends on data quality, the number of integrations, what has to be served from the outside, and how much you choose to rebuild.

Assumptions. A federation with 18 000 members and 25 internal users. Four integrations: finance, payment provider, website and email tool. Dues with payroll deduction, where deduction files from employers are imported and reconciled. A self-service portal where members update their own details and elected officers follow up their members. Twelve of twenty years of history migrated. User licences are nine Dynamics 365 Sales Professional at 65 dollars and sixteen Dynamics 365 Team Member at 8 dollars per user per month, which gives read access and simple updates. These are Microsoft list prices with annual billing, retrieved 18 September 2026 and converted at the Norges Bank rate of 9.43, rounded to the nearest ten thousand. The communication tool may be Microsoft's own or a third party, and the amount varies a good deal with the choice. Internal hours costed at 750 000 kroner per full-time equivalent. All amounts exclude VAT. The model uses unchanged prices in all five years; any price indexation comes on top. The cost of running the existing system during the transition is not included. The licence mix depends on solution design and Microsoft's usage terms; here it is assumed to sit within what Sales Professional and the Team Member app allow, and Microsoft's Norwegian price list may differ from a plain currency conversion. The service items are experience-based planning assumptions, not prices.

Over five years that totals 5 710 000 kroner. Roughly, a third is one-off services, a quarter is recurring subscriptions (user licences, communication tool, portal hosting and capacity), a fifth is stewardship and a fifth is your own hours. Only the subscriptions have a public price list. Compare those alone and you are comparing the part with a price list, and not the part that separates two federations of the same size.

What moves the total most is not the licences. It is data quality, the number of integrations, how many employers deliver deduction files and in which formats, whether members and elected officers are to serve themselves in a portal, and whether the communication tool sits inside or outside the Microsoft portfolio. Two federations with the same membership can land far apart without anyone having done anything wrong. That is also why a ratio between service cost and licence cost is of little use: the denominator is a choice each organisation makes for itself.

Read the example as a shape, not as a price. An organisation with clean data, two integrations and no portal will normally land lower. One with two parallel member registers, many employers on payroll deduction or extensive customisation lands above.

What does the cost of changing membership system consist of?

Eight items make up almost every membership system change in a federation. Only one of them has a public price list, which is why it dominates the conversation. The seven others are the ones that decide whether two organisations of the same size end up with very different projects.

Two organisations with identical user numbers can end up with very different projects, and the difference sits in data, integrations and how much has to be served from the outside: deduction files from employers and a portal for members and elected officers. It is the same cost logic we go through in the article on what a Dynamics 365 implementation actually costs, applied to a narrower project.

Dues are the item that surprises most. Membership dues are not one process but several: calculation rules, categories and exemptions, invoicing, payroll deduction, reminders, reconciliation against the ledger. We have written about the architecture of this in the article on dues and payroll deduction. In a system change, dues is normally the process that needs the most testing, because it is the one where an error is visible to every member at the same time.

Two related articles sit alongside this one. When has the membership organisation outgrown its membership system? deals with need, and ready-made membership solution or your own platform? deals with architecture. How we run the change itself is described on our page for Dynamics 365 for membership organisations.

How long does it take to change membership system?

The phases overlap in practice, but the sequence holds. The durations below are planning assumptions from comparable Dataverse projects in the Norwegian market, not a guarantee.

A membership organisation has fixed windows in the year where a change should not happen. The dues run, the annual meeting, the enrolment season and, for fundraising organisations, the giving season. In practice that leaves two realistic go-live windows per year for most organisations. Working backwards from those windows is often what actually determines whether a project takes eight months or twelve.

The five-year picture: what the total cost actually contains

A usable model has two columns. One-off costs fall in year one. Recurring costs fall every year, including year one.

It is on the recurring side that comparisons usually break down. Subscription or licence is the visible part. Underneath sit stewardship and further development, storage and capacity, integration maintenance and training of new staff. On Dataverse, capacity is entitlement-based across database, file and log storage, so decades of history and documents carry a recurring cost. Then add the price indexation clause: multi-year agreements normally carry annual indexation, and a lower starting price with steeper indexation can be the more expensive of two already in year four. Ask to see the clause before you compare first-year prices.

Stewardship is a real cost in both models

A common mistake in these business cases is to count stewardship as a cost in one model and as free in the other. It is neither.

In a ready-made domain solution stewardship sits inside the subscription. The supplier upgrades, maintains and develops the solution, and you follow their roadmap. That is a genuine advantage: you buy predictability and you do not need to hold the competence yourself. The trade-off is that the roadmap is theirs, and priorities can shift when ownership changes.

On a flexible foundation stewardship is yours, either internally or through a partner. You set the roadmap, and you pay for it. That is also a genuine advantage, and a genuine cost, and it carries its own dependency: on a partner relationship and on the people who know your setup. We go through the architectural differences in the comparison of ready-made solution and own platform.

For the cost model the point is simpler: put stewardship on both sides of the sheet, at a realistic level, and the comparison becomes honest. Based on projects we have taken part in, recurring stewardship for a membership solution often lands somewhere between 15 and 25 percent of the one-off services in year one, per year, depending on how much you keep developing after go-live. The range covers stewardship you buy or staff separately. Where stewardship already sits inside the subscription, it should not be counted twice. That is the number most often set to zero in a business case, on both sides.

Why the change costs more than budgeted

In membership projects, five patterns account for most of the distance between estimate and reality. None of them are technical.

• The bring-everything migration. Twenty years of history moved because nobody dared decide what could be archived. Migration effort scales with volume and with the number of exceptions in the old data.
• Integrations counted as one. "We have an integration to the finance system" often turns out to be a nightly file transfer, a manual reconciliation and a spreadsheet somebody maintains. Count connections, not systems.
• Reports without an owner. A report list almost always turns out to hold far more reports than it has readers. Mapping which ones have an actual recipient shrinks the project, and the mapping itself takes a day.
• Your own time, unbudgeted. Subject experts, finance and member services must be available through design, testing and the first dues run. If those hours are not planned for, they are taken from ordinary operations, and the project slips.
• Training cut last in the project and first in the budget. A membership organisation has more user roles than a sales organisation, including elected officers and volunteers who use the system a few times a year. Those are the users who generate support requests if training is thin. We cover the discipline in the article on change management for CRM.

None of this is unique to membership organisations, and the research on cost overruns is worth knowing even though it covers projects far larger than yours. In a 2012 study of more than 5 400 IT projects, McKinsey and the BT Centre for Major Programme Management at the University of Oxford found that large IT projects on average ran 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. The study defined a large project as one with an initial budget above 15 million dollars, so the magnitude does not transfer to a membership organisation. The mechanisms do, and they are the five above. Panorama Consulting’s annual ERP survey, which rests on self-reported answers from businesses, points the same way at a smaller scale: budget overruns remain common, and additional technology needs are the most cited cause.

Coexistence: how to spread the cost and reduce the risk

Coexistence means the old and the new system live side by side for a period, and that you move one process at a time instead of everything on one date. Replacing everything at once is rarely the right shape for a membership organisation, especially when the annual budget is fixed and the board approves it once a year.

The order matters. Establish the data foundation first, so member data, organisational structure and history live in one place you own. Let the existing system keep owning dues and payments until the new setup has been verified against a real run, not against test data. Then move one process at a time, with the ledger boundary kept where it belongs, which we describe in the article on membership ledgers and ERP. Decommission last.

Pattern: organisations in the 10,000 to 30,000 member range that move in stages, in projects we have taken part in, often spend three to five months longer in total than those attempting one combined transition. In return they spread the cost across two budget years, and they are less likely to disrupt a dues run. The organisations we see struggle are those that combined a system change, a new dues model and a new self-service portal into one delivery, and then let all three depend on the same go-live date.

How to build a decision basis in four weeks

For most organisations in this range, four weeks is enough to take the decision, provided the mapping actually asks the uncomfortable questions. Where the environment is unusually complex, with many integrations or several parallel member registers, more is needed. In our experience a larger feasibility study rarely changes the conclusion, but it often moves it further out in the year.

• Week 1: inventory. Every connected system, every integration point, every report with a named recipient, every user role including elected officers and volunteers.
• Week 2: data quality. Duplicates, incomplete records, how many years of history are actually used, and where the dues rules are documented. If they only exist in one person's head, that is a finding in itself.
• Week 3: process. Which processes actually cause friction today, and which of them a new system would solve. This is the week that most often reveals that the problem is reporting, not the register.
• Week 4: two scenarios and a five-year model. Change, and stay and improve. Both with one-off costs, recurring costs, stewardship and your own hours. If the two land close in kroner, the choice is decided by what the calculation does not capture: member service, manual work that disappears, and the operational risk in what you have. Cost, benefit and risk must be weighed together.

Ask any supplier for an estimate built on that mapping, not on a general price list. And ask for the estimate to be split by the items in the first table. A supplier who cannot break the number down that way has not understood your environment well enough to price it.