Onit ELM is an enterprise legal management platform that in-house legal departments use to run matters, outside counsel billing, legal service requests, and workflow automation in one connected system. The product itself is well documented. The delivery work that turns it into a working system for a specific legal department gets written about far less often, and that work is where a rollout is won: configuration, data preparation, testing, and the first weeks of live use. This is what it looks like from the delivery side.
What is Onit ELM?
Onit ELM is a family of products, and that shapes every implementation from the first scoping conversation onward. The platform spans OnitX for complex enterprise deployments, SimpleLegal for mid-market environments, and Onit Unity, the next-generation architecture that consolidates the two.
Onit’s own materials describe the current Unity direction in terms of three capabilities: asking questions of matter and spend data, capturing legal service requests through structured intake, and automating billing guidelines, budgets, and approvals. Swiftwater’s practitioner overview of what Onit ELM is and how it works sets out the product picture in useful detail for teams mapping the platform for the first time.
Which of those products a client runs changes almost everything about the delivery plan.
Why does the OnitX, SimpleLegal and Unity structure matter for implementation?
Onit is consolidating its platforms onto a single architecture, and that is a change worth planning around at the scoping stage. Bringing OnitX and SimpleLegal together into Unity means one development roadmap and one consistent experience across deployment sizes, which is a clear gain for customers over the longer term.
Onit has been delivering Unity in stages. The company announced Unity e-Billing as the first of the complete Unity platform solutions, with ELM Professional following to bring deeper matter management and analytics.
For anyone scoping an implementation now, three questions are worth settling at the outset:
- Which product will this deployment run on at go-live?
- If Unity is the destination, how does the configuration being built now carry across?
- Who owns the migration timing: the client, Onit, or the delivery team?
All three are scoping questions, and answering them up front is what keeps the technical work efficient.
What does the configuration work actually consist of?
Configuration on Onit means constructing the business rules, intake paths, and approval logic that encode how a specific legal department works. It is the largest single body of work in most implementations.
Two things drive the volume. The first is intake. A global legal department carries different request paths for different regions, languages, and matter types. On a legal service request implementation, Basla has built eight separate intake front doors to cover language and country variations within a single deployment.
The second is conditional logic. Approval routing, budget thresholds, jurisdiction-specific handling, and matter categorization all resolve into rules, and enterprise deployments accumulate them quickly. On one program, Basla configured more than fifty custom business rules, including compound conditional actions where several conditions have to resolve together before the platform acts. That depth is what separates a genuinely automated department from a partially automated one, a distinction explored further in why basic automation fails without conditional logic.
G2’s product listing notes that Onit supports 200+ custom workflow automation applications alongside core matter and spend management. That configurability is the platform’s central strength, and it is also why implementation effort varies so widely between clients. The same software supports a focused deployment or a multi-year enterprise program, depending entirely on how much of that surface an organization chooses to use.
How much does the eBilling piece add?
eBilling introduces an external dimension the other modules do not have, because it depends on law firms outside the organization submitting invoices correctly. That makes it as much an onboarding and coordination exercise as a configuration one.
The delivery work splits three ways: configuring billing guidelines and rejection rules inside the platform, coordinating outside counsel onboarding through the invoice intake route, and reconciling the historical spend data that has to move across. Firms submit through a vendor portal, and how that portal is set up governs how clean the first billing cycle looks. CounselGO, the SimpleLegal vendor portal, covers that side of the deployment in detail.
The third stream is routinely underestimated. Invoice history is where legacy data problems surface most visibly, because errors show up as money, a pattern set out in why messy legacy data can ruin a perfect platform build.
Where jurisdictions multiply, so does the rule set. Basla has supported matter management and eBilling programs spanning more than ten global jurisdictions, and jurisdiction count is a better predictor of eBilling effort than headcount is.
What does testing an Onit implementation involve?
Testing an ELM platform means proving that every configured path behaves correctly for every type of user who will touch it. The platform arrives working. The configuration built on top of it is what has to be proven, and that produces a much larger test surface than teams expect.
Every intake front door, every approval branch, every business rule, and every user profile combination is a scenario. On a contract lifecycle management rollout, Basla created and executed over a thousand test records to cover the configured paths.
Two categories of testing are skipped most often and cause the most damage when they are:
- Role-based testing. If workflows are only tested from an administrator view, permission gaps stay invisible until a live user sees something they should not. Role-based security testing before go-live closes those gaps while they are still cheap to fix.
- Negative testing. Confirming that the platform correctly rejects a non-compliant invoice or blocks an unauthorized approval carries the same weight as confirming the happy path.
What happens at go-live?
Go-live starts the most demanding phase of the work. The first weeks determine whether users adopt the platform or route around it, and that period needs deliberate staffing.
On one Onit rollout, Basla’s team absorbed roughly two hundred tickets in the first week after go-live. Around sixty percent were users asking how to complete a task. The remaining forty percent were genuine defects requiring a developer. The hypercare window ran for eight weeks, with every report triaged, replication steps validated, and only confirmed defects passed to the configuration team.
That filter is what protects the schedule. Without it, the developers who should be fixing real defects spend the most expensive weeks of the program answering the same navigation question repeatedly. The case for staffing that function properly is made in why launches fail without a dedicated hypercare triage desk.
Where do ELM implementations most often run into difficulty?
Almost always in configuration, data, and testing. Across the enterprise legal programs Basla has delivered, the same four causes recur across vendors and deployment sizes.
- Unmapped dependencies. Configuration that works in a sandbox behaves differently in production when the dependencies between workflows were never documented.
- Dirty legacy data. Matter and invoice history migrated without cleansing corrupts the reporting the platform was bought to provide.
- Untested role permissions. Security gaps that only appear when a real user with a real profile opens a real matter.
- Undocumented configuration. The most expensive of the four, because it surfaces months later when the team that built the rules has moved on and nobody can explain why a condition exists.
All four are delivery discipline problems, and they appear on any enterprise legal deployment where the configuration is rich enough to matter. Getting these four right is precisely what a capable delivery team is for.
How long does an Onit ELM implementation take?
There is no standard duration, and any figure quoted without scope attached is meaningless. The variables that actually move the timeline are jurisdiction count, the number of intake variations, how many modules are in scope, and the state of the data being migrated.
Onit’s own pricing varies by user licenses and modules selected, and implementation effort scales along the same axes. A single-jurisdiction matter management deployment and a multi-region program covering matters, eBilling, and contract workflows are very different undertakings on the same platform.
A more useful question than “how long” is “how many of these do we have”: how many jurisdictions, how many intake paths, how many approval variations, how many years of history to migrate.
Conclusion
An Onit ELM implementation succeeds or fails on the work that happens between contract signature and first login. The platform arrives working. What has to be built is the configuration that encodes how one specific legal department operates, and what has to be proven is that every path through that configuration behaves correctly for every user who will touch it.
Three decisions shape the outcome more than any others. Settle which Onit product the deployment runs on before configuration starts, because the OnitX, SimpleLegal, and Unity picture is actively consolidating. Scope the effort by counting jurisdictions, intake variations, modules, and years of history. Then staff the first weeks after go-live deliberately, because adoption is decided there and the cost of getting it wrong is measured in developer time that should have gone to real defects.
How Basla can help
Basla provides the delivery capability behind Onit implementations, covering business analysis, configuration support, documentation, testing coordination, and post-go-live support. The work spans legal service request, matter management, eBilling, and contract workflows, across deployments reaching more than a hundred jurisdictions.
Frequently asked questions
What is Onit ELM?
Onit ELM is an enterprise legal management platform used by in-house legal departments to manage matters, outside counsel billing, legal service requests, and workflow automation in a single connected system. It operates across OnitX for enterprise deployments, SimpleLegal for mid-market environments, and Onit Unity as the next-generation unified architecture.
What is the difference between OnitX, SimpleLegal, and Onit Unity?
OnitX is built for complex enterprise deployments and SimpleLegal for mid-market environments. Onit Unity is the next-generation architecture consolidating the two onto a single platform, which means one development roadmap and a consistent experience across deployment sizes.
How long does an Onit ELM implementation take?
There is no standard duration, and any figure quoted without scope attached is meaningless. The variables that move the timeline are jurisdiction count, the number of intake variations, how many modules are in scope, and the condition of the data being migrated.
What does Onit implementation work actually consist of?
Configuration is the largest single body of work, meaning the business rules, intake paths, and approval logic that encode how a specific legal department operates. Around that sit data preparation and migration, testing every configured path against every user profile, documentation, and post-go-live support.
Why do ELM implementations run into difficulty?
Almost always in configuration, data, and testing. The recurring causes are unmapped dependencies between workflows, legacy data migrated without cleansing, role permissions tested only from an administrator view, and configuration decisions that were never documented.
Do you need an implementation partner for Onit?
Not always, though enterprise deployments with multiple jurisdictions, languages, and approval variations carry enough configuration and testing volume that most legal departments bring in delivery capability alongside their own team, either through a consultancy or a specialist delivery provider.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*