Start with the operating model
A growing provider needs more than additional logins. Decide which services share participant information, which teams must be separated and who can amend a financial record. Write those boundaries before the demonstration. Otherwise, a polished dashboard can conceal a workflow that relies on repeated manual corrections.
This comparison covers SupportAbility and Lumary’s disability products. It does not treat every product sold by either company as interchangeable. Lumary describes DC Pro and DC Enterprise with different organisational and configuration needs in mind. Ask the vendor to name the proposed edition on every estimate.
What changes the decision
| Decision | SupportAbility | Lumary disability products |
|---|---|---|
| Commercial structure | Published staff brackets; annual upfront commitment; smallest bracket covers 30 staff | Obtain a scoped quote for the edition, configuration and implementation |
| Operational scope | Published client, activity, funding and finance workflows | Published client and plan management, rostering, claiming and reporting |
| Integration work | Confirm the fit of standard integrations and any custom work | Identify required payroll, accounting and other connections in the proposal |
| Organisational fit | Test your service boundaries and reporting structure | Test the proposed Pro or Enterprise configuration against the same boundaries |
Source-based differences do not establish reliability or ease of use. Those need your own demonstration, reference checks and contract review.
A demo that exposes the difficult work
Set up a fictional participant receiving two service types across two sites. Give a frontline worker, site manager and finance user different permissions. Ask each person to find only the information needed for their task. Change a service agreement and follow the impact on the roster, funding forecast and invoice.
Next, correct an activity that has already been billed. Ask to see the original entry, the correction, the responsible user and the resulting financial record. Produce the same utilisation report before and after the correction. A report that looks right is not enough: your reviewer should be able to trace it back to the service.
Budget for implementation capacity
Request a written work breakdown: data cleanup, migration mapping, configuration, training, integration testing and acceptance. Allocate an internal owner and realistic staff time to every workstream. Ask what happens if a milestone is delayed and when subscription charges begin.
SupportAbility’s public subscription description provides useful commercial boundaries, but the final amount still needs confirmation. Lumary’s proposed scope needs the same treatment. Neither an annual licence total nor a sales presentation is an implementation budget. Model both proposals in the software cost worksheet.
Our decision rule
Take forward the proposal whose actual edition can demonstrate your information boundaries and financial reconciliation, with a migration plan your organisation can resource. For a small team, test the minimum commitment early. For a larger team, insist on named acceptance criteria and a representative pilot before agreeing to a full rollout. A bigger feature list does not replace either step.
Sources behind this comparison
- SupportAbility: product overview · checked 2026-09-23
- SupportAbility: subscriptions and minimum commitment · checked 2026-09-23
- Lumary: disability software · checked 2026-09-23
Confirm current terms with the vendor. An unanswered question does not establish that a feature is absent.