Penelope Case Management Alternatives for Australian Community Services

Australian community services organisations running Penelope case management are asking a reasonable question: what happens next, and what should we move to?

Before answering, we should be upfront about what we know and how we know it.

Firstly, we are not Bonterra, we have no insight into their plans, and nothing in this article should be read as a statement of what they intend. What we have is two things: what is publicly observable on Bonterra’s own website, and what Australian organisations running Penelope have told us when they have approached us about migration. Where those organisations describe what Bonterra has said to them, we are reporting their account of those conversations. We have not verified it with Bonterra, and current Penelope customers should ask Bonterra directly rather than rely on a competitor’s summary (us).

The observable part is straightforward. Bonterra’s own material describes Apricot, Efforts to Outcomes (ETO) and Penelope as three separate products that Social Solutions offered, and states that Apricot forms the basis of Bonterra’s case management solution. Apricot is a distinct platform, not a continuation of Penelope meaning there is no successor product. It stands to reason that a Penelope customer moving to Apricot faces a full platform migration, the same as moving to any other vendor.

That matters, because it changes the question. If the migration is a migration either way, the choice of destination is genuinely open.

What we cannot tell you is what happens to Penelope itself. The organisations we have spoken to are not acting on an announcement, because as far as we know, there has not been one. They are acting on the absence of one.

This article covers what Penelope did well, what has changed, what modern Australian Client and Case Management Systems (CCMS) do that Penelope-era platforms did not, and the practical criteria for choosing a replacement.

It also covers the part most organisations leave too late: data migration.

What is happening with Penelope case management in Australia?

Penelope was built by Athena Software, a privately owned company founded in 2001 and headquartered in Waterloo, Canada, with staff also based in the United States, Australia and the United Kingdom. In January 2021, Social Solutions Global announced it would acquire Athena Software. Social Solutions was at that time backed by Vista Equity Partners. The acquisition completed on 18 March 2021.

What followed is worth setting out plainly, because it explains a great deal about where Penelope sits today.

Bonterra’s own account is that, from 2014, Social Solutions was acquired by a succession of private equity firms before being purchased by Apax Partners LLP in August 2021. Apax had acquired CyberGrants in June 2021, then acquired Social Solutions and EveryAction in August 2021, with the stated intention of merging them into a single social good software platform. On 23 March 2022, those businesses were brought together as Bonterra, headquartered in Austin, Texas.

So in little over a year, Penelope went from a founder-led Canadian company that had built it over two decades, to one product line inside a private equity roll-up of four separate software businesses, headquartered in a different country again, serving a market whose funding and compliance regime has nothing in common with Australia’s.

That is not a criticism of anyone’s conduct. It is how the model works. Roll-ups are assembled to be rationalised: duplicate products get consolidated, engineering effort concentrates on the assets with the largest addressable market, and the portfolio gets shaped for an eventual exit. Australian community services, running a handful of heavily configured multi-program tenancies at the end of a very long support line, is not where that logic points.

Two observations follow, both verifiable:

• Penelope has no successor product in Bonterra’s case management line. Bonterra’s own material describes Apricot, Efforts to Outcomes (ETO) and Penelope as three separate products that Social Solutions offered, and states that Apricot forms the basis of Bonterra’s case management solution. Apricot is a distinct platform, not a continuation of Penelope. As at 22 September 2026, Bonterra’s Case Management navigation lists only Apricot and Apricot for Government; Penelope does not appear in the product navigation, the footer product list, or the login menu, which covers ETO (United States, Australia and Canada) and Apricot. Penelope appears on the site only in historical passages explaining what Social Solutions used to offer. Sources: Bonterra Apricot, Social Solutions Apricot: How it joined the Bonterra family. This matters for a Penelope customer in a way that a simple product-page delisting does not. If Penelope had been folded into Apricot, there would be an upgrade path. Bonterra’s own description says otherwise: Apricot is a separate product built by a separate team. A Penelope case management customer moving to Apricot faces a full platform migration, not an upgrade. If the migration is a migration either way, the choice of destination is genuinely open.
• Australian and New Zealand support has been a recurring theme in published reviews. GetApp’s analysis of verified Penelope reviews notes a group of users reporting slow response times and limited local support, particularly in New Zealand and Australia. A Capterra reviewer cites a lack of technical support available in Australia. Sources: GetApp, Capterra.

In fairness, Bonterra still publishes an Australian login for Efforts to Outcomes (ETO), so existing Australian customers are being served. But ETO is absent from Bonterra’s product navigation too. We are not in a position to state what Bonterra intends.

What we can report is what Australian organisations running Penelope have told us. Several have approached us about migration in recent months. Their account is consistent: when they have asked Bonterra directly about Penelope’s future, the response has been that the product continues to be supported for the foreseeable future, with nothing put in writing and no dates attached. Their concern is not that support is being withdrawn. It is that meaningful feature development stopped years ago, leaving minor bug fixes, and that a product in that state will not pick up the capabilities they now need.

The response to that has been pragmatic rather than alarmed. As one put it, the point is to migrate on their own terms and schedule rather than in a last-minute rush.

What did Penelope do well?

Penelope earned its place in the Australian sector, and any honest discussion should start there.

• Multi-program delivery in one system. Penelope handled organisations running several distinct programs without forcing a separate database per program.
• Configurable forms and workflows. Published features include smart forms, automated workflows, referral and waitlist management, and email and SMS reminders (SoftwareAdvice).
• Service and session tracking built for agencies. It was designed around service delivery, not clinical billing, which suited community services.
• Funding body reporting, including Australian requirements. Bonterra published material referencing NDIS and DSS integrations alongside the Penelope client portal (Bonterra).
• Longevity. One reviewer records using Penelope since 2003. Systems that survive two decades in this sector do so because they work (Capterra Australia).

Where did Penelope show its age?

The existing bullets are sourced to published user reviews:

• Reporting depth. Reviewers describe out-of-the-box reporting as limited, with a Tableau interface available at additional cost. Another notes that custom reports cost extra and there is no easy way to pull and manipulate data without commissioning a report build (Capterra Australia, G2).
• Configuration burden. One reviewer recommends having a dedicated person to learn and administer the system (G2).
• Interface and mobility. A reviewer describes clunky data entry and a system that is not mobile or tablet friendly (Capterra).
• Distance from the Australian context. Time zone, support hours, and a roadmap shaped by a different funding environment.

None of this makes Penelope a bad system. It makes it a system of its generation.

The second set comes from Australian organisations running Penelope case management who have approached us about migration. These are their words, not published reviews, and they are consistent across the organisations we have spoken to.

• Grant contracts are not modelled well. Configuring minimum data sets around funded programs is cumbersome, which makes data quality harder to enforce at the point of entry rather than after the fact.
• One integration, not many. DSS DEX is the vendor-supported reporting integration. Organisations reporting into more than one collection require customisations and are on their own.
• Functionality built on the side. Reminders, billing, data quality checks and reporting are being built externally via database extracts and calls. Each of those is a piece of the operation that no longer sits cleanly together, and each is a thing to maintain, document and hand over when a staff member leaves.
• Named capability gaps. Waitlists, digital forms, reminders and allied health functionality were raised repeatedly as areas where more flexibility is needed.

The pattern here is worth naming. None of these are faults of the original design. They are the accumulated distance between a platform built two decades ago and a sector whose reporting, consent and service delivery expectations have moved considerably since… and continue to move.

What do modern Australian CCMS platforms do that Penelope-era systems did not?

The gap is not features for their own sake. Penelope-era platforms were built when configuration meant a vendor engagement, reporting meant a report build, and mobile meant a separate app. What has changed is where the work sits. On a modern platform your team configures, reports, captures and exports without waiting on anyone, and the system follows a changing funding landscape rather than lagging it.

• No-code configuration. Programs, workflows, forms, assessments, notifications, permissions and reporting are configured without code, so changes can happen fast.
• Integrated digital forms and surveys. Intake, assessment, consent, outcome measures and feedback captured digitally, including by clients themselves, rather than on paper and re-keyed.
• Self-service reporting. Staff build their own reports without a paid engagement, with an option to push data to Power BI or Tableau where genuinely needed.
• Your data, on demand. Full export of your own data without a service request, a fee or a wait. This matters more than it looks: the ability to leave is what keeps a vendor honest, and a system that makes export difficult has told you something about the next renewal.
• Automation and notifications. Event-based reminders, escalations and task flows, so review dates and compliance obligations do not depend on someone remembering.
• Mobile and field capture. The system works on a phone or tablet, not a cut-down companion app with a fraction of the functionality. Workers in homes, in outreach and in the field get the same records they have at a desk, and can capture notes, documents, photos and signatures at the point of service.
• Flexible funding body reporting. Most organisations report into several places at once. For example, DEX for Commonwealth grant programs (with state jurisdictions layering their own guidance on top), PMHC MDS for Primary Health Network commissioned services, AODTS NMDS for alcohol and other drug treatment and NSW DCJ infoShare for Family Preservation. The capability that matters is not whether a system supports a specific portal today. It is whether it’s flexible enough to apply a new extract, field set or report for the next funder without waiting on a vendor release or paying for a rebuild. A data model shaped around one reporting model will only bend only so far, and past that point the real reporting unfortunately moves into something like Excel.

What should you look for in a Penelope case management alternative?

Can it run all your programs?

First, set the claiming systems aside. NDIS and aged care claiming are specialist domains with their own software, and a platform built around either will not run grant-funded service delivery well. We covered that separately in Why NDIS and Aged Care Software Cannot Run Your Grant-Funded Programs. This section is about everything else: the grant-funded programs that made up most of what Penelope was doing for you.

This is the capability Penelope users are most at risk of losing. Penelope handled multiple distinct programs in one system, and organisations built around that. A replacement that cannot do the same is a step backwards, however modern it looks.

Most community services organisations are not single-program. They run several grant-funded programs at once, often with state, Commonwealth and philanthropic funding in the same building, each with its own intake rules, service types, consent requirements and reporting obligations.

The question to ask is about the data model. Does the vendor’s core model work as a flexible common denominator across grant-funded service delivery, so each new program is configured on the same foundation? Or was it built for one program type, with everything since bolted on? A model that generalises properly absorbs the next program. One that does not accumulates exceptions, and eventually the exceptions are the system.

How much of the operation actually sits in the system?

A useful test is to count the workarounds. Ask your own team what runs outside the Penelope case management system today: the reminder scripts, the billing spreadsheet, the separate web forms and survey tools, the data quality reports someone rebuilds each month, the exports feeding something else.

Each of those exists for a reason, and each one was a sensible decision at the time. The problem is cumulative. Every bolt-on is a separate thing to maintain, a separate point of failure, and a separate piece of undocumented knowledge sitting with whoever built it. When that person leaves, the organisation finds out how much of its operation was running on their goodwill.

When assessing a replacement, take that list of workarounds into the demonstration and ask which of them the platform absorbs natively. Not “can it be integrated with”, which is almost always yes and almost always billable. Which of these does the platform do, out of the box, as configuration rather than development?

How does change actually get made, and what does it cost?

This is the single biggest cost difference over a five-year term, and the answer is rarely at either extreme. A platform that hands administrators unguarded access to the data model lets you break your own reporting and generate technical debt over time. A platform where every change is a billable service request means your total cost of ownership is nothing like the licence fee.

What works well is a split. Your team holds extensive no-code capability for day-to-day change. Structural work sits with the vendor, who should be teaching your people to specify well rather than just taking tickets. That partnership is what keeps change fast and the data intact.

Ask three things. What can our administrators change without involving you? What sits with you, and why? And for that second category, what is the turnaround and what does it cost?

Does it handle Australian funding body reporting?

Be specific, and name the collections that apply to you. DSS DEX is the common one, accepting data via API transfer, bulk XML upload or direct portal entry. Beyond that: PMHC MDS for Primary Health Network commissioned mental health services, AODTS NMDS for alcohol and other drug treatment, the Specialist Homelessness Services Collection managed by the AIHW with client data submitted monthly to Validata, and state collections such as NSW DCJ infoShare for Family Preservation.

Ask any vendor exactly which of these they produce as a compliant extract, which they support through data capture and screens only, and which they do not touch. The distinction matters: a system can be your record of truth for a program without generating the submission file, and that is a legitimate design position if the vendor is upfront about it.

A vendor that answers “yes” to everything has probably not read the specifications.

Where does your data live, and who can reach it?

Under Australian Privacy Principle 8, before disclosing personal information to an overseas recipient an entity must take steps reasonable in the circumstances to ensure the recipient does not breach the APPs, and under section 16C the entity remains accountable for acts of the overseas recipient that would breach the APPs (OAIC APP 8 guidelines).

That accountability sits with you, not your vendor. For organisations holding sensitive client information, including child protection, family violence and health records, ask where data is hosted, whether the tenancy is shared or single, who has administrative access, and from which jurisdictions.

Is the vendor’s commitment to Australia structural or discretionary?

A local sales presence is not the same as a local product and support team. Ask where the product is built, where support sits, whose funding rules drive the roadmap, and what share of revenue comes from this market. A vendor whose Australian business is minimal can withdraw from it without much internal debate.

Data migration is where these projects succeed or fail

You can select the right software platform and still end up with a failed implementation. Migration is the step that decides it, and it is the step most often left too late.

It is also the step where close enough is not good enough. This is not a finance ledger, where an error surfaces at reconciliation. A missing risk assessment, a safety alert that did not carry across, a case history detached from the person it belongs to: these are the records a worker relies on to make a decision about someone’s safety, and the failure shows up in a real person’s life before it shows up in a report.

The pattern is predictable. Migration gets treated as a task near the end of the plan rather than a workstream that shapes it. Scoping often happens after contracts are signed, when the real condition of years of historic data finally becomes visible. Vendors without genuine migration experience price it as a data load, because that is what it looks like from the outside, and the estimate holds until someone opens the source system.

By then the budget is set, the go-live date is published to the board and the funders, and the only variables left are scope and quality. That is the risk. Not that migration is hard, but that it is discovered to be hard at the point where you have no room left to respond.

Every migration is different. A Penelope tenancy that has run for fifteen years contains case files, service files, historical notes, attachments, closed episodes, funding history, staff records, custom fields added by three generations of administrators, and structural decisions nobody now on staff remembers making. There is no generic migration. There is only this migration.

The risks are specific, and mostly irreversible.

• Client identity breaking across merged or duplicated records, so history detaches from the person.
• Historical service data arriving in a shape that cannot be reported on, which matters when a funder asks for a five-year trend.
• Attachments and notes migrating without their case context.
• Consent, privacy flags and conflict-of-interest restrictions not carrying across, which is a live privacy risk rather than a data quality one.
• Closed cases treated as low priority, then needed for a complaint, audit or inquiry.

Tooling is not the differentiator. Experience is. Migration is a judgement exercise. Where the source system’s model does not map cleanly to the target, someone has to decide what the data actually meant and how to represent it faithfully. That judgement comes from having done it before, repeatedly, on messy real-world systems.

Ask prospective vendors these questions.

• How many complex migrations have you completed, from which source systems?
• Who does the work, your staff or a subcontractor?
• What is your approach to reconciliation, and what evidence do we get that nothing was lost?
• How many trial migrations before cutover, and do we get a full test environment?
• What happens to data that does not map cleanly? Who decides, and how is it documented?
• What is the rollback position if cutover fails?

Ask for references from organisations of similar complexity, and ask those referees specifically about migration rather than about the software.

Why SmarterSoft?

We wrote this article because of the volume of enquiries coming our way. Over recent months, many Australian community services organisations running Penelope have approached us about migration. They were not responding to any specific announcement. They were looking ahead and deciding to move on their own terms.

SmarterSoft is a 100% Australian owned and operated no-code Client and Case Management System, built for Australian government and not-for-profit community services organisations. We believe the organisations doing this work deserve a vendor whose roadmap is shaped by Australian funding rules, and whose commitment to this market is structural rather than discretionary.

As SmarterSoft is a commercial alternative to Penelope we have an obvious interest here, so of course please assess our claims below against your own criteria.

Here is how we measure up:

• Built for grant-funded and block-funded programs. Programs, funding sources, brokerage and expenses are modelled directly, not bolted onto a claiming engine.
• No-code configuration. The platform is assembled from approx. 30 configurable building blocks including: Program Management, Intake and Waitlists, Client and Case Management, Case and Support Plans, Goals and Actions, Client and Risk Assessments, Referrals, Digital Forms and Surveys, Incident Management and many more. Programs, workflows, assessments and reporting are configured without code. Structural change sits with us, so data integrity, privacy restrictions and historical reporting are protected.
• Australian data, Australian hosting. Single-tenant AWS infrastructure in the Sydney region. One client, one tenancy.
• Independently assessed security. SOC 2 attested, with controls aligned to ISO/IEC 27001:2022 and the ASD Essential Eight.
• Procurement-ready. Listed on government procurement panels and approved supplier schemes in every Australian state and territory, including NSW ICT Services Scheme Advanced Supplier status, plus Commonwealth BuyICT marketplace prequalification.
• Honest about scope. SmarterSoft is not NDIS claiming software and is not aged care claiming software. Those are specialist domains and we leave them to specialist vendors. Where an organisation runs both, SmarterSoft is designed to be the system of record for everything outside those claiming regimes.
• Migration experience. Complex migrations completed from a range of legacy case management platforms, including migrations of more than 100,000 client records with multi-program case, service and document history carried across intact.

Frequently asked questions

Is Penelope still available in Australia?

Penelope remains a Bonterra product and existing customers continue to use it. However, Bonterra’s own material describes Apricot, ETO and Penelope as three separate products that Social Solutions offered, and states that Apricot forms the basis of Bonterra’s case management solution. Apricot is a distinct platform, not a continuation of Penelope.

As at 22 September 2026, Bonterra’s Case Management navigation lists only Apricot and Apricot for Government. Penelope does not appear in the product navigation, the footer product list, or the login menu. It appears on the site only in historical passages explaining what Social Solutions used to offer.

For a Penelope customer, this matters. There is no in-family upgrade path: moving to Apricot would be a full platform migration, the same as moving to any other vendor. Current Penelope customers should ask Bonterra directly about support commitments and roadmap for the Australian market.

What is the best Penelope alternative for Australian community services organisations?

It depends on your program mix, but the test that matters most is flexibility. Funding rules, reporting collections and consent requirements change constantly, and the cost of a platform is decided by what happens when they do. Ask what your own administrators can change without raising a ticket, how a new program or a new funder’s data requirements get accommodated, and whether that is configuration or a paid development cycle.

If you run grant-funded community programs, look for an Australian-hosted platform with no-code configuration, a data model that generalises across program types rather than one shaped around a single reporting regime, maintained DSS DEX and other mainstream reporting, and demonstrated migration experience.

If your primary need is NDIS or aged care claiming, a specialist claiming vendor is the right choice, often running alongside a separate case management platform for everything else.

Can our Penelope data be migrated?

Yes. Penelope data can be extracted and migrated. The work is in mapping, reconciliation and preserving client identity and case history, not in the loading itself.

How long does a migration take?

It varies with data volume, the number of years of history, the degree of customisation in the source system and data quality. Expect trial migrations, reconciliation cycles and a parallel period before cutover. Any vendor quoting a timeline before examining your data is guessing.

Does SmarterSoft support DSS DEX reporting?

Yes. DSS DEX Integration is a SmarterSoft building block, maintained as part of the platform.