With any type of migration there are numerous factors that must be considered before you start. You need to know how the migration will affect the resources of your IT department, whether there will be any downtime and what the most appropriate migration method is. Many organisations decide to deploy third-party solutions to help automate and speed up the migration process \u2013 but are they necessary?<\/p>\n
The most common aspects of the traditional IT environment that are often migrated are mailboxes and data. This piece explores a few migration scenarios and whether you need third-party solutions for them.<\/p>\n
While migrating mailboxes\u2026<\/strong><\/p>\n There are many methods you can use to migrate mailboxes natively \u2013 but they are often overly complex, time-consuming and prone to error. In most scenarios native migration is possible but not always the best approach. Here we will go through some of the most common mailbox migrations and whether third-party solutions are necessary.<\/p>\n Migrating from Exchange Server 2003 to Exchange Server 2016<\/strong><\/p>\n Natively migrating mailboxes from Exchange 2003 to the latest version will require a \u201cdouble-hop\u201d migration \u2013 moving from Exchange 2003 to 2007\/2010 and then from there to 2016. Double-hop migrations are not the ideal way to move mailboxes as they can often fail and require a serious amount of manual work. There is no native way of migrating mailboxes from Exchange Server 2003 to 2016 without double-hopping.<\/p>\n Third-party migration solutions, though not completely necessary, will directly migrate mailboxes from 2003 to 2016 quickly and with minimal manual intervention.<\/p>\n Migrating Public Folder from Exchange Server 2007\/ 2010 to 2013<\/strong><\/p>\n Again, this kind of migration is entirely possible to carry out using third-party tools alone but the method isn\u2019t particularly clean. For starters, you need to be running Exchange 2007 SP3 RU15 or later\/ Exchange 2010 SP3 RU8. If you have an older version, you will have to upgrade your system, which can be a bit of a pain.<\/p>\n You could technically get around this by using a Serial Migration Method, but this isn\u2019t recommended by Microsoft and so should generally be avoided.<\/p>\n Third-party tools can simplify this migration by allowing you to perform it without upgrading your system.<\/p>\n Tackling network resource issues<\/strong><\/p>\n If you are attempting to migrate particularly large mailboxes it may not make sense to use native methods. The process could end up being unbearably slow or failing altogether. In this situation the best approach would probably be to deploy a third party solution that provided load sharing and other resources to help speed up the migration process.<\/p>\n While migrating data\u2026<\/strong><\/p>\n Data migration can be seen as being comparable to mailbox migration in most cases native processes are available to get the job done. However, just because something can be done natively does not mean that it is the best approach. Let\u2019s go through a couple of common mailbox migrations and see if native auditing alone can get the job done.<\/p>\n Upgrading SharePoint<\/strong><\/p>\n When performing a SharePoint upgrade using native tools, from SharePoint 2010 to 2013 for example, you may run into a few problems. If the process gets disrupted due to low disk space, power failure or unmatched mapping of metadata, the environment could be left in an unbalanced or unsupported state. Occasionally you may also want to easily roll back the changes, which isn\u2019t possible using native processes alone.<\/p>\n Some third-party solutions provide pre-migration analysis to ensure that you avoid running into these problems and also allow you to roll-back unwanted changes at the click of a button.<\/p>\n Migrating from File Server to OneDrive for Business<\/strong><\/p>\n In this type of migration, the structure of File Server and the User names in Office365 should match, which is difficult to achieve natively. You have to manually check that the structures have migrated correctly, which can be a laborious process. Most IT departments don\u2019t have the time to do this process manually, opting instead for a third party solution that allows for automatic synchronisation.<\/p>\n Conclusion:<\/strong><\/p>\n In most cases it is possible to perform migrations manually \u2013 but more often than not, native migrations can be difficult and time consuming. If your IT department is stretched for time, or wants more detail and control over their migrations, then it might be much more effective to deploy a solution like Migrator for Exchange and Documents. Such solutions are relatively inexpensive, easy to deploy and free up IT teams to focus on contributing more to the bottom line.<\/p>\n","protected":false},"excerpt":{"rendered":" With any type of migration there are numerous factors that must be considered before you start. You need to know how the migration will affect the resources of your IT department, whether there will be any downtime and what the most appropriate migration method is. Many organisations decide to deploy third-party solutions to help automate […]<\/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-341","post","type-post","status-publish","format-standard","hentry","category-exchange-server"],"yoast_head":"\n