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.
Y’all have set up a great group and resources. Thanks!
This is great, Indra. Yes, please do share links to your blogs. Thank you for the feedback. If you’re comfortable sharing your experiences between the different softwares, I would love to hear them.
Melanie
Nicoletta,
I think that the confusion arises from historical usage.
First, there is more than one type of upgrade: version-to-version and build-to-build. The build-to-build can be a hotfix or a service pack, but it may very well change any or all of the same things changed by a version-to-version upgrade: the executables files, the database schema and the data (when the database schema changes, the data has to change also).
Second, migration just refers to moving SharePoint from one farm to another. This might mean changing the hardware, changing the SQL Server, merging two farms (acquisition of a company, collapsing domains), or perhaps other scenarios I’m leaving out. It is possible to migrate and not change the version at all, as in the case of acquisitions.
Third, every previous version-to-version upgrade has allowed some sort of in-place option. There were side-by-side scenarios, in-place scenarios and hybrid scenarios. This last version upgrade is the first one that has no such option. So, there were previously upgrades that did not involve a new farm. As a former Microsoft PFE, I can tell you that database attach to a new farm has always been the cleanest.
Finally, Microsoft does not support multiple version upgrades using out of the box methods. This is possible with third-party tools (third-party vendors use supported methods–not magic–or at least they should). It’s always a good idea to refactor something that’s not working for your customers and wouldn’t you know that they often choose an upgrade as the time to do this. You certainly can change the information architecture with or without third-party tools. Given that the skills required to do this are often not practiced, it may be easier to use a third-party tool or to hire an expert unless you plan to continue rearranging the furniture. Having a dev and a QA/Staging environment to practice in is probably more important, however, and will get you through a number of upgrades of every sort.
Regards
Mary
Nicoletta,
Good work, yeah I agree with you, even I was on same boat couple years back thinking upgrade/migration is same :), but realized when I actually started upgrade, I did more than 10 upgrades and 7-8 migrations in my experience and as always the mileage varied depend on each client.
Migrated using DocAve, Control Point and tried few other tools later, but let me share an interesting thing, I did use both in a project (Migration/Upgrade).
if information Architect(IA) is different from SharePoint Architect(SA) (I see these days its happening) then things will change, IA will layout things depend on migration but SA will work on upgrade (technical stuff – mostly after migration and add enhancements to the migration and call it upgrade :)).
I know its kind of confusing but I can try to explain later in blog posts, but my recommendation is if IA and SA are different , please work closely with IA and decide whether its migration/upgrade at very first stage not after IA is completed.
