With the advent of SharePoint 2013, I am getting used to listen people speak about migration and upgrade as if they were synonymous. Um, no. It is important to understand that they are two different processes, which means different headaches for admins. In the next paragraphs, I am going to collect some information to start putting things in order.
Migration: it is the process of moving contents[1] form the current system to a different new updated one. It is typically carried out through commercial tools[2], not supported by Microsoft. Data transfer is mostly based on public API, which permits to work on a restricted set of information. It means that some metadata can be lost during the transfer. In example, you should think about how versioning, permissions, authors… but also statistics, audit data … will be managed. The migration process insists almost only on contents, which is why you can use it to jump versions in your update plan. In other words, you can migrate from SharePoint 2003 to SharePoint 2013.
Upgrade: it is the process that brings the system from the current version to the next one. It is supported and documented by Microsoft[3]. The upgrade works at database level, which is why it will be easier to avoid metadata loss.
At this point, it is possible to do some considerations, comparing the two processes with respect to common scenarios. In general, the update should be considered as an opportunity to review how the platform is used and governed. Indeed a new version brings new functionalities and services.
The upgrade process does not change the information architecture. Differently, you can pick up and choose what to migrate where. It means that while migrating you could rearrange your contents.
Application services provides important functions and improve the user experience. A migration almost implies the re-configuration of them[4]. While upgrading (database attach) application services are essentially automatically upgraded[5].
There is no discussion with customizations; both migration and upgrade requires carefulness to let them work. A SharePoint farm is a complex environment and the presence of bad code could compromise the upgrade itself. An effective update plan have to consider the analysis of solutions, third part tools, personalizations, … in order to define the best approach[6].  Sometimes it could be easier and more convenient to recreate a solution from scratch instead of updating the existing one; sometimes it could be possible to find useless elements.
In conclusion, migration and upgrade are just two different options. The best approach depends on requirements and constraints. It would be possible to move contents without involve the database level, as well as there could be the urgency to decommission the current farm right away, managing the cleanup in a second moment.
Now it your turn, let us know what your experience has been, did you migrate or upgrade ?
[1] Sometimes also applications and configurations.
[2] It depends on the constraints; you could script it or do it manually.
[4] Even if PowerShell could simplify the work.
We are in the process of migrating which is going just ok. We have run into so many customizations that we are going to have to rebuild. In some cases we are trying to convince or customers to upgrade rather than migrate. Speaking of. Can you truly Migrate from 07 to 10 – data only – and work on all other aspects of an upgrade before or after? Anyone have some good resources on this topic?
Matt – I thought for a second you had mentioned a tool that wasn’t on my migration list, but it is 🙂
http://sharepoint-community.net/page/sp-migration-tools
Nice work! Great that you also provided the references!Â
I always migrated to new farms, instead of upgraded.
Usually with the help of a tool like Tzunami, which also allows you to reorganize content by rules you set up (i.e. splitting up subsites into site collections or folders into multiple document libraries).
Metadata was retained completed (as far as I recall) but I guess we had issues with content created by useres which were not present in the AD anymore.
Still, quite an effort, as you need to do several dry runs and then the whole migrations seems to take ages (like whole weekends)…
Thank you, Nicoletta. I should have worded it more clearly. Yes, I want to take the metadata with the documents/pictures and could use a number of 3rd party tools like Metalogix or AvePoint to move it. Since I envision making significant changes in the new system, creating it separately and then migrating data in, that is what I was referencing.
In the move process, I would like to specify different locations for the data. Right now all of the data is together in one db and there have been search issues which led to significant custom coding wherein performance issues have arrived and have been difficult to troubleshoot. IMHO if we correctly structured the 2013 and identified in advance which metadata for which search criteria and specified via permissions (flirting with the idea of setting internal permissions via groups and nested groups in AD) then a new 2013 architecture would merely receive the metadata and documents migrated over, which would make this change an “Upgrade & Migration” rather than just saying I want to migrate.Â
Hello Melanie,Â
Thank you for your note!
I would take this opportunity to clarify a couple of points:
– Microsoft does not release and support the “migration tool itself” (and it should sound normal since they they are released from other vendors).Â
– Migrate does not mean that you will lose, for sure, all, your metadata. It depends on the tool, if you do it manually or not, ecc … By the way, as already emerged in the discussion, you have to carefully consider if and how your approach works with respect to your requirements.
Just let me know if I can help you further.
All the best,
Nicoletta
