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.
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
