This is the second part of a three-part guide to replacing your association management system.
- Part 1 covered how to assess whether a switch is genuinely warranted.
- This section covers the selection process itself: how to align your organization before going to market, build an RFP that produces comparable responses, run demos that surface weaknesses rather than strengths, and model total cost of ownership across a realistic timeframe.
- Part 3 covers implementation if you were to select ReadyMembership.
- The evaluation checklist is available to download and use alongside each stage.
The hardest part of replacing an association management system is not deciding to do it. It’s running a selection process that produces the right answer. Associations rarely fail here through bad judgment. They fail through structural mistakes that are entirely avoidable. Teams skip internal alignment before going to market. RFPs describe the current system instead of the future one. Demo days let vendors lead with their strengths and bury their weaknesses. Reference calls confirm what the association already wants to believe.
This guide walks the selection process in the order the steps should happen, not the order most associations attempt them. It starts with getting your own organization aligned before you contact a single vendor. It then covers building the RFP, deciding how many vendors to include, running the demo stage, conducting reference calls, and assessing total cost of ownership. It closes with the shape of the AMS market in 2026, so you can build a longlist that fits your association rather than the vendor’s pitch.
Get your own house in order first
The selection process has to be anchored internally before a single vendor is contacted. This is the step most associations underinvest in, and it’s the source of most problems that surface later.
1. Align on success
Align on what success means before you write requirements. The most common RFP mistake is producing a long list of functional requirements before anyone has agreed what the new system is supposed to achieve. Requirements written without a success definition describe the current system’s behavior. They lock in legacy processes that were never working well, and they exclude approaches that would serve the association better.
Start with outcomes. What does the membership director need to be true in 18 months? What does the executive director need to report to the board? What should a member be able to do that they cannot do today? These questions produce requirements worth writing. Feature checklists produce responses that are hard to compare and easy to game.
2. Involve every department
Get every department in the room before the RFP goes out. Finance, events, membership, IT, and communications each have different needs and different tolerances for change. Skip internal alignment before the RFP is issued, and vendor clarification questions will expose the gaps. The process then stalls while the association resolves internally what it should have settled before going to market.
3. Bring finance in early
Finance deserves particular attention. In associations making this transition, finance is consistently the department that gets involved latest and adjusts hardest. The implications for invoicing, payment reconciliation, deferred revenue handling, and accounting system integration are significant. If your finance team has not reviewed and signed off the financial requirements before the RFP is issued, you will pay for it later, either in the evaluation, the implementation, or both.
4. Set your budget range
Set your budget range before you send anything out. This sounds obvious. Associations still go to market without a confirmed range, which means they cannot disqualify vendors that are clearly out of reach until they’ve already spent time evaluating them. Set a realistic range covering license fees, implementation, data migration, and first-year running costs. Use it as a filter from the start. As AHOU’s Rheanna Smith reflected after completing her own selection process: “ReadyMembership really checked all the boxes of everything we required.” That confidence came from a process that started with a clear definition of what “checking the boxes” actually meant.
5. Check governance requirements
Check your governance requirements. Some associations have procurement thresholds, board approval requirements, or bylaw provisions that affect the selection process. An executive director who starts an AMS evaluation without checking whether the board needs to vote on the final decision, or whether the bylaws require competitive tendering above a certain contract value, risks having the decision challenged or delayed at the worst possible moment.
Building the RFP
A well-structured RFP does two things at once. It gives vendors the information they need to scope the work accurately, and it gives your evaluation team a framework for comparing responses consistently. Most RFPs do neither well enough.
The thirteen sections a well-structured AMS RFP should contain:
- Organization overview. Background on the association: membership size, structure, mission, and why you are going to market. Vendors need this context to calibrate their response and their team.
- Project objectives and success criteria. Quantifiable goals, not vague aspirations. “Reduce manual renewal processing time by 50%” is a success criterion. “Improve the member experience” is not.
- Current state and pain points. A description of existing systems, integrations, and the specific problems driving the replacement. Without this, vendors cannot size the effort or demonstrate relevant experience.
- Functional requirements. The core of the RFP. Break it into must-haves and nice-to-haves across membership management, events, finance and billing, communications, committees, CPD or learning, and reporting. Specify a response format. Use a shared document or spreadsheet where every vendor responds in the same structure. Skip this and you’ll receive responses in incompatible formats that are nearly impossible to compare.
- Workflow documentation. This deserves its own section, separate from functional requirements. Describe how your team actually works: how members renew today, how conference registrations are processed, how certifications are recorded. A vendor who understands your workflows can assess fit far more accurately than one responding to a feature checklist. This is also where you flag any non-negotiable workflows, the processes mandated by your bylaws, governing regulations, or board decisions that any new system must accommodate.
- Technical and integration requirements. Hosting preferences, SSO requirements, and every existing system the AMS must connect with, including the version, API availability, and data volumes for each. Vague integration requirements produce wildly variable cost estimates. Be specific.
- Data migration requirements. Volume, complexity, history, and the condition of your existing data. State which records must be migrated, over what timeframe, and who owns the mapping and validation work. Data migration is consistently underestimated in RFPs. It typically consumes 30% of the project effort. Give it the space it deserves.
- Implementation and project approach. Your expected timeline, the internal resources available to the project, and any fixed constraints, particularly go-live dates relative to your renewal cycle or annual conference.
- Ongoing service and support. SLAs, support tiers, account management model, training approach, and how the vendor handles product roadmap input from clients.
- Total cost of ownership. Ask vendors to quote across five years, not just year one. Year-one figures look similar across vendors. Years two through five are where the real differences emerge. Request a breakdown covering license fees, implementation, data migration, integration build and maintenance, training, and what is included versus charged after go-live.
- Vendor credentials and references. Company background, financial stability, and relevant client references, ideally associations of similar size, type, and complexity to yours.
- Evaluation criteria and weighting. Tell vendors how you will score their responses and what carries the most weight. This disciplines your own evaluation and signals to vendors where to invest their response effort.
- Process and timeline. Submission deadline, how clarification questions should be submitted, and one point that matters more than it looks: confirm that all vendor questions and answers will be distributed to every respondent. Without a structured Q&A process, vendors work from different information sets and the comparison is compromised from the start.
How many vendors to include
There’s no universally right answer here. The right number depends on the size of your evaluation team, your budget confidence, your go-live constraints, and any governance requirements that mandate a minimum number of competitive bids.
What is clear from experience across association technology selections is that casting the net too wide creates its own problems. Send RFPs to eight or ten vendors and you incentivize generic responses, create enormous evaluation overhead for your own team, and often end up with a shortlist no better informed than a well-reasoned longlist would have produced.
Work through these factors before you set your numbers:
✓How much time does your evaluation team realistically have to assess responses?
✓Does your go-live constraint allow a nine-month procurement process, or do you have twelve months to go live?
✓Have you done enough market research to have a view on which vendors are worth serious consideration?
✓Are there governance requirements that specify a minimum number of competitive bids?
As a working guide: no more than eight vendors at the RFP stage is manageable for most associations. A shortlist of three to four is the right size for demo and reference stages. Go below that and you limit competition. Go above it and the evaluation process becomes the project.
To narrow from longlist to shortlist, apply your budget range as the first filter. Then assess vendor fit against your association type and size, the functional requirements you flagged as must-haves, and the quality of their RFP response, especially how specifically they addressed your workflow documentation and integration requirements rather than answering generically.
The demo stage
The demo is where most associations give vendors too much control. A vendor-led demo is a polished performance built to show strengths. It will not surface weaknesses unless you create the conditions to force them out.
The single most important change you can make is to provide a scripted scenario rather than a blank invitation to demonstrate the platform. Give vendors a set of specific scenarios drawn from your actual workflows: your renewal process, your event registration flow, your reporting requirements. Ask them to demonstrate those scenarios in sequence. This makes responses comparable, and it surfaces capability gaps a standard demo would never reach.
Questions most associations forget to ask during demos:
Q
When a vendor demonstrates a capability that was not in your original RFP requirements, ask immediately whether it’s included in the original proposal cost or whether it would be an additional charge. Demos are commercial events. Features shown during a demo that fall outside the original scope are often billable additions, and unspoken assumptions in either direction create problems later.
Q
Ask to see the admin interface, not just the member-facing portal. Associations often evaluate platforms on the member experience, then discover after implementation that the back-office admin interface is clunky, counterintuitive, or requires technical staff for tasks that should be self-service for non-technical staff.
Q
Ask what happens when the platform updates. If the vendor has built custom features on top of the core product, what does an upgrade mean for those customizations? On some platform architectures, custom work requires paid remediation every time the underlying system releases a major update. That’s a TCO question as much as a product question, and the demo is the right time to raise it.
Reference calls
References provided by vendors are, by definition, clients the vendor expects to speak well of them. That does not make them useless. It does mean the value of a reference call depends almost entirely on the quality of the questions you ask.
Before each call, check the vendor’s online reviews on G2, Capterra, or any sector-specific review platforms relevant to your association type. Look for patterns in what reviewers consistently flag as problems. Then use the reference call to follow up on those patterns. A reference client’s answer to “we noticed several reviewers mention difficulties with X, has that been your experience?” will tell you far more than “how has your overall experience been?”
The questions that consistently produce the most useful answers in AMS reference calls:
Q
What has gone wrong, and how did the vendor respond when it did?
Q
If you were making this decision again, what would you do differently in the selection or implementation process?
Q
How does the vendor handle situations where your requirements fall outside the platform’s standard capability?
Q
How did the relationship change between the sales process and the delivery process? Did the reality match what was promised?
Q
What does a typical support interaction look like when something breaks?
A reference client who answers these candidly is worth more than one who gives an unqualified endorsement. The goal is not to find reasons to reject a vendor. It’s to walk into implementation with an accurate picture of what the relationship will look like.
Understanding total cost of ownership
License fees are the most visible line item in an AMS comparison and often the least informative. Associations that make poor procurement decisions almost always do so by evaluating year-one costs in isolation.
A genuine TCO assessment covers a three-to-five-year horizon and accounts for the following.
✓ License and subscription fees.
The base platform cost and how it scales, whether pricing is tied to member count, contact volume, number of admin users, or modules enabled. Model the fee at your current size and at projected growth. Ask how annual uplifts are calculated and whether they are capped.
✓ Implementation and onboarding costs.
The one-off cost to get live: discovery, configuration, build, testing, and go-live. Ask whether this is fixed-price or time-and-materials, what happens if scope changes mid-project, and whether the vendor or a third-party partner delivers the implementation work.
✓ Data migration.
Often quoted separately and consistently underestimated. Account for data cleansing work, which is usually an internal cost or a specialist agency cost, the vendor migration fee, and the cost of validation during cutover. The condition of your existing data is the biggest variable here. Associations with fragmented, inconsistent, or poorly maintained data will face higher migration costs regardless of which vendor they choose.
✓ Integrations.
Each connection to an existing system carries a build cost and an ongoing maintenance cost. Ask whether integrations are native to the platform, connector-based, or custom-built. Ask who is responsible, and at what cost, when the connected system upgrades.
✓ Customization and configuration.
The gap between what the platform does out of the box and what your association actually needs. This is where costs most commonly spiral past the original estimate. Ask vendors to be explicit about what is standard configuration and included, what is supported customization and charged at a stated rate, and what would require bespoke development. The distinction between these three categories carries significant cost and risk implications.
✓ Platform architecture: single system versus assembled stack.
This deserves its own line in a TCO comparison because the cost profile is fundamentally different. A purpose-built platform that includes membership management, events, communications, and a CMS in one integrated system carries a different maintenance overhead, integration cost structure, and upgrade cost profile than a CRM with membership modules bolted on, a separate CMS, and a member portal stitched together through a series of integrations. Each additional system in the stack is another licensing relationship, another renewal cycle, another point of failure, and another integration to maintain every time any component updates.
✓ Staff time savings from automation.
This is a benefit, not a vendor cost, but it belongs in the TCO model because it’s often the single strongest financial argument for switching. Quantify the staff time currently consumed by manual processes a better-configured system would automate: renewal chasing, payment reconciliation, event registration management, report generation, data reconciliation between systems. The associations that make the strongest case to their boards are the ones that have done this calculation honestly. AAPL was spending more than $200,000 a year running six disconnected platforms that still did not work reliably. FEDESSA cut the time spent on membership management to less than a third of what it was before, recovering 12 hours a week the team could redirect to member value rather than administration. These are not anomalies. They are what an honest TCO comparison tends to surface.
✓ Exit and transition risk.
Often the last thing anyone wants to think about during a procurement process, and one of the most important. What does it cost to leave? Can you export all your data cleanly and in a usable format? What are the contractual lock-in provisions? What would a future migration actually involve? A vendor who makes data portability difficult, or whose contracts include punitive exit clauses, adds a hidden cost to every year of the relationship.
The AMS market: understanding the landscape
The association management software market in 2026 divides into four platform categories. Knowing where a given vendor sits, and what that category typically means for an association of your type and size, gives you useful context for building an initial longlist and for reading vendor claims.
⚙ Legacy platforms.
Legacy platforms were built decades ago and have evolved through accumulated customization and bolt-on modules rather than architectural redesign. They tend to have broad functional coverage and large installed bases, particularly among larger associations that have been with them for years. The trade-offs are well documented. Upgrade paths are complex, interface design reflects the era the system was built in, and total cost of ownership over time runs higher than initial license fees suggest, because customization work is required to fill gaps that purpose-built modern systems handle out of the box.
▦ Enterprise platform solutions.
Enterprise platform solutions are built on top of horizontal CRM or ERP infrastructure, typically Salesforce or Microsoft Dynamics, with association-specific functionality layered on through modules or specialist implementations. They offer deep integration with the parent platform ecosystem and can suit large, complex associations with significant in-house technical capacity and existing investment in that infrastructure. The trade-offs include higher implementation complexity, greater dependence on technical resource for ongoing management, and a cost profile that reflects enterprise-grade infrastructure.
↑ SME and lightweight platforms.
SME and lightweight platforms are designed for smaller associations, typically those with straightforward membership structures, limited events requirements, and small staff teams. They offer low entry cost and fast implementation, and they suit associations in the early stages of growth or with limited operational complexity. As associations scale, or as their requirements diversify, these platforms frequently reach their limits. The cause is not poor engineering. They were not designed for the complexity that comes with growth.
✳ Modern AMS platforms.
Modern AMS platforms are purpose-built association management systems developed in the past decade, designed around the operational realities of membership organizations rather than adapted from generic CRM or ERP foundations. They tend to offer adaptive roadmaps, contemporary UX and member portal design, and increasingly, native AI capability, features that older architectures struggle to add without significant re-engineering. Mid-market associations with complex membership structures, active events programs, and ambitions for member self-service typically find the best fit here.
On pricing. These categories sit at meaningfully different price points, and the right budget filter for your longlist depends on where your requirements place you. Rather than quoting specific figures, which shift with member count, scope, and market conditions, the chart below shows the relative positioning of the four categories on a five-year total cost of ownership basis. Note that the gap between initial license cost and five-year TCO is widest for legacy and enterprise platforms, where customization, integration maintenance, and upgrade remediation costs compound over time.
How platform costs compare over five years
Illustrative cost ranges by platform category — not actual pricing
SME / lightweight toolsBasic membership tools
Modern AMSPurpose-built platforms
Legacy platformsOlder, entrenched systems
↳ Dashed zone reflects typical hidden TCO uplift from customisation, integration, and upgrade costs
Enterprise suitesLarge-scale, highly configured
Low High
Relative cost over 5 years
Pricing varies significantly by member count, scope, and configuration. Request a detailed five-year TCO from each shortlisted vendor.
ReadyMembership sits within the modern AMS category.
A disciplined selection process is a sequence, and skipping a step costs you later. Align your organization on outcomes, departments, budget, and governance before you write a word of the RFP. Build an RFP that defines success and standardizes responses. Keep the vendor count tight enough to evaluate properly. Script the demo so weaknesses surface. Use reference calls to test the patterns reviewers already flagged. Model total cost of ownership across five years, not one. Run the process in that order and the final decision becomes the easier part, because the hard work of knowing what you need is already done.
What to read next
If you landed here without reading Part 1 first, it's worth going back. It covers how to assess whether a switch is genuinely warranted before you invest time in an evaluation, and includes a scored self-diagnostic you can use to build the internal case for change. The evaluation checklist gives you a vendor scorecard and requirements framework to work through alongside every stage of this process.
If you're ready to think about implementation, Part 3 covers what a ReadyMembership project actually involves, what your team needs to own at each stage, and the internal readiness work that tends to decide whether go-live goes smoothly or not.
Download Part 3: ReadyMembership implementation
