We are moving to Exchange online in a few months. We currently archive from Exch2016 without shortcuts, on EV 12.5.1. The plan was to disable the users for archiving, and export a users archive back to their orginal mailbox, then migrate to the cloud. Any concerns with that approach?
A user had a question, if they move items from their mailbox in to Virtual Vault, would it restore the item back to the original folder? I assume if it's named the same, say Inbox to Inbox then it would work, but if they moved from Inbox to Inbox\reports it would create the folder structure Inbox\reports if it didn't already exist?
In theory, this will work.
How many users do you have? A few months might be to short to restore all the archives to the mailboxes. If moving items to Virtual Vault, I assume you configured that to place them into the archive? If I recall correct, if you put an item in a folder in VV, (depending on configuration) it would be archived, and put in the location from VV. IF configured to update shortcuts, you move a shortcut from inbox to inbox\reports, location in archive would also be updated.
If you have many users (or large archives) you should really also look at 3rd party tools. I understand the cost is not something to look forward to, but the ease they provide are well worth the money.. Have a look at TransVault and/or Quadrotech.
I agree witth everything above. Provide a lot of time as there will be pleanty of gotchas. Remember that there is a reason you archived mailbox data in the first place, so ensure you are not restoring more than you can deal with locally, OR in Exchange Online. I would configure local exchange to match the limitations of Exchange Online to ensure you are best suited for this transition. Your mailbox migration will be much more challenging due to the increase in size.
Generally if you are a small company and we are talking about a small ammount of data, this approach theoritically should be OK with gotcha's along the way. In practice and scale, I would not suggest going this way. Archive data is typically less critical than live mailbox data and dumping it back to Exchange and migrating it up only complicates the migation of this critical dataset.
I have even seen cusotmers go the other way, to agressivly archive prior to a migraiton to shrink the mailbox sizes and ensure prompt migration of that data set and then moving the archived data more once their mailboxes are done. This model incurs additional costs, but tends to make for the smoothest of migrations IMHO.
To chime in here from an archive migration vendor, I do agree with the previous posters.
If you have a larger project and want to talk to some awesome folks about migrating it, feel free to contact us @ https://cloudficient.com/contact-us/
We do handle the common gotchas, and out team has many years of experience migrating Enterprise Vault
Thanks guys. There's about 2000 archives. Average size is about 6GB, 12TB total. I did a test of 1GB, took about 12mins to ingest back into the mailbox on-prem, and went smoothly. But I know how these things go, so am expecting some issues. There's still testing to do, haven't migrated any mailboxes to the cloud yet, that's a couple of months away.
Ok. So, did you do the math? If not, let me show you:
12TB in total = 12288 GB
1 GB = 12 minutes = 12288 GB takes 147456 minutes which is 2458 hours which is 103 days (provided migrating 24*7). You will not be migrating 24*7, trust me :)
That 12288 GB is EV size. That means that if you restore that back to Exchange, to be on the safe side, you need to double that to accomodate mailbox growth. If you use DAG's, you need even more. Do you have at least 24TB available for your Exchange?
With this amount of data, you are best of with a 3rd party tool. What do you do if the migration crashes halfway? Have you tested what happens? Does EV pick up where it left off, or does it start over again? How about running archiving? What do yo do with archives that no longer have a mailbox connected? I am currently migration an EV with about the same amount of archives, and use a 3rd party tool. The ability to define exactly which archive to migrate, the reporting, the chain of custody etc. justifies the additional cost easily.
With 2000 archives, if I had any other option I would explore it. It is not as bad as PST migrations, but you also have to consider the care and feedding of this process and that issue isolation is something that requires some expertise that typically is not cheap.
Is trackability of this process needed at all? What about when user Q (it is most commonly an officer) has claimed an issue with the migration's results (Incomplete, duplicated data, wrong data, wrong location.....) . With third party tools you can PROVE what happened and end the conversation. With no such tracking.... you will have to rely on creative defense.