The questions your IT team should ask before your association signs an AMS contract
Choosing a new AMS is one of the most significant technology decisions an association will make, and getting the technical due diligence right from the start makes everything that follows considerably smoother. When IT and operations leads are brought in early, with a clear brief on what to look for, they can provide exactly the kind of scrutiny that turns a good selection process into a confident one.
This piece sets out the questions that IT and operations leads should be asking before a contract is signed, covering security, integrations, data ownership, staff training, and support. Some will overlap with questions the broader evaluation team is already asking. Others belong specifically to the technical review and are worth raising before the project moves into implementation.
Security and infrastructure
The security questions are worth covering first, partly because they carry the most risk if answered poorly, and partly because a vendor’s willingness to answer them in detail tells you something about how seriously they take this area.
The two accreditations most worth verifying are ISO 27001:2022 and SOC 2 Type 2. Both require ongoing compliance work throughout the year, not just at the point of audit, so ask when each was last renewed and whether you can see the audit reports rather than just a certificate. Ask specifically about penetration testing: how often is it done, who conducts it, and how are findings tracked and resolved?
On infrastructure, the questions that tend to reveal most are around hosting and redundancy. Which cloud provider does the platform run on, and what is the nature of the vendor’s relationship with that provider? Is the application deployed across multiple availability zones, so that a single data center failure does not take the platform down? Where are backups stored, and are they distributed across more than one cloud provider to avoid a single point of failure? These are not obscure questions. A vendor who cannot answer them clearly is telling you something important.
Integrations
As covered in more depth in a companion piece on evaluating AMS integrations, the integration questions are where a significant number of implementations run into difficulty later. The headline question is whether each integration the vendor describes is native and API-based, or whether it relies on a middleware connector or a manual data transfer. The distinction matters considerably for reliability and real-time data accuracy.
For integrations that are critical to your operations, ask whether you can speak to another client who has that specific combination working in production. A vendor who has genuinely done it before should be able to connect you with someone who can confirm it.
Beyond the technical architecture, ask what happens when an integration breaks. Is there monitoring in place that alerts the vendor before you notice? Who is the contact, and what are the response time commitments? And ask about API versioning: if the vendor releases a new version of their API, what is the process for updating existing integrations, and who is responsible for that work?
Data ownership and what happens if you leave
This is the area most likely to get glossed over in a vendor conversation, and one of the most important to nail down in the contract. The question of who owns your member data sounds obvious, but the practical implications are worth spelling out explicitly.
You should be able to export all of your data at any time, in a usable format, without needing to involve the vendor. Confirm what that format is, how complete the export is (including historical activity, not just current records), and whether there is a cost attached to it. Some vendors make data portability difficult in practice even when it is technically permitted in their terms.
Ask what happens to your data when the contract ends. How long does the vendor retain it, in what form, and what is the deletion process? If the vendor were to be acquired, or to discontinue the product, what contractual protections exist around your data?
These questions should be asked and answered in writing, in the contract, not just in a sales conversation. The single biggest fear in an AMS purchase is a failed migration. Knowing you can get your data out cleanly if you need to is a basic condition of entering into any long-term platform commitment.
Support, SLAs, and what happens after go-live
The support conversation tends to happen toward the end of a procurement process, after the feature evaluation is done. It deserves more attention earlier.
Ask what the support model looks like once the project is live. Is there a named account contact, or does everything go through a general helpdesk? What are the response time commitments by severity level, and how are those measured and reported? Ask specifically about out-of-hours coverage, particularly if your organization runs events or critical member processes at weekends.
It is also worth understanding how the vendor handles platform updates. How frequently are they released, how is advance notice given, and what is the process for raising a regression if an update breaks something in your configuration? These are not hypothetical concerns. They are routine events in any long-term platform relationship, and knowing the process in advance saves a great deal of friction later.
Staff training and organizational readiness
This is the area that IT leads are perhaps least likely to raise during a procurement, but Jack Thompson, Technical Support & Systems Manager at Pixl8, has seen it cause significant problems post-launch: “One of the things we see quite often is two or three contacts at an organization will learn everything about the system before it goes live, and they will be confident in how to use it. Then when the system goes live and the rest of the organization are involved in trying to use the system, if they haven’t been trained to the correct level, it’s really quite hard for them.”
The consequence is not just a difficult first few weeks. When staff are not confident in the system, they stop using it as intended, raise more support queries than necessary, and in some cases revert to older workarounds that undermine the data quality the new platform was supposed to fix.
The questions worth asking a vendor are: what does the training program cover, who delivers it, and at what point in the project does it happen? Is training included in the project cost or charged separately? What documentation is provided, and how is it maintained as the platform evolves?
As importantly, the internal question to ask before go-live is whether everyone who will use the system has been trained to the right level, not just the project team. This includes people who join the organization after launch. Building internal documentation that explains how your organization specifically uses the platform, rather than relying solely on the vendor’s generic guides, is one of the most valuable things a team can do to protect the investment.
The contract itself
A handful of things are worth reviewing carefully before signing, beyond the headline pricing and term length.
Check the notice period for cancellation and whether there are penalties for early termination. Check what the renewal process looks like and whether price increases are capped or at the vendor’s discretion. Confirm that data portability and deletion terms are written into the agreement, not just described verbally. If the vendor uses subprocessors (third-party services that handle your data), these should be listed and subject to the same data protection standards.
If the contract is long or complex, it is worth having your legal team review the liability clauses and any limitations on the vendor’s responsibility in the event of a data breach or service outage. This may feel like caution for its own sake, but the cost of that review is small compared to the exposure it is designed to protect against.
Bringing IT in earlier
The questions above are easier to ask and answer during an evaluation than after a contract is signed. Most of them do not require deep technical expertise to put to a vendor; they require the organization to have decided that they matter. IT and operations leads tend to add the most value in an AMS evaluation not as a final approver but as an active participant from the longlist stage, shaping the criteria before the field is narrowed.
The associations that get the most out of a new platform are generally the ones that went into the purchase with clarity about both the technical requirements and the feature set, and with the right people involved early enough to influence the outcome.
