You’ve probably already had thoughts about potential migration speeds, how to do reporting during the migration, and other EV data movement related things. Based on our experience, we encourage you to take a step back first.
If you’re watching this video, most likely you’re looking into how to migrate your Enterprise Vault data to Exchange Online, or Office 365 in general. That means your users are also about to be onboarded to Office 365.
Have you considered all the dependencies and how you will handle those in your project?
Of course, there are obvious dependencies like,
“I can’t ingest data to an Office 365 archive mailbox that doesn’t exist”,
but also more tricky ones. For example, having to change the archiving policy in EV a few days before the mailbox is migrated to Office 365 to avoid potential data loss; in certain EV configurations.
I would encourage you to try to understand how this process should look in your organization and how the migration of an archive can tie in.
With hundreds of successful data migration projects behind us, I can also tell you that despite best practices, each migration in each organization is different. Your chosen migration approach should be able to cope with the individual requirements of your organization.
No matter which migration approach or migration product is chosen, it can be only as good as your EV environment is.
Consider the following situation: You deployed EV years ago and have archived hundreds of millions of emails over the years. EV has fingerprinted each item and attachment, stored those single instanced entities on your archiving storage, and created multiple entries in its databases. Your SQL Server had to take a moderate load over a long period of time.
Well, the bad news is that you are about to re-apply almost the same load again to your SQL Environment when you start migrating to Office 365. But this time you will shrink the time period where the load is applied to the duration of the migration, whatever it might be. Are your legacy environments able to handle that load?
The good news is, that you can do a lot of things, to prepare your systems and your organization for this challenge and we’re here to help you.
All the different vendors that offer migration applications use different architectures and delivery methods. Some vendors will require that you install data migration servers and dedicated migration SQL Servers in your datacenter while others will suggest you use Microsoft Azure to host and / or process the data. Whatever company you’re talking to make sure to understand and to be comfortable with the underlying architecture and approach.
You can basically differentiate between three different generations of architectural models, which have all their advantages and disadvantages. We’ve got a video in our plan where we’ll discuss the different approaches.
Having seen in the last 15 years all kinds of customer environments, we know for a fact that every customer environment has its own challenges.
You might expect that if you have two customers with a similar setup that you get the same data migration throughput. Unfortunately, this is not the case. What I’m trying to say is that it doesn’t help you to know what your migration vendor’s maximum speed was in one of their last projects, because it might be completely different in your environment, even if you have a comparable setup.
An Archive Data Migration project is not a cheap and easy undertaking. You should make sure that the solution works in your environment and with your requirements and data, and the easiest way to do that is via a proof of concept in your environment with your users and your data.
In many projects unexpected things come up during the lifetime of the project. Make sure that whichever vendor you choose takes a flexible, agile approach to your project and how to adapt to changes that might occur.
You might have seen our blogs on service protection throttling. This is just one of the things that might happen during your Enterprise Vault migration to Office 365.
That just about covers things in this video. Let’s do a quick recap.
We’ve talked about taking a step back and reviewing project dependencies.
We’ve said you need to brace for a high load on your environment in order to perform the migration quickly.
We’ve said you should check how your migration project architecture is designed because this will affect how your migration scales, how agile it is to changes that might be required and the vendors approach to your project.
We said that you should always do a proof of concept. This will show how the product performs and gets you on level footing with your chosen vendor and the migration team.
Finally, you should prepare for unexpected things that might occur during your migration to Office 365 project.
Thanks for your time. Check out other resources on our website … cloudficient.com
.png?width=620&height=82&name=Untitled%20design%20(18).png "Cloudficient")
.png?width=200&height=26&name=Untitled%20design%20(18).png "Cloudficient"){kind=small}
.png?width=600&height=79&name=Untitled%20design%20(18).png "cloudficient logo")