It is not difficult to find information on how to perform a SharePoint version migration; in fact, the documentation provided by Microsoft in this regard is quite complete, both in terms of information and even automation of processes through PowerShell scripts that are quite simple to adapt to our needs.
But the migration process, which at first glance based on this information seems very linear and simple, even if it involves skipping two or more versions (eg migrating from version 2010 to 2016 or 2019) can be significantly complicated If the farm to be migrated has a high level of customization, both at the configuration level (such as highly developed search services, customization of the user profile service, etc.), and at the level of custom developments (WebParts, applications , timers, etc.).
However, with good planning and taking into account a number of factors, the migration process should not be excessively traumatic. That is why, in this article, beyond focusing on the ‘theoretical-technical’ process of migration, it is more about highlighting some aspects to take into account within this process so as not to find ourselves with major headaches in the real-life application of a SharePoint migration.
Experience teaches us that the migration process to a later version of SharePoint Consulting Services begins on the day of the initial version deployment. It may sound strange, but it should be considered that way. It is very common to tend to forget that a newly established farm is very likely to be migrated in the future. This, especially if it is about farms that host core applications of large companies (corporate intranets, for example) ends up happening, beyond the desire of its owner in search of the possible advantages or improvements of the new versions, by himself. platform life cycle: after time, the version will no longer be supported, and in these cases especially it is difficult to maintain this situation.
This does not mean that any extra effort is necessary in the maintenance and development of the farm. Simply, what he recommends is to establish a series of common application guidelines that in the future will not entail additional work time in the migration process. There are tools that are recommended for use, not only in this aspect but in general when developing on the SharePoint platform such as MSOCAF or SPCAF, which among other things will indicate those aspects to change in our solutions in order to optimize a possible version migration (serve as For example, the inclusion of folders in the SharePoint ‘Hive’ that can be changed from one version to another as text strings and that can be referenced through the use of the SPUtility class). Getting used to detecting and correcting,
Within these previous considerations, it is recommended (although as a prior aspect and apart from the migration process) to convert web applications to Claims authentication if they are already in the source environment. It is convenient to carry out this conversion before starting the migration tasks, to already have the final scenario that we will migrate.
The migration process will also be the time to adopt the target version models that have changed, as far as possible. And this can be especially relevant for example in relation to the search service if it is included in the migration. In any case, the ideal would be to have it ready for the application as quickly as possible after the migration, that is, prepare scripts and components already packaged to apply in a short space of time at the end of the migration process, and that the new environment begins to work with these adaptations already applied. In this way, for example, in the aforementioned case of searches, we will adapt from the outset to the new model in case of change (e.g. from 2010 to 2013), since, although the model will continue to work correctly in the new version,
At this time also, it will be important if it is not applied in the farm of origin, that in the new farm the recommendations regarding service accounts are applied. If they are already applied in the source farm, it will simply try to replicate it.
Environments and migration process
Since SharePoint version migration does not include a jump of more than one version, we must bear in mind that we will need as many environments as versions we are going to pass. That is, if for example we are going to migrate a farm from SharePoint 2010 to 2016, we will need two new environments: one in the 2013 version and the other in the 2016 version. The hardware is the minimum, since the web applications are not even going to be built on them. They will simply be used to upgrade the different service applications and the content databases of the web applications to be migrated (that is, a single machine would be sufficient). Regarding the destination environment, it must be dimensioned according to the final needs,
As in many other cases, good planning will be key to the successful completion of the SharePoint migration with the least impact. To do this, it will be necessary to be very clear about what we are going to migrate:
Identify the service applications that are going to be migrated: Obviously, they will be one of those whose migration is supported (Search Service, User Profile Service, Secure Store Service, Managed Metadata Service, Business Data Connectivity Service and PerformacePoint) those that are used in the current farm. If they are not in use or configured, it is preferable not to migrate them and configure them from scratch in the new farm if they are necessary.
Identify the content databases of the different farm web applications that must be migrated.
Identify the configurations of the web applications to replicate in the new farm, as well as the existing managed paths in each of them.
Identify all custom solutions deployed on the farm.
Also take into account other ‘helper’ applications that are being used in the farm: clients, redistributable packages, etc. which should also be available in the final environment.
Regarding the migration steps, as indicated, we will not go into detail, we will simply list the tasks that we will have to perform in all environments:
Obtaining backups of Service databases to be migrated and Content Databases of web applications.
Restoration in the destination environment.
Migration of services.
Creation and configuration of web applications.
Solution deployment (.wsp).
Content Database Test.
Assembly of the Content Databases.
Upgrade of site collections (if the version requires it).
Final adjustments and adaptations that are necessary.
As indicated, it is relatively easy to find information on each of the steps in the process.