Dear AA11,
Migration is done when you choose to change indexers for the entire device. What I mean is you cannot do it for the largest share to balance the load, you do it for the filer device and all of its' shares. Depending on the device it could be a very large transfer.
The process is to mark the device and all of the associated shares as migrating and keep the in progress status until all of the indexes, pending data base transactions and backlog are transferred. We actually stop updating the indices maintaining the current status until all are transferred and there is a duplicate copy in the target of the source's data, including new and incoming data. You need a period of no I/O with high network bandwidth availability to complete the transfer as each new stream in would also have to be a stream to target and this makes the bandwidth 50% as effective for the duration on a very busy box.
Logically starting a transfer during a downtime window or entering a weekend is best but you are in the situation you are in already. I would not recommend cancelling only to start over as the cancel resets the status, opens the databases for updates and starts indexing on the next job cycle making the data on target redundant and irrelevant so it is deleted and you are starting over with any subsequent migration request.
As each share location is successfully moved the data is sent to both the target and source until 100% of all shares are completed. In the migration databases the share is marked as successful and the freed thread is move to the next consecutive share for migration. The status of the migration job will remain in progress with some shares completed successfully, others in progress and the remainder in waiting pending status until completion.
Once 100% of shares are migrated, all pending transactions associated to those shares are in the target inbox and all new data is being sent to the target the status will move to the completed phase and the configuration database will be updated for the device's association, all shares and their path and file objects to reflect the location on the new indexer making the source data outdated and redundant. On the next job cycle for indexing the device's shares will be marked for index and the block to indexing removed. This will cause the old location which is no longer valid to delete all the databases, and pending files freeing space on the old indexer. The new indexer will start processing the shares associated to the device and play all the transactions into their appropriate database clearing the backlog on the new indexer. These actions should remove the excess files in the inbox and remove the notification on the processing times for the backlog or at least put it back into an expected range. One reason for suggesting and initiating a migration is to lower the amount of backlog processing times, another is to improve response times for reporting and rendering the GUI data.
Going forward you have a few choices and perhaps I can put them into a suggested list to guide you in your decision making.
1) let it run over the weekend when you have less I/O from the share's client computers and it may complete for you
2) call into Veritas support who will direct you to send the appropriate files and databases for a 'check' of your current status
3) Cancel and NEVER MIND I would not suggest this; do number 2 and they can direct you since they will have valid information.
We can continue the conversation if this does not resolve your query and further explanation is required just let me know.
Rod