Universal Migrator has three types of logs that you can use to investigate the results of a data extraction or injection.

1.  Output Logs

Output logs are stored in:

%LocalAppData%\Universal Migrator\__Diagnostics\Logs

and captures user-visible text that is shown in the application.  When ever you see a "console" window like the following:

the contents of it are being written to one of the logs in that directory.

 

2.  Extraction Logs

When you are extracting data from a source system, there are two types of logs that may be generated:  Warning Logs and Raw_Content.

2.1  Warning Logs

Occasionally Universal Migrator may encounter invalid or unexpected data when extracting from a legacy system.  When that happens, records will be saved into the __B_LOGS table in the Universal Database:

This table can be queried so that you can see any extraction errors or warnings.

2.2  Raw_Content

When extracting from web-based system, Universal Migrator will preserve a raw copy of the content that it extracted in the Final_Raw_Content column of every table.  The format of this content is system specific and will be a copy of the data as it originated out of the source system.  It might look something like this:

The purpose of this data is to help you better understand the data that Universal Migrator is processing and enable you to dialog with your customers and our engineers better.  For example, if you were looking at a document, you might wonder if it is truly accurate that the document is on version 50 but when you look at the Raw_Content, you can see that the originating system identifies the current version as version 50.

2.3  Post-Extraction Best Practices

Generally speaking, after performing an extraction, you should run the Table Record Count query and ensure that you don't have any Warning Logs.

3.  Injection Logs

When you are injecting data into a destination system, there are two types of logs that get generated: Result Logs and Status Logs.  To view these logs, simply view the specified columns on the table you want to inspect using a query like:

SELECT * FROM __M_Documents_Digital_Files

3.1  Result Logs

Result Logs are stored in the following columns of every table.

Column	Usage
Result_Id	This contains the internal primary key of a record that has successfully been injected into the destination system.  For example, if a document has been uploaded to a web-based system, this might contain a number or GUID value.
Result_ReferenceCode	This contains the human visible primary key of the record.  In most systems, this matches the Result_Id but occasionally you may see that these differ.
Result_Raw_Content	This contains the raw content of the object that was returned by the destination system.  You can view this to better understand how the final data was pushed into the destination system.

 

3.2  Status Logs

Status logs are stored in the following columns of every table:

Column	Usage
Status_ReferenceCode	This contains a reference code (error code) for any issue that the record encountered when pushing into the destination system.
Status_Subject	This contains an expanded error message for any issue that the record encountered when pushing into the destination system.
Status_Description	This contains an expansive log that details all the steps that Universal Migrator took when processing that record (successful or not).

 

When reviewing status logs, keep in mind that an error does not necessarily mean that an action is required on your part.

For example, if you tell Universal Migrator:

Upload C:\MyDocument.pdf to Matter ABC.001

You might get an error that says:

Error: C:\MyDocument.pdf does not exist.

Does that document exist at a different location or does it not exist at all?  You should investigate and determine the appropriate next steps.

 

3.3.  Post-Injection Best Practices

Generally speaking, after performing an extraction, you should run the Table Record Count query and ensure that all of the tables you expect to be complete are indicated as Complete.  For any tables that are not 100% success, you should likely run the following query to see all records that did not process successfully:

SELECT * FROM REPLACE_WITH_A_TABLE_NAME WHERE Result_Id = ''