When backing up data, the process will vary from one application to another, however, there are some general guidelines that you should always follow:
When you are creating a backup, always back up all the data that you will ever need for your project. For example, if you are doing a full migration from one system to another, always backup everything even if you don't need all the data yet.
While you might think it will allow you to work quicker, it will make the project much more complex. Because you will have a partial view of the database, then it will not be possible for you to reliably verify all the links between the client's data (How can you verify all matters are linked to valid contacts if you didn't backup contacts?).
Additionally, many of our processes and procedures expect that you have a full view of the data. If you don't, then you are making your project much more complicated and taking yourself outside our standard processes.
When Universal Migrator backs up a system, it will store all the data in the database you specify. Unless otherwise directed, always backup data into a brand new, empty database.
Each record that Universal Migrator backs up has a unique ID associated with it. If you backup to a database that is already in use, you will have conflicting IDs which will cause errors in the process.
Before talking about document backups, there are some common terms you need to know.
| Term | Usage / Meaning |
| Document | When working with enterprise and cloud-based document management systems, the human-visible name of a document often varies from the actual file path of a document. For example, a document that users refer to as "Motion for Private Process.docx" might have different versions that live at different locations. A document is a combination of metadata and one or more versions / BLOBs. By storing the metadata and blob separately, the legacy application can preserve important information such as Created/Modified dates even when the document is moved from one server to another by an IT administrator. |
| Document Metadata | Document Metadata represents the human-visible information about a document including the name of the document, the folder path it is in, its created/modified dates, and any contacts/matters it might be linked to. Metadata is often stored in a database. Document Metadata looks like this: Document #1... |
| Document Version | A document version represents an item in the edit history of a document. It is often stored in a database with a link to a document and a BLOB. Document Version metadata looks like this: Version 2 of Document #1: |
| Document BLOB | "Binary Large Object". A blob is a random file path that that has the raw contents of a file in it. By itself, a blob is not very useful because it will have a random file name and no identifiable information. A blob is usually a file path like this: \\SERVER\Docs\DF1E6A29.docx However, some systems use human-understandable blob paths like: \\Server\Docs\ABC.001\Motions\Drafts\Motion for Private Process.pdf |
In a cloud system such as Clio, NetDocuments, or Smokeball, Universal Migrator will prompt you to provide a Document Content cache path. You should select a location that has enough space to contain all documents from the system you are backing up. Ideally, this should be the DOCS folder from your Migration Workspace and not on a file share, network location, or USB Drive. Also, please note that each document will be temporarily staged to the local TEMP directory before being moved to its final location.
When backing up data from a cloud app, always have Universal Migrator cache the documents to the folder above.