7 steps to successfully migrate the SharePoint 2007 portal to SharePoint 2010
Hello! This is our first material on Habré. In it, we are going to talk about our experience in migrating a complex portal using the Database Attach method. Enjoy!
Having decided to share our experience of migration of a single portal, we focused primarily on those who do not ask "Why migrate?" Windows Workflow Foundation, Event Handlers, Jobs, Content Types, Future Receivers, various Site, List, etc. terms and thinks how to make it work in SharePoint 2010.
The article is based on real events, namely on the results of EastBanc Technologies' long-term cooperation with a major airline. For five years, we have worked with the IT department of the portal on the Virtual Sales Manager project. This is a non-standard internal corporate portal for MOSS 2007, which automates the routine financial and legal aspects of the sales directorate and, in fact, is the back office of the directorate. The portal is used by everyone, from the directorate to the cashiers. It operates several products that automate such processes as the conclusion and termination of the agency agreement, registration and cancellation of the point of sale, etc., a huge number of business processes.
')
Over the five-year history of development, the project has grown into an effective communication system for the company with its agent network, which includes more than 1,200 contractors.
So you can appreciate the scale and scope, here are figures and facts:
The development of the portal began in 2007 and continues to this day.
Over the past year, we participated in the migration of several portals from the SharePoint 2007 platform to the SharePoint 2010 platform, in particular, in the migration of the Alawar portal portals and the public receiving mayor of Novosibirsk .
Both portals are remarkable for enhanced functionality, the presence of specialized modules (Windows Workflow Foundation, Even Handlers, Jobs), integration with various BI solutions (Reporting Services, Excel Services, Performance Point).
In Microsoft's promotional products, the migration procedure looks very simple :
In practice, everything was not so simple and not so fast: we were faced with the fact that almost all types of custom solutions require an individual approach to migration. And if we consider that the preservation of all this non-standard good, acquired by overwork, and minimizing the portal shutdown time (!) Is at the forefront, the task turns out to be quite ambitious.
The same specificity (only in larger volumes) was waiting for us on the migration portal for the company, and we again tamed this terrible beast. And then they decided that we already have such experience, which may seem interesting and useful to the honorable public.
We started with the revision of our many years of work related to the development of VSM-portal. In its course, we found that:
1. In the project there are 16 types of various custom portal extensions:
2. The project integrates with the following third-party systems:
The migration of each of these types requires its own approach, which we have formed, but more on that later, but first you need:
This is where the most interesting begins: we have a portal in which seemingly compiled sources are installed, but it doesn’t even open, what further do you ask? About this further.
After the audit, the crucial moment came - you had to choose the method of migration. In order to migrate such a complex portal, we decided to create a test platform identical to the original portal and gradually revive all the functionality on it. We abandoned the idea of ​​running a backup of the farm, because Such an approach would entail a lot of additional work on upgrading the system software of the customer’s farm, and chose the “Database Attach” approach. Thus, we saved ourselves from the hassle associated with the fact that the new and original portal infrastructure did not match.
In accordance with this approach, we have configured encrypted tunnels to the customer's infrastructure through which we connected to complete the test infrastructure on our servers:
At this stage, we worked with various groups of specialists, including administrators and the security service of the portal.
As a result, we received two test sites, each of which consisted of SQL Server 2008 R2 and a web server with SharePoint 2010. At these sites, we deployed the original 80-gigabyte content databases. Test pads, as we conceived, became an exact copy of the original.
So we prepared. In our hands we had a portal identical to the natural, it was possible to start testing business processes. Hour is nearing X, it was time to take the first step on the path of migration.
Next, we launched a pre-upgrade check. Thanks to this, we saw a lot of features required for installation. We connected the content base and recompiled all our DLLs under SharePoint 2010.
Te features that were out of the WSP added to the WSP. We ended up with 16 of them in the end.
After the next pre-upgrade check, errors became much smaller, among them - not a single critical one.
In the next step, we added the * .config, * .sitemap files for configuring the workflow and outgoing emails from the “C: \ inetpub \ wwwroot \ wss \ VirtualDirectories \ 80” folder to the root of the site. The portal opened, and we were able to see what was supposed to migrate on its own (document libraries, site structure, lists), but, unfortunately, one could only see.
After seeing the portal, we wrote out a check list of what is not working. We had to make it work. One can imagine that the checklist was not small, we took every role and made a list of available actions, for example, “anonymous user”, “cashier”, “authorized agent”, etc.
Primus demanded repair:
The same was with the task list for Workflow.
Finally, earned all the sheets.
And then within two weeks we went through the site, found out that it falls and repaired all the custom-solutions that require it.
For example, it was required to correct:
When it seemed to us that everything was ready, we deployed 2 virtual machines with the old airline base and went all the way anew (in the checklist we described 16 steps that had to be done, we repeated them). Everything was restored in the condition in which it was required. It was possible to prepare the infrastructure and ... migration!
When preparing the infrastructure, it was desirable for us to keep the old portal in order to return to it in case of failure. Therefore, a backup of the old infrastructure was made, which took about 4 hours.
The task to the puzzle was also added by the fact that we did not have direct access to the infrastructure, and the preparation took place at night, when the technical service did not want to disturb them in case of problems. Therefore, they resorted to using the remote access system ILO, with which they installed the operating system.
On Friday, at 9 o'clock in the evening in Moscow, we turned off the servers, made a backup, killed all the systems and turned on the new ones. Here the main adventures began: instead of an hour, the system through ILO was set for three hours! And it took us 7 whole hours to install the three systems, whereas initially we planned to spend no more than two! With the motto "Do not back off and do not give up" on our lips, we spent a sleepless Friday night.
When, finally, on Saturday at 6 am, everything was established, and we had normal access through a repository desktop, we installed SharePoint 2010 and SQL on the systems, deployed the base, tested it (see Step Five) and connected it. Already on Saturday afternoon (12 hours after the beginning of the epic), we had a 90% working portal.
So let's summarize.
We spent 4 weeks on preparing the migration, during which everything was done to minimize downtime: a test site was created that was identical to the original portal; with the help of this site was carried out "training" - test migration; Based on the test results, a detailed “combat” migration plan was drawn up.
Preparations worked - the migration took place with minimal portal shutdown time! Namely, the portal did not work for 17 hours, including a 12-hour rearrangement of operating systems and equipment configuration. All this happened at the weekend and had almost no effect on the work of the agents. On Monday, the portal acted as usual, we won!
Thank you for mastering this epic work. We will be happy to talk on the topic of migration, answer questions and argue (constructively!).
A little bit about who is likely to be interested in reading this.
Having decided to share our experience of migration of a single portal, we focused primarily on those who do not ask "Why migrate?" Windows Workflow Foundation, Event Handlers, Jobs, Content Types, Future Receivers, various Site, List, etc. terms and thinks how to make it work in SharePoint 2010.
Portal History
The article is based on real events, namely on the results of EastBanc Technologies' long-term cooperation with a major airline. For five years, we have worked with the IT department of the portal on the Virtual Sales Manager project. This is a non-standard internal corporate portal for MOSS 2007, which automates the routine financial and legal aspects of the sales directorate and, in fact, is the back office of the directorate. The portal is used by everyone, from the directorate to the cashiers. It operates several products that automate such processes as the conclusion and termination of the agency agreement, registration and cancellation of the point of sale, etc., a huge number of business processes.
')
Over the five-year history of development, the project has grown into an effective communication system for the company with its agent network, which includes more than 1,200 contractors.
So you can appreciate the scale and scope, here are figures and facts:
The development of the portal began in 2007 and continues to this day.
- Over 35,000 man-hours were spent on its creation.
- At various times, 28 people worked on the project.
- Every day more than 1600 active users work in the system.
- The size of the portal content base is 80 GB.
- The geography of users - the whole of the Russian Federation, CIS, South-East Asia, Europe.
- The system works in all time zones.
Why we decided to write about it
Over the past year, we participated in the migration of several portals from the SharePoint 2007 platform to the SharePoint 2010 platform, in particular, in the migration of the Alawar portal portals and the public receiving mayor of Novosibirsk .
Both portals are remarkable for enhanced functionality, the presence of specialized modules (Windows Workflow Foundation, Even Handlers, Jobs), integration with various BI solutions (Reporting Services, Excel Services, Performance Point).
In Microsoft's promotional products, the migration procedure looks very simple :
- We carry out infrastructure planning.
- Install the portal and configure it.
- Select the method of updating the portal to 2010.
- Update and done!
In practice, everything was not so simple and not so fast: we were faced with the fact that almost all types of custom solutions require an individual approach to migration. And if we consider that the preservation of all this non-standard good, acquired by overwork, and minimizing the portal shutdown time (!) Is at the forefront, the task turns out to be quite ambitious.
The same specificity (only in larger volumes) was waiting for us on the migration portal for the company, and we again tamed this terrible beast. And then they decided that we already have such experience, which may seem interesting and useful to the honorable public.
Audit or accounting of inventory items
We started with the revision of our many years of work related to the development of VSM-portal. In its course, we found that:
1. In the project there are 16 types of various custom portal extensions:
- a. Windows Workflow Foundation - running 21 business processes (for example, canceling sales points, adding volumes of flights under a corporate agreement, a question from a user, etc.). Some processes run in an amount of 3,000 instances.
- List templates - 232 pieces
- Web-sites' templates
- Main portal
- News feed
- BSP Agent Portal
- Portal Bonus program cashiers
- Confidential Rates node
- Agent Assistance Node (Agent Requests)
- More than 66 Custom Event Receivers and Feature Receivers
- Designs
- For the main site
- For Agent Requests
- For bsp
- For Cashier Bonus
- Jobs (pieces 15)
- Computed fields (about 80)
- Custom Actions with custom controls (about 30).
2. The project integrates with the following third-party systems:
- counterparty accounting system;
- ASIA NEXT software - order ticket outlets, claim work.
The migration of each of these types requires its own approach, which we have formed, but more on that later, but first you need:
- Collect all the sources in one pile and create a new project in VS 2010, place them TFS.
- Make it all going (as it turned out, it is not so difficult).
- Create a WSP for roll on the portal.
- Complete the pre-upgrade check procedure.
This is where the most interesting begins: we have a portal in which seemingly compiled sources are installed, but it doesn’t even open, what further do you ask? About this further.
Infrastructure and approach to migration
After the audit, the crucial moment came - you had to choose the method of migration. In order to migrate such a complex portal, we decided to create a test platform identical to the original portal and gradually revive all the functionality on it. We abandoned the idea of ​​running a backup of the farm, because Such an approach would entail a lot of additional work on upgrading the system software of the customer’s farm, and chose the “Database Attach” approach. Thus, we saved ourselves from the hassle associated with the fact that the new and original portal infrastructure did not match.
In accordance with this approach, we have configured encrypted tunnels to the customer's infrastructure through which we connected to complete the test infrastructure on our servers:
- Active Directory
- Web services for integration (point 3 from the previous section)
- Oracle database.
At this stage, we worked with various groups of specialists, including administrators and the security service of the portal.
As a result, we received two test sites, each of which consisted of SQL Server 2008 R2 and a web server with SharePoint 2010. At these sites, we deployed the original 80-gigabyte content databases. Test pads, as we conceived, became an exact copy of the original.
So we prepared. In our hands we had a portal identical to the natural, it was possible to start testing business processes. Hour is nearing X, it was time to take the first step on the path of migration.
First step
Next, we launched a pre-upgrade check. Thanks to this, we saw a lot of features required for installation. We connected the content base and recompiled all our DLLs under SharePoint 2010.
Te features that were out of the WSP added to the WSP. We ended up with 16 of them in the end.
After the next pre-upgrade check, errors became much smaller, among them - not a single critical one.
In the next step, we added the * .config, * .sitemap files for configuring the workflow and outgoing emails from the “C: \ inetpub \ wwwroot \ wss \ VirtualDirectories \ 80” folder to the root of the site. The portal opened, and we were able to see what was supposed to migrate on its own (document libraries, site structure, lists), but, unfortunately, one could only see.
Second step
After seeing the portal, we wrote out a check list of what is not working. We had to make it work. One can imagine that the checklist was not small, we took every role and made a list of available actions, for example, “anonymous user”, “cashier”, “authorized agent”, etc.
Third step
Primus demanded repair:
- Custom-fields (caught 45 pieces), which for some reason did not want to be displayed correctly. We decided that we will fix them as recommended in the manuals for SharePoint 2010, that is, through XSLT transformation. It worked!
- Many custom workflows written in Visual Studio and custom pages that used Ajax. Previously, when moving from page to page, we transferred ViewState. After migration to SharePoint 2010, it stopped being transmitted. We have long tried to understand - why? It turned out that in SharePoint 2010 the Java scripts changed, and therefore when entering a new page, the form replaced the action path. We solved this task as follows: we wrote on each such page our own additional script, which forbade changing this custom path. And it all worked!
- A lot of Windows Workflow Fondation with a lot of different versions of the DLL, which have gradually been added all these years, and as a result, on the eve of the migration, some Workflows had 3-4 versions of the DLL. In order not to transfer all these DLLs, but to use the functionality from new DLLs, we, first, recompiled them for SharePoint 2010, and, second, we registered the binding of these DLLs in the configurations. As a result, when the system requested the DLL of one version, the DLL of the other version that we identified was always given to it. After that, we also managed to avoid many problems: working Workflow continued to work, and the new ones were started as needed, with the correct versions.
- ASPX pages lists. After migration, they began to work very slowly. Here we are at a standstill for a while. In the end, we decided to review the queries to the SharePoint database with a SQL profiler and find out what goes into the database. It turned out that SharePoint was trying to pull out all the .aspx pages at a time. We tried to create a new list and wrote a script that copied the list pages from the old sheet to a new one. It all worked quickly. After that we wrote a script that returned all the ASPX pages in the old list to the original version of the site - everything was fixed.
- Large lists of points of sale. SharePoint distributed the rights to each element separately. There were about 15 thousand points of sale for which the rights were distributed separately, so the lists were terribly slow. They did it like this: they brought a folder for each agent, they distributed rights to this folder and dragged an agent’s points of sale there. We reduced the number of rights to the number of agents, and the list began to work significantly faster.
The same was with the task list for Workflow.
Finally, earned all the sheets.
Fourth step (boring routine)
And then within two weeks we went through the site, found out that it falls and repaired all the custom-solutions that require it.
For example, it was required to correct:
- Translation of list views in XSL. Specifically, we did not translate them, only a few fields. The rest of the lists we have earned as it should.
- Job and Handlers. It was necessary in the job class to override the “HasAdditionalUpdateAccess” property in order to create the job from the site's UI.
- JQuery widgets. Previously, the $ .ajax method simply returned an object, and now began to put it inside the “d” object (there was data — data.d became).
Fifth Step (training)
When it seemed to us that everything was ready, we deployed 2 virtual machines with the old airline base and went all the way anew (in the checklist we described 16 steps that had to be done, we repeated them). Everything was restored in the condition in which it was required. It was possible to prepare the infrastructure and ... migration!
The sixth step (we prepare infrastructure of the customer)
When preparing the infrastructure, it was desirable for us to keep the old portal in order to return to it in case of failure. Therefore, a backup of the old infrastructure was made, which took about 4 hours.
The task to the puzzle was also added by the fact that we did not have direct access to the infrastructure, and the preparation took place at night, when the technical service did not want to disturb them in case of problems. Therefore, they resorted to using the remote access system ILO, with which they installed the operating system.
On Friday, at 9 o'clock in the evening in Moscow, we turned off the servers, made a backup, killed all the systems and turned on the new ones. Here the main adventures began: instead of an hour, the system through ILO was set for three hours! And it took us 7 whole hours to install the three systems, whereas initially we planned to spend no more than two! With the motto "Do not back off and do not give up" on our lips, we spent a sleepless Friday night.
Seventh step (we pressed the switch!)
When, finally, on Saturday at 6 am, everything was established, and we had normal access through a repository desktop, we installed SharePoint 2010 and SQL on the systems, deployed the base, tested it (see Step Five) and connected it. Already on Saturday afternoon (12 hours after the beginning of the epic), we had a 90% working portal.
And everyone was happy
So let's summarize.
We spent 4 weeks on preparing the migration, during which everything was done to minimize downtime: a test site was created that was identical to the original portal; with the help of this site was carried out "training" - test migration; Based on the test results, a detailed “combat” migration plan was drawn up.
Preparations worked - the migration took place with minimal portal shutdown time! Namely, the portal did not work for 17 hours, including a 12-hour rearrangement of operating systems and equipment configuration. All this happened at the weekend and had almost no effect on the work of the agents. On Monday, the portal acted as usual, we won!
Thank you for mastering this epic work. We will be happy to talk on the topic of migration, answer questions and argue (constructively!).
Source: https://habr.com/ru/post/168493/
All Articles