Table of Contents
The part of a new DMS that firm administrators worry about most is the move. Years of client folders sit on the S: drive, much of the matter record lives in personal Outlook folders, and nobody wants to lose a file’s history on the way over.
A document management system implementation comes down to a few decisions made early, a migration that keeps dates and versions intact, and a short cutover with a fallback. Decide how matters are numbered and who owns the structure, test-migrate a handful of matters, then switch over a weekend with the old server kept read-only.
This plan for implementing a document management system is for firms of roughly 5 to 50 users. You’ve picked your law firm document management software and need to get there without losing a week of billable time. If your team is worn out from software changes, a clear plan keeps this one orderly.
When we move a firm off a file server, the same handful of decisions shape the whole migration.
A Law Firm DMS Implementation Plan, Phase by Phase
A law firm DMS implementation runs in six phases: decide and scope, prepare the data, configure the system, migrate files and email, cut over, and settle in over the first 30 days. Most of the work happens before the cutover weekend, which is why the weekend itself can stay short.
Here’s who owns each phase and when it happens.
Each phase has its own section below. The decisions come first, then moving files off a server, legacy email, the cutover weekend, and the first month after go-live.
Before You Start: The Decisions That Shape the Whole Implementation
Everyone expects to map the data before a DMS migration; the steps firms skip are a communication plan from leadership and a clear schedule covering training, data conversion, and the date the old system goes read-only.
Tell everyone at your firm what’s changing, when, and why before anyone touches a file. Then settle the four decisions below, since each one gets harder to change once documents start moving.
Still weighing systems? The document management software comparison chart lines up features side by side.
Matter Numbering and Naming Conventions
Use your practice management system’s matter numbers in the DMS, so a matter number means the same thing in both places. If your firm doesn’t number matters yet, define the scheme once, before migration, and apply it everywhere.
Keep naming conventions light. Strict schemes, like every file named description_matter_client and every matter folder built from the same fixed subfolders, grew up on shared drives because a folder was the only structure available. A written naming SOP can be a good system and still be impossible to enforce across a whole firm over years.
A DMS that files everything under client and matter does most of what those schemes try to do. Firm administrators can turn on Mandatory Profiling in LexWorkplace to require a document type, status, or tags before a document is saved, so documents stay findable even when their file names don’t help.
Who Owns the Structure
Name one person to own the structure, usually the firm administrator or office manager. That person decides where things go during migration and answers the “where does this file go?” questions after go-live.
Without an owner, every attorney improvises. The structure drifts back toward the S: drive, one exception at a time.
What Moves and What Gets Archived
Before data prep starts, decide which matters move as active, which move as closed or archived, and what stays behind. Closed matters need to stay searchable, and that’s all most of them need.
The cleanup guidance in the next section covers how far to take it.
Permissions and Connected Systems
Set default matter permissions and any restricted matters during setup, before documents land in matters where the wrong people can open them. The security side of legal document management covers ethical walls and access control in more depth.
Confirm what connects before you set the schedule. If your practice management runs in Clio, ask how matters sync between the two systems; if billing runs in separate accounting software such as QuickBooks, ask whether there’s a connection at all or whether matter numbers are the only link.
How to Move Files off a Server or Shared Drive Without Losing History
Moving files off a server without losing history means carrying over each file’s created and modified dates, its existing versions, and its permissions, while re-filing it under the right client and matter. A planned migration handles all four, and a test run on a few matters proves it before the full move.
Four steps get your files there intact.
Mapping Folders to Clients and Matters
Each client folder on the S: drive maps to a client in the DMS, and each subfolder that represents a piece of work maps to a matter. Most server trees follow that pattern loosely, with some exceptions.
The exceptions need a decision from the taxonomy owner:
Decide each one before the move so nothing lands in a matter by default.
Keeping Dates and Version History
Dates and versions only survive a migration if the migration is built to carry them, so confirm it in writing before the move. Ask three questions:
LexWorkplace migrations preserve folder structure and metadata, and once files are in LexWorkplace, version history is retained forever. Scanned PDFs are a related gap: Integrated OCR makes migrated paper searchable, so years of scans stop being images nobody can find.
Clean Up First, but Don’t Overdo It
Clear out the obvious junk before the move, like duplicate “FINAL_v2_REVISED” copies and the folder that turns out to be a full backup of someone’s old PC. Leave closed matters alone beyond that.
Your team’s time is better spent on the active matters people will open on Monday.
Test a Few Matters Before the Full Run
Migrate a few representative matters first:
Check that dates, versions, and email came through, then fix the mapping before moving everything.
The same approach works if your files live in Dropbox, Box, or OneDrive rather than on a server, and migrating from cloud storage follows the same client-and-matter mapping.
If you’re still deciding whether the move is worth it, weighing the benefits of a DMS against your current setup makes the decision clearer.
A clean test run is the best evidence the full migration will go the same way.
What to Do with Legacy Email
Legacy email should move with the matter it belongs to, because the client approvals, negotiations, and deadline changes in a matter record usually live in individual inboxes and old PST files. Email is often the most scattered part of the client file, spread across personal Outlook folders, PSTs, and departed attorneys’ mailboxes.
Picture the associate who left two years ago. Their PST holds the client’s sign-off on a settlement term, and nobody has opened it since they left. If that email stays out of the migration, the matter record in your new DMS is incomplete from day one.
Settle these points before the email moves:
With those settled, legacy email arrives as part of the matter record.
After go-live, filing happens from inside Outlook. In LexWorkplace, email management includes LexWorkplace for Outlook and Email Smart-File, which help file each message to the right matter, and Email Duplicate Detection, which flags messages already saved so the same thread doesn’t get filed twice.
The day-to-day habits are covered in filing Outlook email to matters. How long to keep that email is covered in email retention and archiving.
The Cutover: Planning the Go-Live Weekend
A DMS cutover is the planned switch from the old system to the new one, and for a small or midsize firm it can fit inside a weekend with the old server kept read-only as a fallback. Your firm stops saving to the old system on Friday and starts work in the new one on Monday.
The graphic shows the sequence, and three judgment calls around it decide whether Monday goes smoothly.
Set the freeze time and announce it. The firm administrator picks the moment saving to the old server stops, usually end of day Friday, and tells everyone in advance. Anything saved after the freeze won’t be in the final sync.
Decide what the spot-check covers. Before Monday, the taxonomy owner opens a sample of active matters and confirms documents, dates, and email arrived where they belong.
Plan for something missing Monday morning. Someone will look for a file and not find it. Because the old server stays read-only, they can find it there, and the migration team can move it into the right matter the same day.
That read-only fallback is also the answer to running both systems in parallel. Months of parallel running split your firm’s work across two places and teach people that the old system is still an option. A short read-only window lets people check the old files without giving them a second place to save.
The First 30 Days After Go-Live
The first 30 days after go-live are when a new DMS either becomes the firm’s habit or loses to people saving on their desktops again, so they need a plan of their own. Training on day one gets people started, and the first month is what makes it stick.
Four things keep the new structure in place:
A short check-in at the end of the month tells you whether the structure is holding or needs a tweak.
What Goes Wrong in a DMS Implementation (and How to Avoid It)
The mistakes that derail a DMS implementation are predictable, and each one traces back to a decision that wasn’t made before the migration started. Here’s what each mistake costs and how to prevent it.
Most of these show up the same way. An associate keeps saving to the S: drive because nobody made it read-only, or a partner’s PST never gets imported because email wasn’t in scope. Both are decisions, and both are cheaper to make before the move than to fix after it.
Why Waiting Makes Migration Harder
Waiting makes a DMS migration harder because the document and email footprint keeps growing even when headcount doesn’t, and a move planned on your timeline is easier than one forced by a vendor change or a failure. Every year adds matters, email, and scans to sort through.
The vendor side can change on you too. In May 2026, Bloomberg Law reported that legal tech is heading into a long-anticipated wave of consolidation.
When a vendor is acquired, pricing, terms, or the product roadmap can change on a timeline your firm didn’t choose. Older on-premises systems also stop getting security updates once their vendors end support for them.
Meanwhile, the workarounds cost billable time:
A migration you plan now lets you pick the timing, the scope, and the weekend, while one forced by a vendor shutdown or a server failure picks them for you.
How LexWorkplace Handles Implementation and Migration
LexWorkplace handles implementation and migration in-house: its onboarding team reviews your current documents and email, moves your documents into the right matters, and trains your team. The onboarding team works for LexWorkplace, so there’s no outside consultant between your firm and the people doing the work.
Here’s what the process includes:
If your firm would rather hand off the move than run it, that’s the job the onboarding team is there to do.
A Good Implementation Is Mostly Decided Before the Weekend
Most of a document management system implementation happens before anyone opens the new system. Number your matters, keep naming rules light, name one person to own the structure, and decide what moves and what gets archived.
Then test a few matters, bring the email along, and plan a cutover short enough to fit in a weekend, with the old server kept read-only. Whether you run the move yourself or have it handled for you, start with an honest inventory of where your documents and email live today.
WHAT’S NEXT
