Most legal migrations do not fail on the open matters. They fail on the closed ones, the trust ledger, the documents nobody catalogued, and the twelve years of notes an attorney will need on a Tuesday morning. Twopir Consulting profiles, maps, loads and reconciles legal data into CaseCloud — in rehearsed passes, with a reversible plan.
Trusted by 500+ organizations — including law firms, corporate legal teams and legal technology companies building their operations on Salesforce with Twopir Consulting.
Built for Legal Operations
Every one of these is a scoping failure, not a technical one — and every one of them shows up after the invoice for the quick migration has been paid. All are avoidable at profiling stage.
The quickest migration moves active work and leaves history behind. Two months later the firm is still paying for the legacy system because closed matters, ledgers and documents only live there — and nobody budgeted for round two.
Field mapping built from a schema export rather than the actual data meets duplicate clients, blank matter types, dates in three formats and free-text status values on load day. That is the point at which timelines slip.
Time entries, invoices, payments and trust balances migrate as records but not as a balanced ledger. Finance cannot sign off, so the firm keeps the old system authoritative for money — which means it keeps it, period.
Matter records arrive without the documents attached to them, or with links pointing at a file share that is about to be decommissioned. Attorneys lose trust in the new system on day one and never fully return.
A migration run once, in production, on a Friday, is not a plan. Without staged rehearsal passes and reconciliation after each one, nobody knows what will break until it is breaking.
Without a written reconciliation standard — row counts, control totals, spot checks by practice area — sign-off becomes an argument. Migrations stall in that argument for weeks.
A CaseCloud migration moves a firm's legal record — matters, clients, contacts, documents, time, invoices, ledgers and notes — out of a legacy system and into Mitratech CaseCloud on the Salesforce platform, with a documented map and a reconciliation standard. It is a data engineering project with legal consequences, not a data export followed by an import.
Because CaseCloud is a Salesforce application, the target is not a closed product database — it is an org with an object model, sharing rules, validation and automation that all react to inbound data. A load that ignores automation order fires thousands of workflow actions on import. A load that ignores sharing produces matters nobody can see. These are Salesforce problems, and they are the reason legal migrations are rarely just a data job.
Twopir Consulting migrates into CaseCloud from practice-management platforms, legacy AdvoLogix orgs, spreadsheets, file shares and home-grown systems. We are a Salesforce implementation partner, not a Mitratech reseller — the vendor's CaseCloud documentation governs the product; this page is about getting a firm's real history into it intact. Migration is usually one workstream inside a wider CaseCloud implementation, and it is also the single most common reason firms come to us mid-programme.
Three legitimate strategies with different costs and different consequences. The wrong one is chosen by default when nobody asks the question.
| Approach | What it means | When it fits | Trade-off |
|---|---|---|---|
| Lift | Move the data as-is into the equivalent CaseCloud structure, with minimal transformation. | The legacy structure is sound and the firm wants continuity above all. | Fastest and cheapest. Carries the legacy model's flaws forward with it. |
| Remap | Redesign the matter model in CaseCloud first, then transform legacy data into the new shape — merging duplicates, standardising matter types, normalising dates and statuses. | The legacy model is the reason the firm is moving, or practice areas have changed. | The common choice. More discovery and more mapping work, and the only route that leaves clean data behind. |
| Migrate & archive | Bring active matters and a defined history window into CaseCloud; move the remainder to a searchable archive that satisfies retention without carrying dead weight. | Very large closed-matter volumes, or retention obligations that outlive business need. | Keeps the production org fast and licence costs sane. Needs a written retention position signed off by the firm. |
A migration is only finished when the firm's own people can confirm the record is complete. Everything here is built to produce that evidence.
We profile the real data before mapping a single field — volumes, completeness, duplicates, value distributions and orphaned records — and give you a written data-quality report with the decisions it forces.
A field-level map, reviewed and signed off by the firm, covering every source field: migrate, transform, default or deliberately drop — with the reason recorded for each.
The part most plans underestimate. Documents move with their matter association and metadata intact, into CaseCloud or the firm's document management system — not into a folder nobody can search.
Time entries, invoices, payments, write-offs and trust movements migrated so the ledger balances — because finance signing off is what actually ends a migration.
Every pass produces evidence: row counts, control totals, and structured spot checks by practice area. Sign-off is against a standard agreed up front, not a conversation on cutover weekend.
A rehearsed cutover with a rollback position, the legacy system left read-only rather than switched off, and a decommissioning plan that only executes once the firm is genuinely running on CaseCloud.
Five phases. The rehearsal phase is the one firms try to cut, and it is the one that determines whether cutover weekend is uneventful.
We inventory every source that holds legal record — including the spreadsheets and shared drives nobody lists — profile the data, and report on quality, volume and the decisions the firm needs to make before mapping.
The CaseCloud matter model is confirmed first, because you cannot map into a shape that is not agreed. Then the field-level map is written, reviewed with the people who use the data, and signed off.
We build the migration in a sandbox and run it end to end — repeatedly. Each pass produces reconciliation output, each exception is logged and resolved, and the run time is measured so the cutover window is a known quantity.
The firm validates against the agreed acceptance criteria: control totals for finance, spot checks by practice area, document spot-retrieval. Nothing proceeds to cutover on an unsigned reconciliation.
Freeze, final delta load, reconcile, go live — with the legacy system read-only behind us. We stay through the first weeks of real use, when the questions that no test finds actually surface.
The official system is never the whole picture. Discovery finds the trackers, diaries and shared drives too — because anything left behind becomes a shadow system the week after go-live.
Cloud practice-management platforms are the commonest source. Matters, contacts, notes, documents, time and billing history are extracted through their APIs or exports, mapped to the CaseCloud model, and reconciled — with the legacy platform kept read-only through stabilisation rather than cancelled at cutover.
Firms already on AdvoLogix are running what is now CaseCloud, so this is rarely a migration in the usual sense. It is more often consolidation of multiple orgs after a merger, or a re-architecture of a matter model that no longer fits — same discipline, different starting point.
Documents move to the system that will own them long term, with matter association and metadata preserved. Where the firm keeps its DMS, CaseCloud holds the matter record and the link; where it does not, documents land in the platform against the matter.
Invoice, payment and trust history is migrated and then reconciled to control totals from the accounting system, so the finance team can confirm the two agree before the old ledger stops being authoritative.
Almost every firm has a matter list, a referral tracker or a limitation diary living outside the official system. We find these in discovery and migrate them properly rather than letting them survive as shadow systems after go-live.
Not everything should migrate. Where a system is staying, the answer is an integration rather than a data move — see CaseCloud integration services for how those connections are designed and which direction data travels.
These outcomes come from Salesforce legal-operations engagements delivered by the same team, on the same platform CaseCloud runs on. Each figure is scoped to the engagement it was measured in — follow the case study for the full context.
Twopir provided Salesforce customisation and integration services to help us build a robust, compliant, and scalable legal operations platform — connecting case management, document processing, and financial systems into one unified workflow. The result was transformative for how we run case-to-cash operations.
Streamlining case-to-cash operations with Salesforce, AWS and QuickBooks.
The difference between a migration that finishes and one that drags for months is almost never tooling. It is whether anyone agreed, in writing, what correct looks like.
Nobody can scope a legal migration accurately from a schema. We profile the actual data first and tell you what it contains — including the parts that will cost more than you expected, before you sign rather than after.
CaseCloud sits on Salesforce, so a load interacts with automation, validation and sharing. Knowing how to stage a load around those is Salesforce work, and it is the difference between a clean import and a hundred thousand unintended automation firings.
Every pass produces reconciliation evidence against acceptance criteria agreed in writing beforehand. That is what lets a finance team sign off, and sign-off is what actually ends a migration.
Staged passes in a sandbox, measured run times, a written runbook and a rollback position. Cutover weekend should hold no surprises, because every step has already been performed.
Personal injury, family law and corporate practices, from cloud practice-management tools and from systems with no export path worth the name. The failure modes are familiar to us.
Full history is achievable and is usually the right call — the firms that migrate open matters only tend to be back within a year, still paying for the legacy system because closed matters and ledgers live there. The genuine decision is between migrating everything into the production org and migrating a defined window while moving older closed matters to a searchable archive. That choice is driven by volume, retention obligations and how often historical matters are actually retrieved, and we scope it during profiling.
We extract through the platform's API or export facility, profile the real data, and map it field by field to the CaseCloud matter model — which is confirmed before mapping starts. The migration is then built and rehearsed in a sandbox with reconciliation after every pass, validated by the firm against written acceptance criteria, and only then run for real. The legacy platform stays read-only through stabilisation rather than being cancelled at cutover.
No. AdvoLogix was renamed Mitratech CaseCloud in November 2024 — if you were on AdvoLogix, you are already on the product now called CaseCloud, and the rebrand did not require any data movement. The migration work we do for existing AdvoLogix firms is different: consolidating multiple orgs after a merger, or re-architecting a matter model that no longer matches how the firm works.
The honest answer is that it is driven by four things: how many source systems hold record, how clean the data is, whether documents and financial history are in scope, and how many rehearsal passes the firm's risk appetite calls for. Data volume matters far less than data quality — a large clean dataset is faster than a small chaotic one. We profile first and give a scoped estimate against that evidence rather than a number before we have seen the data.
They migrate with their matter association and metadata intact. Where the firm uses a document management system such as iManage or SharePoint, documents are routed there and CaseCloud holds the matter record and the link; where there is no DMS, they land in the platform against the matter. Either way, spot-retrieval of documents by practice area is part of the acceptance criteria — the point is that an attorney can find the file, not that a row count matched.
Against acceptance criteria written and agreed before the first load: row counts by object, control totals for financial data reconciled against the accounting system, and structured spot checks by practice area performed by the firm's own people. Every pass produces a reconciliation pack and an exception log. Nothing goes to cutover on an unsigned reconciliation, which is what stops sign-off becoming an argument.
Yes, and it is a common way firms reach us. We assess what actually landed against what should have, quantify the gap, and give you a written position on whether to remediate in place or reload cleanly — with the trade-offs of each. Partial migrations are recoverable; the expensive mistake is continuing to build on top of one without knowing what is missing.
Twopir Consulting migrates legal record into Mitratech CaseCloud on Salesforce — for growing and mid-market companies and enterprise legal teams that need history, documents and ledgers to arrive intact.
Speak with a team that has moved legal data at volume
