Microsoft do offer native tools to help users with their Exchange migration but they are not always user-friendly. Often they are lengthy, time consuming and prone to error. Here are the 10 things we think would be most helpful to users when migrating using Microsoft\u2019s own processes. <\/p>\n\n\n\n
Knowing how much time a migration will take is important when \nplanning how to deal with the potential downtime. Setting up an \ninfrastructure and then running a test migration to find out how long it\n will take can be time consuming and complex. A simpler means of \nestimating the exact time it will take would make the whole process much\n easier.<\/p>\n\n\n\n
Admins using different versions of Exchange have different \nexperiences with Exchange migration. Older versions of Exchange \n(Exchange 2003 or before) may experience more issues when migrating. For\n example, someone who wants to migrate from Exchange 2003 to Exchange \n2013 will have to do a double hop migration from Exchange 2003 to \n2007\/10 and then to the latest 2013 \/16. The same is the case with \nExchange 2003 to Office 365 migration.<\/p>\n\n\n\n
Exchange migration may vary significantly depending on the source and\n the target environments. Various types include same domain (single \nExchange migration), same domain (multiple Exchange migration), \ndifferent domain, Office 365 and hosted Exchange Server migrations. \nMaking the migration process as similar as possible for each type will \nhelp speed up and simplify it.<\/p>\n\n\n\n
Additional infrastructure, such as a migration server, needs to be \nsetup in order to perform native migrations. Users also have to run some\n additional tools for pre-migration analysis and configuration. Virtual \ninfrastructure can be setup manually but a lot of the time users can \nexperience issues with this approach. Migrations that don\u2019t require \nadditional infrastructure would be much easier and may reduce the amount\n of issues that users come across.<\/p>\n\n\n\n
Occasionally, some Exchange versions mailboxes are unavailable to \nusers throughout migration process. This can be particularly irritating \nwhen the migration can last for days. Being able to schedule the \nmigrations to run during non-office hours would help to minimize the \ndisruption to end users.<\/p>\n\n\n\n
During the migration, glitches can occur if your Exchange environment is not properly configured. There can be an overwhelming amount of variables to consider, and anything you miss may cause the migration to fail. The overall migration process just need to be simplified.<\/p>\n\n\n\n
Migration speed hinges on a number of factors, including the server \nresources. If your server resources aren\u2019t up to the task then the \nmigration can take a long time regardless of your network capacity. One\n solution to speed up the migration would be if you could use the \nresources of other network computers in addition to the server \nresources.<\/p>\n\n\n\n
In large organizations with terabytes of data, migrations may run for\n days and admins may be spending an excessive amount of time keeping \nwatch to make sure everything runs smoothly. If the migration stops \nadmins won\u2019t know about it until they get round to checking it. Alerting\n should be introduced to notify admins immediately if the migration \npauses.<\/p>\n\n\n\n
While the migration is in progress, admins may want to know what has \nbeen migrated, what hasn\u2019t, and how much time remains. It would be \nuseful if Microsoft provided a GUI based reporting console to give this \ninformation in an easily consumable format.<\/p>\n\n\n\n
Once the mailboxes and public folders have been migrated, you may \nfind that you want to roll back the entire migration and put things back\n to their original state. At the moment Microsoft does not provide an \neasy means to do this.<\/p>\n\n\n\n
Conclusion<\/strong><\/p>\n\n\n\n Achieving a successful migration is possible using native processes but it is by no means perfect. There are many factors to consider and potential issues to overcome when relying on native migration alone. We believe that, until Microsoft addresses the key issues we have outlined in this article, the most effective means of carrying out migrations is with the use of third-party Exchange Migration solutions . This solution provides all the things that we think users want that aren\u2019t currently available using native processes.<\/p>\n","protected":false},"excerpt":{"rendered":" Microsoft do offer native tools to help users with their Exchange migration but they are not always user-friendly. Often they are lengthy, time consuming and prone to error. Here are the 10 things we think would be most helpful to users when migrating using Microsoft\u2019s own processes. Exchange Migration Tips 1. Provide means to estimate […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-765","post","type-post","status-publish","format-standard","hentry","category-exchange-server"],"yoast_head":"\n