Migrating to OCM
Nobody switches case management systems because it’s fun.
They switch because something is wrong and the migration is the price. So the migration is the part we have spent the most time getting right, and the part we will be most specific with you about.
The sequence
Six steps, in this order, every time
The order is the method. Every migration that has gone badly in this field went badly because someone committed to a cutover date before staff had worked in the data.
- 1
Extract it
We pull a complete extract from your current system through an authorized connection or a vendor export. Nothing is written anywhere until you have seen what came out.
- 2
Map it
Your fields, codes and vocabularies are mapped against an OCM configuration, with your staff in the room. This is the step programs want to skip and the step that decides whether the migration is any good.
- 3
Load it
A full OCM instance is provisioned for you and loaded with your real data. It is yours to break. Outbound email and text messaging are disabled on it so nothing reaches a client by accident.
- 4
Work it
Your advocates open their own matters, run their own reports, and tell us what is wrong. Findings go back into the mapping and the instance is reloaded. Most programs go around this loop more than once, and should.
- 5
Cut it
On a date you choose, we take a final extract, load it, and switch. Cutovers run outside business hours because a program that cannot open a case at 10am has a bad day regardless of whose fault it is.
- 6
Keep it
Your previous system stays available read-only for as long as you want it, so nobody is betting a closed file on our first week.
Migration walkthrough
From source mapping to an ordinary working matter
A complete synthetic migration in the demo system: mapping, preview, live progress, reconciliation, the imported case narrative, and its document.
Migration Wizard
Real product footage · Captions included
Where you are coming from
The path for each source
Pika and earlier OCM migrations are included with hosted OCM. JusticeServer, LegalServer and other sources are scoped and quoted before work begins.
JusticeServer
The automated path is built end to end. We review the size and shape of your Salesforce data before quoting the migration.
Scoped and priced per program.
Pika and earlier OCM
The path we have run most often, including full version upgrades with custom reports, overlays and org-specific configuration carried across.
Included at no charge. Multiple programs migrated in the last year.
LegalServer
A supported migration path. We review the program's configuration and data before setting the scope and price.
Scoped and priced per program.
Spreadsheets and CSV
Programs coming off Access databases, shared drives and spreadsheet trackers. Messier than a vendor extract, and completely doable.
Scoped per program.
Something else
Other commercial systems, homegrown applications, and combinations of the above. Tell us what you have and we will tell you honestly whether we have done it before.
Scoped per program.
What we check
The things a migration quietly drops
Every item here is something we have watched go wrong on a real cutover, in this field, and now check for on every one.
Custom reports
The reports your program wrote for its own funders are the first thing a migration silently drops, because they are not in the vendor's standard set. We inventory them before cutover, not after a grant report is due.
Menu vocabularies
Problem codes, funding codes, outcome codes and priority codes are your program's language. They come across as they are rather than being flattened into somebody's defaults.
Case tabs and screens
A tab your program does not use gets disabled, not deleted, so the data behind it survives the move.
Assignments and staff flags
Co-counsel and supervising attorney assignments depend on staff records being flagged correctly. We check these, because when they are wrong it looks exactly like the migration lost your assignments.
Documents
Document storage moves with the database. A migration that brings the case record but leaves the paper behind has not moved anything.
Open sessions and history
Login history and audit records come across where the source system has them, so your compliance history does not restart at zero.
Questions
What programs ask us before they commit
- How long does it take?
- For a well-supported path, a few weeks from extract to cutover, most of which is your staff testing rather than us loading data. A messier source, or a program that wants to reconfigure while it migrates, takes longer. We would rather quote you a real range after seeing an extract than a reassuring number now.
- What does it cost?
- Migration from Pika or an earlier version of OCM is included. Migrations from JusticeServer, LegalServer, spreadsheets and other systems are scoped and quoted before we start, with a fixed price rather than an hourly meter.
- Do we have to stop working during the cutover?
- Briefly. The final extract and load happen outside business hours, and your staff sign into the new system the next morning. Nobody is asked to run two systems in parallel for a month.
- What if the migration is bad?
- You find out during step 4, in staging, on your own matters, before any date is committed. That is the entire reason step 4 exists. If the data does not come across correctly, there is nothing to roll back because you have not switched.
Send us an extract and we will show you your own data in OCM
It is a more useful evaluation than any demo, and it is the same first step we would take if you signed tomorrow.