A matter management implementation turns a selected platform into a working system for one specific legal department, covering configuration, data migration, integration, testing, and the support model for the weeks after launch. A product demo shows a configured environment holding clean data, and every implementation begins with neither. This article covers the work that sits between those two states, and how to scope it before the timeline is committed.
What does a matter management implementation actually involve?
A matter management implementation involves five workstreams that run in parallel more often than in sequence, and the effort concentrates in places the demo never touches.
- Configuration. Matter types, intake forms, workflow rules, approval routing, security profiles, and reporting.
- Data migration. Existing matters, historical records, documents, and outside counsel details.
- Integration. Connections to document management, finance systems, eBilling, and identity providers.
- Testing. Every configured path validated against every user profile in scope.
- Adoption. Training, quick reference material, and the support model for the first weeks.
Configuration and migration consume the majority of the effort on most programs. Both are invisible during a demo, because the environment on screen already has them completed.
Why does a demo environment mislead on scope?
A demo environment misleads because it shows the destination while hiding the journey. The matter types are already defined, the workflow rules already built, the data already clean, and the integrations already connected.
Three specific gaps recur.
- The taxonomy is done. A demo shows matter types someone already agreed. Yours requires workshops, disagreement, and a decision nobody wants to own.
- The data is clean. A demo dataset has consistent naming and complete fields. Your legacy estate has neither.
- The integrations exist. A demo shows a connected environment. Yours requires design, build, and testing per connection.
Vendor return-on-investment material carries a related caution. Commissioned economic impact studies typically model a composite organization built from a small number of customer interviews, which produces a figure describing an average that resembles no actual company. Treat those numbers as an indication of what the platform makes possible, and build your own business case from your own baseline.
How much configuration does a matter management implementation need?
The build needs configuration proportionate to how differently the department works from the platform’s defaults, and enterprise legal departments differ considerably.
Volume accumulates faster than teams expect. On one legal technology program, Basla configured more than fifty custom business rules, including compound conditional actions where several conditions resolve together before the platform acts. On a legal service request implementation, Basla built eight separate intake front doors covering language and country variations within a single deployment.
Four variables predict configuration effort more reliably than headcount. The number of jurisdictions in scope, the number of languages, how many matter types the taxonomy carries, and how many approval variations exist across business units. Counting these during scoping produces a far better estimate than asking how long implementations usually take.
What does matter data migration involve?
Matter data migration involves extracting existing records, mapping them to the new structure, cleansing them, then loading and validating. The cleansing stage determines whether the reporting works on day one.
Legacy matter estates carry predictable problems: inconsistent outside counsel naming, matters open for years with no activity, missing business unit or cost center values, documents stored outside any matter, and matter types from a taxonomy nobody uses anymore. Each becomes a decision about whether to migrate, remediate, archive, or leave behind.
Settle those decisions before extraction begins, since making them mid-migration is what causes overruns. Matter history moved without cleansing produces analytics nobody trusts, a pattern covered in why messy legacy data can ruin a perfect platform build.
How should integrations be scoped?
Integrations should be scoped individually, because each carries its own design, build, testing, and failure modes. A platform advertising an integration catalog is describing capability, and capability still needs implementing.
Four connections appear on most enterprise matter management programs. Document management, so matter documents live in one place. Identity and single sign-on, which also determines what gets prepopulated on intake forms. Finance or ERP, so approved invoices reach accounts payable without rekeying. And eBilling, where invoices attach to matters and accruals report against budgets.
Each integration needs testing under real conditions, since a connection working in isolation behaves differently once live volumes and real permission rules apply. That principle is covered in the hidden dangers of packaging workflows for production.
How much testing does a matter management implementation require?
The build requires testing proportionate to the configuration built, which produces a larger test surface than most plans allow. The platform arrives working, and what has to be proven is everything configured on top of it.
Every matter type, approval branch, security profile, and integration point is a scenario. On a contract lifecycle management rollout, Basla created and executed over a thousand test records to cover the configured paths, and matter management deployments generate comparable volumes once jurisdictions and matter types multiply.
Security testing carries particular weight, because matter records hold privileged and commercially sensitive material and access varies by matter, practice area, and business unit. Testing only from an administrator view leaves permission gaps invisible, as covered in why skipping role-based security testing breaks go-lives.
What questions should you ask about implementation scope?
The most useful scoping questions expose effort the demo concealed, and they belong in the conversation before the timeline is agreed. Six produce the most useful answers.
- Who configures the matter taxonomy, and how many workshops does that take?
- What data cleansing is included, and what is expected from us?
- Which integrations are configuration, and which require development?
- Who writes the test scripts, and who executes them?
- What documentation is delivered, and does it explain why rules were built as they were?
- What support model covers the first month after go-live?
The documentation question separates thorough implementations from quick ones. Configuration delivered without recorded reasoning becomes unmaintainable when the build team rolls off, as covered in why undocumented configuration becomes technical debt.
What happens in the weeks after a matter management go-live?
The weeks after go-live generate a predictable volume of questions, because lawyers meet the system at the moment they need it to work. Staffing that period keeps the configuration team available for genuine defects.
On one enterprise legal platform rollout, Basla’s delivery team handled roughly two hundred tickets in the first week after go-live. Around sixty percent were users asking how to complete a task, and the balance were genuine defects requiring a developer. The hypercare window ran for eight weeks with every report triaged before anything reached the configuration team, a model described in why launches fail without a dedicated hypercare triage desk.
Spend control deserves attention in the same period, since matter budgets and invoice rules only deliver value once they operate. Survey research from LegalBillReview.com and In-House Connect found that nearly 60 percent of legal departments have no formal outside counsel guidelines, and among those with guidelines, 87 percent described enforcement as light. A platform configured to apply those rules automatically closes that gap, and configuring it is implementation work. The need is wide, since a 2025 survey of in-house teams found 76 percent still run matter processes manually.
Conclusion
A matter management implementation succeeds when the scoping is honest about the work the demo did not show. The platform is proven, and what remains is the configuration, data, integration, and testing that make it fit one department.
Four practices produce a defensible plan. Scope by counting jurisdictions, languages, matter types, and approval variations, which predicts effort far better than headcount does. Settle the taxonomy through workshops before configuration starts, since it governs every report the department will run. Treat data cleansing as its own workstream with an owner, because analytics built on inconsistent history convince nobody. And ask directly who writes the test scripts, who documents the configuration, and who staffs the first month, since those three answers reveal how much of the work is actually included.
How Basla can help
Basla provides delivery teams for enterprise legal management and eBilling software implementation, covering legal technology consulting, business analysis, configuration support, data migration support, testing coordination, documentation, and post-go-live support. Basla has supported matter management and eBilling programs spanning more than ten global jurisdictions, with hands-on experience across Onit matter management, eBilling, legal service request, and contract workflows.
Frequently asked questions
What does a matter management implementation involve?
A matter management implementation involves five workstreams: configuring matter types, forms, workflow and security, migrating existing matter and document data, integrating with document management, finance, eBilling and identity systems, testing every configured path against every user profile, and running the adoption and support program.
How long does a matter management implementation take?
A matter management implementation takes as long as its scope dictates, and the platform matters less than the variables around it. The variables that move the timeline are the number of jurisdictions and languages in scope, how many matter types the taxonomy carries, how many approval variations exist across business units, and the volume and condition of the data being migrated.
What does a product demo not show about implementation?
A demo shows a completed environment, which conceals three things: the taxonomy has already been agreed, the data is already clean, and the integrations are already connected. Each of those represents substantial work on a real program.
How reliable are vendor ROI studies for matter management platforms?
Commissioned economic impact studies typically model a composite organization assembled from a small number of customer interviews, so the resulting figure describes an average that matches no actual company. Treat them as an indication of what a platform makes possible and build the business case from your own baseline.
What should be asked about implementation scope before signing?
The six questions worth asking cover who configures the taxonomy and how many workshops that requires, what data cleansing is included, which integrations need development, who writes and executes test scripts, what documentation is delivered, and what support model covers the first month after go-live.
Which part of a matter management implementation is most underestimated?
Data migration and configuration together consume most of the effort, and both are invisible during a demo. Legacy matter estates carry inconsistent outside counsel naming, missing business unit values, matters open for years without activity, and documents stored outside any matter, and each requires a decision before extraction begins.
*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.*