Hi ​@Erase4ndReuseMedia,

The migration path for this is to standup a new index server, create a new client, and change the index server on the mailbox client to the new index server.  It will then need to rebuild the index on the new hardware.

To monitor the progress of the rebuild, you can review the indexserver.log on the new index server and filter on the phrase “jobs in recon” and the number of jobs should steadily decrease.

If the Index Server cloud is still running, you can switch back to that and use that server for browse and restores that you might need to run

Thanks for the response ​@Mike H 

Are you able to provide any details on the data flow for the rebuilding of the index to new hardware?

Also are there any rough estimates for rebuild time? Items Per Hour / Terabytes Per Hour?

I suspect this may be cost prohibitive.

Hi ​@Erase4ndReuseMedia,

Timelines are for this process are tough, it’s all really dependent on the amount of items in the index, if you are using deleted item retention, and hardware on the new server. I have seen this process complete anytime between a few days up to a month.  Also to note, if you are Content Indexing messages, they will need to be content indexed again once the rebuild is complete. 

For this operation (since we cannot use the backup\restore method) would require the Index server process to restore all of the action logs from media to the index server starting with the first mailbox job that ever run, once the actions logs for that job are restored, they are played back into the index, and then the process moves on to the next job.

Thank you ​@Mike H 

Just two quick follow up questions…

Are we able to perform new backups during the re-indexing process?

If we switch back to use the existing Index Server Cloud for Browse and Restore operations, does that impact the re-indexing process?