There is a lot more involved in migrations than moving or copying data from one location to another. Involvement depends upon the kind of data you migrate or if you want a lot more information (e.g. what is the new URL of file X, what information was read for the source, which attachments were too big, etc.). In many cases, this information is not only interesting to the customer, but can also be critical to audit reporting. In most scenarios that information is only accessible through support services or in a text-based log file stored in some hidden folder. These limitations make it very hard to provide up-to-date information and reporting to customers and end users.
MigrationWiz is enabling more transparency and information about your migrations, and it’s fully integrated into the standard offering. MigrationWiz now stores all information about the migration, in a central location. Through a SQL Azure database, MigrationWiz will log all the information that you require. You determine what information you want. Start by creating a SQL Azure database (read the complete step by step guide here). In the advanced option of your MigrationWiz project, you define the following attributes:
- Severity: These are in order of ascending value: Fatal, Error, Warning, Information, Trace
- Note: The severity levels with greater value will include logs of those from lower values (i.e. severity level warning will include logs with warning, error and fatal levels)
- Buffer size: The number of items to hold in the log queue before flushing to the database.
- Note: The queue will flush either when it reaches the buffer size, or every minute – whichever comes first.
- Server: Server name
- Database: Database name that you built to store the audit log table
- Connection time out
- Table name: The table and schema will be generated by the audit log service, but you must specify the name that you wish to give to the table.
The created table will be filled in with all the information you chose to log during the migration. That table itself can be used in many scenarios like reporting, but the use of a SQL database allows a lot of more. You can use the table as a part of a BI model, PowerView report or even a PowerBI setup. This model allows our partners, customers and end users to benefit the most from the collected data and provides additional services to make your data migration as smooth and transparent as possible.