SharePoint 2013 and SharePoint Online Upgrade Notes

Introduction

For SharePoint 2013, there is a lot of great stuff coming for performing upgrades. I may have mentioned this recently on my blog but a lot of this optimization in upgrading SharePoint. Much of this is driven by experience from the five major releases of the SharePoint however SharePoint Online is proving to be a strong catalyst for improvement. When SharePoint 2010 was released we saw how the architecture of SharePoint completely changed, and much of that change is associated to a long-term Microsoft vision to deliver SharePoint through the cloud. Whether you are implementing on-premise or purchase SharePoint Online, you will be able to benefit.

I know many folks have done upgrades in past versions of 2003, 2007 and 2010 and have dealt with a lot of work to get through those. There are a mixed bag of reasons of why upgrades were complex. When I was consulting I would also remind customers to design and implement for the future. Every large SharePoint customization should have a path for the future. There is really too much to go into here and not the topic of this posting….

In this blog I am going to discuss some of the big improvements that you should know right off the bat in regards to performing SharePoint 2013 upgrades. Second I am going to discuss how these new upgrade changes apply to SharePoint Online.

The following are some of my notes I have captured from multiple events and presentations.

New Facts About Upgrades for SharePoint 2013

The following are some of the big facts that you should know about SharePoint 2013 Upgrades:

• Upgrade Approach – The only approach available for SharePoint 2013 upgrades is DB Attach. There is no more In-Place Upgrade (2003, 2007 and 2010) or Gradual Upgrade (2003).
• Upgrade Versions – It is pretty much the same, you will need to be on the previous version to perform an upgrade; which will require you to be on SharePoint 2010. There are numerous third-party solutions available in the marketplace that can assist you to upgrade from older versions of SharePoint to SharePoint 2013.
• Requires New Server Instances – Given the fact that you must do DB Attach, you will have to create SharePoint 2013 servers. You cannot upgrade your existing SharePoint 2010 servers.
• Important >> Site Collections – Upgrading is now focused at the site collection level. Databases will be attached into the new SharePoint 2013 farm however the actual upgrade itself will be done at the site collection, when the site collection is ready. This is a really important point; “when the site collection is ready”. This means SharePoint 2010 site collections will run in full SharePoint 2010 experience on a SharePoint 2013 server until such time it is decided that it will be upgraded.
• Improvement >> More Well Known – There is a new capability for performing an upgrade health check before actually moving forward with an upgrade. The goal is to provide a capability that will tell organizations that an upgrade will fail prior to it actually failing. A health check report will provide detailed warnings and information on issues to remediate. This is extensible and can build own custom rules. These rules that can detect and custom repair operations can be created for specialized scenarios you may need to support.
• Improvement >> Evaluation Site – This is an exciting capability. There is a new capability that will provide you the ability to spin up a new site collection to preview an upgrade of a site collection before it is actually done. This is a great capability to test and remediate issues before you actually perform an upgrade. This is basically a replacement of the visual upgrade process that was provided in SharePoint 2010 (in my opinion a better solution). These evaluations site collections cannot made be permanent nor is it recommended for long-term usage. There is configuration available to administrators to control the maximum size for an evaluation site (for instance when an administrator did not put on site quotas and you have TBs of data sitting in a single site collection). There is PowerShell available to automate the creation of evaluation site collections (which can come in real handy if you need to do some automation around testing large amounts of site collections). As well an expiration date can be applied to the evaluation site collection to ensure that these sites are not accidently used for too long.
• Improvement >> Quicker Upgrades – With the focus of moving to Site Collection upgrades versus an entire content database upgrade, significant amounts of time is saved when actually performing an upgrade. This is because you upgrade the farm but all the site collections (which require all processing) can be spread out. This reduces having to do big bang upgrades.
• Improvement >> Communications – New features have been implemented that will communicate to users via email during an upgrade. There are events and different email templates you can work with to communicate the status of an upgrade. Additionally a system status bar will also be displayed that an upgrade is being performed. Administrators have the ability to customize the messages displayed to the user to give customized instructions and information.
• Easy User Transition – As I mentioned earlier, upgrades are done at the site collection level and the SharePoint 2010 experience will remain until in effect the site collection is upgraded. This means you can start delivering new SharePoint 2013 solutions in other site collections while continue to run SharePoint 2010 solutions until you have created a proper transition path for the end users. Additionally, this is great for user transition as it will allow end users get user to SharePoint 2013. Organizations have the ability to strategically identify site collections for upgrade to SharePoint 2013 and then select which ones that should go first.
• Initiating an Upgrade – Upgrades of site collections can be automated through PowerShell, administrators can manually execute them or they can be delegated to site collection admins (which may be a person within the business). Remember there are still controls available to control how site collection admins can do it (max sizes, specific site collection blocks, etc.).
• Queuing Site Collections – There is a new capability to throttle the number of parallel upgrades. This can become important if you need to coordinate the upgrade of a lot of production site collections. Specifically you do not want to overload your SQL Servers databases. The Web Application processes will wait for processing capacity and database space before executing. Time jobs are responsible for assisting with this. Large, oversized site collections will not be done through the Web Application; it would be done through a timer job. The queue can be managed if you need. Note that each queue is assigned at the content database level. Even if there is a failure (for whatever reason) the upgrade will be re-initiated in the queue. Finally PowerShell is available to place site collections in the queue or even change the throttle.
• Logging Improvements – Additionally there have been many new improvements for logging. ULS Logs can easily be pulled into Excel, correlations IDs, more error codes and more details are now provided when an error may occur.

Beyond new upgrade capabilities your process for performing an upgrade will change a little bit given these changes. Here are some things to keep in mind.

• Review the Upgrade charts located here - http://msdn.microsoft.com/en-us/subscriptions/cc263199.aspx. There are two specific diagrams a workflow for performing an actual upgrade and another for testing.
• Do not skip doing due diligence. Please audit yourself, know what you have deployed and determine what the best path is to ensure continuity of operations.
• As discussed above, you will need to build out your SharePoint 2013 farms prior to performing the upgrade. It is also good practice to leave those SharePoint 2010 farms as long as you can until you feel the production migration is complete.
• Additionally if you are using federated service farms (ie you have a SharePoint 2010 services that provides common services to other SharePoint farms), you MUST upgrade those farms first. Do not worry, an upgraded federated service farm on SharePoint 2013 can communicate with a SharePoint 2010 content farm. However it does not work in the reverse order.
• Similar to the prior note, even if you do not have a federated service farm, you should upgrade your services first, then bring over content databases and then gradually upgrade sites collections to SharePoint 2013.
• Do not forget, if you have a ton of customization and third-party tools, you will need to work through the process of moving them to the SharePoint 2013 farm.

SharePoint Online

As you have been reading, you may have noticed a lot of new features that are focused on supporting large SharePoint environments. One would be Office 365 and upgrading SharePoint Online customers. Knowing that:

• Previously I talked about upgrading federated service farms first and then upgrading the content farms. Well this is exactly what is going to happen with SharePoint Online. The common federated service farms will be upgraded first by building new service farms on SharePoint 2013 and connecting them to SharePoint 2010 content farms. The new SharePoint 2013 content farms will be created and then the content databases will be moved over.
• Next customers in SharePoint Online will determine when they want to upgrade the Site Collections to use SharePoint 2013. New PowerShell commands are available for SharePoint Online to automate this activity. Both the new Health Check Report and Evaluation Site Collection features are available.
• Note that with SharePoint Online customers will be required to eventually upgrade all Site Collections to SharePoint 2013 user experience. Even on-premise customers should do this as the goal is not to allow SharePoint 2010 solutions to run forever. This capability is really intended to provide support for transition.

As I mentioned, moving forward it is always good to understand how you are building custom solutions. I know a lot of people are doing this SharePoint. I really believe that you can build a lot of solutions with out of the box features and capabilities. I recommend that if you are building highly customized solution, to investigate building solutions with the new SharePoint Apps model.

SharePoint 2013 Technical Diagrams Notes

Introduction

SharePoint 2013 Preview Technical Diagrams are now available here - http://technet.microsoft.com/en-us/library/cc263199(v=office.15).aspx

Ever since SharePoint 2007 started publishing these technical diagrams, I have recommended that architects become very familiar with them. I always start here when trying to understand a new major product release for SharePoint. If you search my blog, you will see that I have directly referenced these diagrams when building SharePoint strategies for customers.

The following is a high-level review of the new architecture changes available with SharePoint 2013.

Corporate Portal Diagrams

I reviewed the two new Corporate Portal Diagrams for SharePoint 2013. From a logical architecture perspective, these diagrams do not have any major changes from the SharePoint 2010 versions. These diagrams accurately capture how organizations should build web applications, site collections, application pools, SharePoint services, etc. to support major business initiatives. The diagrams are still a must read for people who are new or who need a refresher to understand how they should be segregating content and business functions across SharePoint.

Extranet Diagram

The new diagram for SharePoint 2013 extranet architecture closely resembles the corporate portal diagrams, however it is not very revealing on the type of information organizations need when making a decision on how to deploy an extranet. Looking back at the SharePoint 2010 Extranet Topologies diagrams (http://technet.microsoft.com/en-us/library/cc263199.aspx), I find that diagram to be much more helpful and the information contained here still holds true with SharePoint 2013. I would recommend reviewing both of them together.

Services in SharePoint 2013 Diagram

I admit this has always been one of my more favorite diagrams. When this was released in SharePoint 2010, it captured a fundamental change in how SharePoint services are configured and delivered. This new architecture was created to support Microsoft’s ability to deliver SharePoint Online as a SaaS solution.

I reviewed this diagram and nothing has significantly changed in regards to sharing services across farms, the logical architecture of services, service groups and service deployment.

In the services table there are a few new services that have been added.

• Access Services – Do not be confused by this. Yes there was Access Services in SharePoint 2010. At this early point, I know that that Access Services for SharePoint 2013 have been changed to be more focused on utilize the new App Architecture. As such, Access Services for SharePoint 2013 is pretty different. Access Services solutions created in SharePoint 2010 will still be supported moving forward, however they will run in a different service.
• App Management Services - This is a new service that will be used specifically for supporting the new internal catalog or the public SharePoint store. Remember that in SharePoint 2013, everything is an app; EVERYTHING. Even everyday SharePoint lists are now called an app. Once you get over the name change, you will find out it makes complete sense and Microsoft has just aligned what is does with how business users talk about technology.
• Machine Translation Service – This is a new one and as of right now, I do not have much information on the purpose of this service other than the description which says it performs automated machine translation.
• Work Management Services – This service provides task aggregation across management systems including SharePoint, Exchange and Project Server. This is huge from a user perspective. One single place to see all of your tasks. No more building content query web parts to find all tasks; this effectively does this plus goes outside the SharePoint boundary to find more tasks. This is a very exciting service.
• Office Web App Services – Is called out in here as a service that is no longer running inside of SharePoint server. Why? Microsoft strategy is to provide Office Web App Service to other enterprise application than just SharePoint and it strategically made sense to move it out of SharePoint.

In the rest of this diagram there are architecture diagrams for how to architect service groups across farms, none of which have changed from SharePoint 2010. If you are not familiar with this stuff, this is a must read and I recommend reading my old posting on it here.

Mobile Architecture Diagram

There is a brand new mobile architecture diagram provided and obviously this is drive by Microsoft’s focus on being a “services and devices” company. This is a pretty simple architecture that basically describes some things you need to think about if you are going to support mobile to your users and discusses some of the mobile capabilities. This can serve as a launch point for you to begin to dive deeper into how you will support mobile for your organization. The following are some high-level observations I had when reading this the first time:

Extranet – If you are not thinking extranet, you need to so you mobile users can access content when they are on a mobile device. They have some diagrams which will get your started thinking about it and additionally how you can use Unified Access Gateway (UAG) as a reverse proxy to help with that.

Mobile Device Management (MDM) – One interesting thing brought up in this diagram is how do you manage mobile devices? If you need something simple, you can leverage Exchange ActiveSync for remote device wipe, password enforcement, etc. If you are looking for application level MDM there are additional solutions out in the marketplace today that provide even more capabilities.

Application Architecture – The new SharePoint 2013 mobile architecture is introduced. They break it down basically into two logical layers: mobile and SharePoint. Some key points are:

• Automatic Mobile Browser Redirection – Is a new capability that can be used to optimize the mobile experience based on the connecting device. This Feature must be active on the site and will be activated by default on numerous site templates. First there is the Classic View which is used to provide backwards capability to mobile devices and will have a SharePoint 2010 mobile browser experience. Then there is the Contemporary View which is geared to support HTML5 browsers. The Contemporary View is several enhanced features for navigation of SharePoint sites. Additionally, Full Site View is available so the SharePoint site page can be viewed as if it were on a desktop browser or a tablet device.
• Office Hub for Windows Phone – Is an application for Windows phone devices that provides enhanced capabilities to access SharePoint content from multiple places in one spot. It also leverages mobile Office.
• Location – There is a new geo-location field type that is available in a SharePoint List. This can make a list location aware to capture latitude and longitude which can be used with map applications. For instance, if a user enters in data on their mobile device, it will capture where it was done from and then can be displayed on a map. Here is some more information about this - http://technet.microsoft.com/en-us/library/fp161355(v=office.15).aspx
• Push Notifications – There is a new capability to allow notifications to be sent from a SharePoint site to registered applications running on a mobile device. The nice thing about this is that Windows Phone Apps can receive notifications without having to poll. Here is some additional reading on the topic - http://msdn.microsoft.com/en-us/library/jj163784(v=office.15).aspx
• Device Channels – This is a really important new capability as device channels allow you to deliver a publishing site geared specifically to support different types of remote devices. Basically the site can mapped to multiple master pages and style sheets and even control what content you want to make available to specific devices. Here is an overview on the new device channels - http://technet.microsoft.com/en-us/library/fp161351(v=office.15).aspx
• Office Web Apps – As mentioned earlier in this posting, Office Web Apps is now a separate standalone server which does not run inside of the SharePoint boundary. Office Web Apps has been improved a lot to support mobile devices. There are Word, Excel and PowerPoint Mobile Viewers.

SharePoint 2013 Upgrade Process Diagrams

There are two upgrade diagrams that have been provided. Here are some high points I walked away with:

• Must be on SharePoint 2010 – To upgrade, you must be on SharePoint 2010 technologies. This means if you are on SharePoint 2003, 2007 or 2010, you will need to upgrade to the appropriate version to get to SharePoint 2013. There are Microsoft migration partners that have solutions to assist with this. I saw many times, this is the big value proposition for using SharePoint Online as this is handled for customers.
• Database Attach Upgrade – Is the only supported method for upgrading. There is no more “in-place” upgrade option. Frankly that is fine because most customers always went down a database-attach upgrade.
• Preparation – much of the preparation activities that we have discussed in the past with SharePoint 2010 hold true with SharePoint 2013. There is a bunch of information you are responsible for gathering.
• Manual Configuration Settings – In the preparation phase is recommended to get a understanding of all the custom configurations that you may have done because not all of them are going to be migrated. This is because not all databases are upgraded. So many custom configurations in central admin such as alternate access methods, time job tweaks, managed paths, incoming/outgoing email settings, certificates, etc. will need to be documented and reconfigured in the new farm.
• Databases That Can Be Upgraded – There is a set of databases that can be upgraded. They are Content, BDC, Managed Metadata, PerformancePoint, Secure Store, Search and User Profile databases.
• Customizations – This is an important task that needs to be completed. I have seen many cases where good software organizations have not implemented a strong configuration management process and the result is an organization may not know about all the customize code that may be implemented. There are numerous ways to find all of them by running PowerShell commands, doing system directory diffs, checking web.config, etc.
• Upgrade Health Checks – There are some new features that are available to site collection administrators that will show you a health check of a site collection before actually upgrading the site collection.
• Evaluation Site Collection – Site Collection Administrators also have the ability to request the site collection be copied into a new site collection to evaluate how the upgrade will affect any customizations they may have. This is helpful so you can remediate issues before you actually perform the upgrade. This is also nice because your site collection will run in a SharePoint 2010 mode until you are ready to actually upgrade it.
• Testing – Just like for SharePoint 2010, the best way to prepare for a migration is to build up your new SP 2013 farm and then multiple practices runs of that upgrade into the new production environment. An entire process is defined in one of the diagrams and is a great place to start.

SharePoint 2013 Search Diagrams

If you are a reader of my blog, I wrote some long postings about the search architecture for both SharePoint 2010 Search (here) and FAST for SharePoint 2010 (here). I am not going to do a deep dive into all these search components and roles because they are basically covered. As many people now know, the FAST search engine is now the core search engine for SharePoint. It will just be referred to as SharePoint Search. Now you will be able to leverage a very powerful search engine out of the box. However many of the advanced enterprise features of search will only be available in the SharePoint Enterprise addition. I am also really excited about this for SharePoint Online because it can leverage FAST too. SharePoint Online will not be able to do Enterprise Search of line of business systems but a Search Farm (which is FAST underneath the hood) can be configured on premise and SharePoint Online can invoke that search and provide the search results in the cloud; pretty exciting.

I highly recommend taking the time to review both of these diagrams. It explains how each of the components interacts with each other. Additionally there is a diagram the goes into how to scale the server farms for the amount of content you will need to index. There is a great, new table in there that shows you how scaling will work. To be honest, the folks who are really serious about search will say it is an art and a table does not always communicate how you will do it. It always comes down to how many items, the types of data sources, custom transformations, query latency, index latency, etc.

SharePoint 2013 App Overview Diagram

This is an area I plan to do a lot more exploration of this coming year on and writing on this blog. Why? This is something we have been waiting for a long time with SharePoint development. There are several ways to look and this. SharePoint Features which we have been writing for years are Apps. This is name change to better communicate our technology to the end users who have to use SharePoint. However the new SharePoint App architecture is way more than that.

I have seen so many things over the years.

• I think one of the biggest challenges people would run into is developing great SharePoint solutions only to find out they incorporated some dependency they should not have, they wrote some high-end code that should not be running in the SharePoint layer, they cannot leverage their solution outside the SharePoint boundary, etc. We want to resolve those problems by helping developers to deploy solutions in way that will keep their SharePoint environment nimble.
• Plus we want to provide third-party vendors quicker access to customers. We want to help customers to quickly acquire third-party solutions.
• Additionally we want to allow customers to leverage commodity based SharePoint Online. As you may know SharePoint Online has restrictions on high-end custom development and if that code where to run in another location, while be highly integrated with SharePoint Online, that is a huge win.

I will thing of many more reason this year on why this is so great J

Now we can achieve this through the new SharePoint App architecture. The old SharePoint Solution architecture where you create a WSP is still around. Nothing has changed there. This is used to create deployment packages and in many cases is used to deploy code that requires full trust. SharePoint Solution packages will continue to be used by third-party vendors or developed internally with such tools as Visual Studio. You can still create Sandbox Solutions which run in a more secure runtime and can be deployed in SharePoint Online.

Now the new Apps framework for SharePoint 2013 is a packaged up in a file called .APP. It is composed of many of the same types of files, AppManifest, embedded Solution.wsp, etc. Once an app is loaded into SharePoint, it is accessible through the App Catalog in SharePoint. This App Catalog can be controlled at an organizational level.

Remember the big point with Apps is, that the custom solution you are writing may or may not actually run in SharePoint. Full trust code is not supported. Your custom solution code itself may run in a different SharePoint farm, on an IIS server as ASP.net pages, ASP.net pages running in Windows Azure, etc. So how does SharePoint access these solutions running outside the SharePoint context? In simple terms we have an IFrame (with some extensions) that external solution is available through. OAuth provides the secure connection for access SharePoint objects from a remote location. We will additionally use a new extended and robust event model and remote client SharePoint library to write integrated, remote code.

Why is this so great? We are going to ensure that custom applications and solutions that are being developed with SharePoint are isolated. No more writing a bunch code and services that should not be running in SharePoint servers. It is great that you can do whatever you want with SharePoint, however this will drive solution management.

So you may be asking where does this get deployed? There are many different options for hosting.

• SharePoint Hosted – This means the app and all the resources run in SharePoint. Remember you server side is not supported however you can write applications with SharePoint’s JavaScript libraries and such.
• Windows Azure Autohosted – This is a model that is only supported in SharePoint Online. In This case you can write an App package that will have code for Azure and SQL Azure embedded into it. When the application is deployed, the azure solution will be automatically deployed for you. You do not have to go to Azure and set anything up at all; it is all handled for you behind the scenes.
• Provider-Hosted – This is the third model where custom code and solutions are hosted in a separate server in your organization, hosted in Azure, hosted in different SharePoint servers, etc.

Once an App package is installed, it can be managed and monitored through the catalog. End users have the ability to select an app to run in their sites (much in the same way as turning on a Feature). If and when an app is updated, the user can decide how they want to upgrade to the new app.

Again I really plan to go much deeper on this in my blog but for right now, these are just some introduction notes and ramblings on how excited I am about this new capability J

Back Up and Recovery Diagram

There is a new diagram that goes into the details of doing your own back-up and recovery for SharePoint 2013. I know many people have become accustomed to using third-party vendors for supporting these operations and I still believe these vendors will continue to provide features above and beyond what is out of the box. However, if you are a do it yourself sort of person, this is a great diagram to review.

Not much has changed in regards to developing back-up procedures for both the SQL Servers and the SharePoint Servers. There are tons of scenarios covered in here, and I recommend reading this if it is important to you.

SharePoint 2013 Database Diagram

Finally the database server diagram has been updated. This is a really really really important diagram to review if you are managing on-premise servers. It goes over all the SharePoint databases, plus provide sizing and scaling guidance. Great information.

SharePoint 2010 Upgrade, Validation and References

• SharePoint 2010 Migration Getting Started
  
• SharePoint 2010 Upgrade Scenarios
  
• SharePoint 2010 Upgrade Preparation
  
• SharePoint 2010 Upgrade Testing
  
• SharePoint 2010 Upgrade, Validation and References
  

Implementation and Validation Phases

This final phase is the actual upgrade of your SharePoint environment and validating that it was a success.

Communication Plan

A prerequisite of the upgrade is to make sure you have a rock solid communication plan for the business users and stakeholders. You need to:

• Show them all of their functionality is being upgraded.
  
• Explain to them your testing approach.
  
• Ensure them that service level agreements will be maintained.
  
• Describe to them how the upgrade process will work.
  
• Explain to them where there will be changes.
  
• Give the stakeholders confidence that you have accounted for everything.
  

I would not wait to start communications with stakeholders until this phase. I would actually start it very early in the upgrade project but there are things that will come out of testing that will affect your communication plan.

The Upgrade and Validation

The actual upgrade should be completed based on all the steps capture in your previous test runs. You should make sure you steps throughout your deployment plan that spell out who is doing what and when. You should also spell out specifically who needs to be on call during specific periods of during the deployment. A well prepared deployment plan will actually spell out to hour what tasks are being done by whom and what are the dependencies. The objective of any deployment (SharePoint or not) is to ensure that there is minimal downtime with little to no errors.

It is not possible for me to give you an actual plan for your SharePoint environment because every client has different dependencies. As well depending on the upgrade approach you chose the steps will be different. However the following need to be accounted for:

• Hardware Configuration Steps
  
• OS Configuration Steps
  
• System Account Configuration Steps
  
• SharePoint Installation Steps
  
• SharePoint Configuration Steps
  
• Upgrade Approach Steps
  
• Customization Upgrade Steps
  
• Data Recovery and Back-up Configuration steps
  
• Validation Test
  

After the upgrade is complete, you need to make sure you validate things are working as expected. There are several things that you can do to ensure the upgrade went successfully (reference):

• Review Logs – Review all of the logs. There are logs associated to the setup, the SharePoint Configuration wizard and the upgrade log that tell you if there were any errors.
  
• Verify Version Numbers – Go into Central Admin and check the version number on the farm page.
  
• Check Web Site Status Page – All sites can be checked in Central Admin to see if the site has been upgraded or is still in progress. This can also be checked via command line (localupgradestatus).
  
• Walkthrough Service Configuration – Ensure services are configured as expected.
  
• Search – Run a crawl and review the logs to see if there any errors.
  
• Review Upgraded Sites – Very basic functionality, check placement of web parts and controls, review highly visible sites, check integration functionality, review large lists and ensure it works with the new SharePoint list throttling features, check branding and layouts, check user permissions to ensure they have access to what they used to, check customized (unghosted) pages, etc.
  

Conclusions

I hope by the end of this you have initial understanding of how to get started with your SharePoint Upgrade. It is complex process and there are tons of facets you need to think about. I believe success of a SharePoint migration is understanding the People, Process and Technology.

I also hope that during this upgrade process your organization begins to really focus on SharePoint Governance and create an official project to manage your SharePoint environments based on this experience.

References

• Upgrade and Migration for SharePoint Server 2010 - http://technet.microsoft.com/en-us/sharepoint/ee517214.aspx
  
• Upgrade process overview (SharePoint Server 2010) - http://technet.microsoft.com/en-us/library/cc262483.aspx
  
• Run the pre-upgrade checker (SharePoint Server 2010) - http://technet.microsoft.com/en-us/library/cc262231.aspx
  
• Verify upgrade and review upgraded sites (SharePoint Server 2010) - http://technet.microsoft.com/en-us/library/cc424972.aspx
  
• Upgrade Resource center - http://msdn.microsoft.com/en-us/sharepoint/ee514557.aspx
  
• SharePoint 2010 Evaluation Guide - http://technet.microsoft.com/en-us/library/cc262881.aspx
  
• Worksheet - http://go.microsoft.com/fwlink/?LinkId=179928
  
• In Place Upgrade Check List - http://technet.microsoft.com/library/ff608117(office.14).aspx
• Database Attach Check List - http://technet.microsoft.com/library/ff607663(office.14).aspx

SharePoint Migration Models

• Microsoft SharePoint Server 2010 Products Upgrade Planning (http://go.microsoft.com/fwlink/?LinkId=167099)
• Microsoft SharePoint Server 2010 Upgrade Approaches (http://go.microsoft.com/fwlink/?LinkId=167102)
• Microsoft SharePoint Server 2010 Test Your Upgrade Process (http://go.microsoft.com/fwlink/?LinkId=167105)
• Microsoft SharePoint Server 2010 Services Upgrade (http://go.microsoft.com/fwlink/?LinkId=167108)
• Microsoft SharePoint Server 2010 Upgrading Parent and Child Farms (http://go.microsoft.com/fwlink/?LinkId=190985)

SharePoint 2010 Upgrade Testing

• SharePoint 2010 Migration Getting Started
  
• SharePoint 2010 Upgrade Scenarios
  
• SharePoint 2010 Upgrade Preparation
  
• SharePoint 2010 Upgrade Testing
  
• SharePoint 2010 Upgrade, Validation and References
  

Test Phase

The next phase is to actually do a test run of the upgrade. We will need to build up test farms and upgrade real production data into these farms. We want to ensure that we know and understand all the steps needed to support the upgrade approach that was chosen and resolve as many issues as possible.

The Test Farm

First you will need to create a new test farm with a configuration as close as possible to the new production environment. It would best to copy the entire production content database(s) and ensure that you all of the services configured as close as you can to production. It will not be possible to have an identical configuration databases (because it is not very easy or really supported to copy configuration databases – yes I know you can) but having SharePoint central admin and services configured as close to production to possible is good enough.

It is also important to try to use similar hardware as possible for your test environment.

Test Run the Upgrade Approach and Documentation

Once you have a test environment as close to the production environment as possible you will need to go through the actual upgrade process. Earlier we discussed there is an In-Place, Database Attach and Hybrid approaches. You should test these approaches as if you were doing them in production. You should focus on catching/handling potential exceptions and minimizing downtime.

You should make sure that you have strong step-by-step documentation that captures all of the steps needed to support the upgrade. The documentation should capture:

• Hardware configuration
  
• OS configuration
  
• System account configuration
  
• SharePoint installation steps
  
• SharePoint configuration steps
  
• Upgrade approach steps
  
• Data Recovery configuration steps
  
• Tests that ensure upgrade was successful
  

I would recommend that once you have a successful run of it; make sure that you can do it again using all of the steps that you have documented.

The Actual Test

The actual testing of the new SharePoint environment must be comprehensive. It is not just as simple as running the upgrade and seeing of the homepage works. Here are some things you should be thinking about:

• Have a test approach that will incorporate business users.
  
• Have a test plan with actual test criteria that you can measure success by.
  
• Create test plans will test all SharePoint services that you plan to utilize.
  
• Have test plans that test the performance and utilization.
  
• Have an approach for testing search and search crawl configuration.
  
• Have test plans to test all customizations. Everything from branding to integration with external systems that feed or consume data from SharePoint.
  
• Make sure your test plan really tests the boundaries of your SharePoint implementation.
• Finally make sure you have a mitigation plan and approach on how to rollback an upgrade if there is a failure.

SharePoint 2010 Upgrade Preparation

• SharePoint 2010 Migration Getting Started
  
• SharePoint 2010 Upgrade Scenarios
  
• SharePoint 2010 Upgrade Preparation
  
• SharePoint 2010 Upgrade Testing
  
• SharePoint 2010 Upgrade, Validation and References
  

Prepare Phase

The goal of this phase is to take the information that you learned in the previous phase and actually perform a detailed audit of the current SharePoint 2007 implementation. The focus will be to ensure you are ready to do the migration and have accounted for everything you need to. The focus should always be on risk mitigation. The challenge is with SharePoint is that it is commonplace that poor governance has not been put in place and this will lead to challenges with an upgrade.

Pre-Upgrade Checker

One thing you will need to do is run the Pre-Upgrade checker on the current SharePoint 2007 environment. This tool will check the status of your server environment and provide you a list of issues that need to be resolved before doing the upgrade. It will not resolve any issues for you. It will tell you:

• The upgrade path for each server in the SharePoint 2007 and if it can be upgraded.
  
• Will return a list of alternate access mapping settings.
  
• Will return a list of all installed and customized elements on the SharePoint 2007 server. This list includes all site definitions, site templates, features and language packs. It will call out customizations to these elements as well. Knowing all these customizations and understanding their upgrade path is critical.
  
• Unsupported customizations will also be listed.
  
• Orphaned objects any databases will be listed. This would include list items, documents, web sites, and even site collections. These objects need to be resolved by running a tool prior to doing the upgrade otherwise they will not be recoverable after the upgrade.
  
• Will report any missing or invalid configuration settings throughout the SharePoint farm. These again should be fixed before performing an upgrade (especially if you are doing an In-Place upgrade).
  
• Will perform a check of the database and report if the current database meets the requirements for an upgrade.
  

The findings of running this tool will assist in making a decision of what upgrade approach you will take.

Technical Considerations

Some other things you will have to take into consideration as part of the upgrade are the following:

• Upgrade Performance - Is proportional the amount of data to be upgraded. The number of site collections, web, lists, documents, document versions, document size, and basically the overall size of the content database. The more content, the longer it takes. As well, the database environment has a direct affect on the performance of the upgrade. You need to account for SQL Disk I/O, SQL disk layout, Temp DB optimizations, SQL CPU and Memory, Web Front End CPU and Memory. I wish I had great statistics to give you an idea of how long it actually takes.
  
• Upgrade complexity - Is proportional to the amount of customizations made to SharePoint. This is rather broad and I have mentioned it before that customizations to SharePoint will make the upgrade process more difficult. Most customizations will be upgradable unless you were not following best practices. However you should pretty much review each every customization that has been made into SharePoint and understand its upgrade path. You also need to think about external application dependencies to SharePoint. If SharePoint is integrated with external applications, you need to consider how the upgrade will affect them. You also need to review all third party products that may have been installed into your SharePoint 2007 environment.
  
• URL Changes – This is something you could easily forget about but could have majorly affect business users. You need to know how dependant they are to the current URLs. Even still, URL dependencies are not just user dependant, applications and custom solutions built for SharePoint use them to access content. An In-Place will require no URL changes. A Hybrid Approach where the content databases are attached into an In-Place upgrade will not require a URL change either.
  
• Audit the Current Environment - I have mentioned earlier that you need to make sure that you audit your environment. You need to understand such things as how much data you have and what are the characteristics of that data. You need to know how many users you have and what do they do within SharePoint. You need to know how many SharePoint farms you have and what their migration path is. Another thing you need to understand is the topology of the each SharePoint farm and how you will migrate to the new SharePoint farm. Also you need to take into account what is the backup strategy and data recovery of SharePoint environment. The current hardware and network environment should be re-evaluated to ensure that it is still sufficient and if there are plans to move to new hardware, what is it?
  
• Third Party Software - A special focus needs to be made on third party software that has been installed into SharePoint 2007. You specifically need to focus on any applications that may have modified the SharePoint DB Schema, configuration changes that will have to be migrated, check to see if you are at the proper path level, does it even support SharePoint 2010 and if it is even needed anymore with the new features of SharePoint 2010.
  
• Evaluating Customizations to SharePoint 2007 – The most common customizations that you will need to check into are customizations to site templates, list template, custom css, master pages, SharePoint Designer Modifications, Features, custom web parts, event handlers, application pages and javascript. The most common way to understand what changes have been put into SharePoint it to check to see what solution packages may be deployed. However we have seen a lot of developers not follow best practices when deploying their SharePoint 2007 solutions so you may have to resort to more drastic approaches to find all customizations. One way is to do a complete diff on an out of the box SharePoint 12 hive and compare to a production 12 hive. Can also look at the web.config and look for SaveControls elements that have been added and look at the GAC or webs for custom DLLs.
  
• Cleaning Up Environment Before Upgrade – Before doing the upgrade it would be recommended to clean up stuff that is no longer being used or does not need to be migrated. You can delete stale sites or webs, remove documents that are not being utilized anymore, and cleanup or back out of custom templates, features and web parts that are no longer needed.
  

Non Technical Considerations

I know I have mentioned this before but it is worth mentioning again that a successful SharePoint upgrade is not just driven by understanding the technology. You have to have a solid understanding of how users are using it today and ensure that they do not lose any functionality moving forward. Just because it is newer and better does not mean it is best for the business user. You need make sure you have strong communication plans and provide them a solid understanding of the new features of SharePoint 2010. Providing them early access to a SharePoint 2010 environment to test drive would be a great thing to do. You need to understand all the current use cases of how SharePoint 2007 is used and make sure that matches up with the upgrade approach you plan to use. You need to have an understanding of the functionality of SharePoint 2010 needs to be made available immediately and provide them with a vision of how SharePoint 2010 can better support their needs.

We all know have business owners and stakeholders on your side and allowing them to be part of the decision process is extremely important.

Preparing for the SharePoint Upgrade

To summarize, to prepare for your SharePoint 2010 upgrade you should:

• Run the upgrade checker as we have discussed.
  
• Complete a technical audit of the current SharePoint 2007 environment.
  
• Complete functional audit of how SharePoint is used.
  
• Create a new logical and physical architecture for SharePoint 2010 and understand how existing functionality will upgrade into.
  
• Clean up your current SharePoint 2007 environment.
  
• Finalize your upgrade approach based on all the information that has been captured.

SharePoint 2010 Upgrade Scenarios

• SharePoint 2010 Migration Getting Started
  
• SharePoint 2010 Upgrade Scenarios
  
• SharePoint 2010 Upgrade Preparation
  
• SharePoint 2010 Upgrade Testing
  
• SharePoint 2010 Upgrade, Validation and References
  

Upgrade Scenarios

As part of your planning you planning you need to make a decision on the upgrade approach that is right for your organization and service level agreements you have with the business for solutions and applications hosted within SharePoint 2007. There will be no single upgrade approach that can be used for every organization.

• Unsupported Upgrade Scenarios - There are several standard upgrade scenarios you can look into. There are few unsupported scenarios that you know immediately. First it is not possible to upgrade from any version of SharePoint earlier than WSS v3 or MOSS 2007 SP2. If you are not on those versions you first need to upgrade to that which will require you extra planning and validation to ensure those upgrades worked correctly. So if you are still on SharePoint 2003 you will need to upgrade to version 2007 first. Second, there is no side-by-side installation supported meaning you cannot run SharePoint 2010 and 2007 on the same machines. Third there is no more gradual upgrade supported anymore like there was with upgrading from SharePoint 2003 to 2007.
  
• In Place Upgrade– First there is an In-Place upgrade which is to basically just go through the installation wizard. It is the most simple however all sites will be unavailable during the upgrade. Users can continue to use the same URLs after the upgrade is complete. You will be required to upgrade the machines SharePoint is running on from 32 to 64 bit and the previous version of SharePoint 2007 must be removed off the machine. You can be ensured that farm wide settings will be upgraded correctly and customizations to SharePoint 2007 will be brought forward if they are SharePoint 2010 compatible.
  
• Database Attach Upgrade – Databases from SharePoint 2007 platform can be attached into SharePoint 2010. This would include content, profile service and project service databases. SharePoint 2007 configuration and search databases cannot be attached into SharePoint 2010. At a high level the process is as simple as backing up the databases, restoring on the SQL machine where SharePoint 2010 is pointing to and then run two PowerShell commands. Using this approach you can upgrade many content databases at a time and you have the ability to consolidate SharePoint farms into a single farm. However all farm settings and configurations will be lost using this approach and more importantly all customizations will have to be manually migrated. I personally do not that is such a bad thing because it will force you to do an audit of customizations in your SharePoint 2007 environments and provide you the opportunity to put in a new governance plan to control customizations from this point moving forward.
  
• Hybrid Upgrade Approach 1 – Using the two approaches above there are some potential ways to minimize some of the cons. One approach is to create a brand new SharePoint 2010 farm and subsequently move over all customizations to that new farm. Once the customizations have been tested, make the SharePoint 2007 content databases read-only, perform a back up of the databases and restore them on the new 2010 farm. Once the new 2010 farm is tested, you can then take down the old servers and bring the new one online. The good thing about this process is that is minimizes downtime because read-only access is still available. It also provides you some time to test everything before opening it up for use. The downside is that more coordination is needed to do this, more hardware is required, and farm configurations from 2007 are not migrated.
  
• Hybrid Upgrade Approach 2 – Another approach would to stop access your SharePoint farm and detach your content databases. Then perform an In-Place upgrade of just the service and configuration databases. Then once the In-Place upgrade is complete, then reattach your content databases into the upgrade server. The advantage of doing this is the In-Place upgrade process will perform quicker if it does not have to do the content databases at the same time. If you want to even speed it up more you could create a temporary SharePoint 2010 on the side for just upgrade content databases while the In-Place upgrade process is running on the main server. Using this approach you still have the flexibility of consolidating multiple content databases from other SharePoint 2007 farms. As well customizations do not have manually moved to a new SharePoint 2010 server. Still a down side of this is that the SharePoint farm will be down for a period of time.
  

I personally like Hybrid Upgrade Approach 1 because it allows for minimal downtime and you will have a new clean SharePoint 2010 farm to start from. I know will require extra re-configuration of the services and migration of customs. However there is no point bringing over a ton of stuff that may not need to be used anymore and it allows you to put in some new governance to get control of customizations that are put into SharePoint 2010 from this point on.

Minimizing Downtime

Microsoft has built several features in to the upgrade process to assist with keeping the size of your upgrades small.

• Read-only Databases – Was introduced in SharePoint 2007 SP2 and during the upgrade process content databases will be marked as read-only. This will prevent any change to the content but still provide read-only access to SharePoint while the upgrade is going.
  
• Attaching Content Databases in Parallel – The upgrade process allows you to attach multiple content databases at the same time. This can be done by using multiple Window PowerShell sessions. So you are not limited to attaching one content database at a time. Microsoft is aware that many of their customers have content databases that are very large. This is why it is important to have good SharePoint Governance plans in place to make sure you have site collections that do not get too large. SharePoint Content databases can be terabytes but when something gets that big it hard to back and restore; and in this case upgrade. If you have the ability to break apart your content databases before the upgrade, that could be a good thing to look into.
  
• Alternate Access Mapping – There will be cases where the content databases are very large and it is not reasonable to do upgrade of the content database in a single shot. SharePoint 2010 upgrade process supports using alternate-access mapping redirections to direct traffic between the old and new SharePoint sites (reference).
  

Other Upgrade Considerations

Along the way there are lots of things that need to be thought about when doing a SharePoint upgrade. Here is a couple you should be thinking about right off the bat:

• New Hardware Requirements - Understand the new hardware requirements need to support SharePoint 2010. For instance for production use you need to use 64-bit machines with a minimum of 8GB memory. You can use either SQL Server 2005 or 2008 but the OS must be Windows Server 2008. This could be news to your infrastructure team and need to get the new SharePoint 2010 requirements in front of them.
  
• Install Prerequisites - There are a lot of pre-requisites that have to be installed on every machine that will be running SharePoint 2010; too many to list here. To assist with this, Microsoft has provided a Prerequisite Installer that can check each machine that SharePoint 2010 will be installed on to ensure that it is compliant.
  
• Streamlined Installation - There are several installation wizards for SharePoint 2010 that will assist you with the installation. There is a SharePoint 2010 Preparation Tool (new) that will install all the prerequisites. Setup wizard to that installs the bits. Configuration wizard which installs configuration database, central admin and adds servers to the farm (nothing new there). Server Farm Configuration Wizard (new) which is used to configure the farm itself, site collections, service accounts, etc. You need to plan on how to use these wizards as part of your upgrade.
  
• Client Requirements - Minimum client requirements are that Silverlight 3 be installed along with IE7, IE8 or Firefox 3.5. Safari 4.x a d Firefox 3.5 on OS X Snow Leopard. Firefox 3.5 on Unix/Linux 8.1.
  
• Forms Based Authentication (FBA) – If you are using FBA authentication you will have to do some extra planning to move it forward. You will need to convert web applications to use the new claims-based authentication model of SharePoint 2010. You will need to make modifications to the web.config of those sites and you will need to use PowerShell to migrate users and permission forward.
  
• Shared Service Providers (SSP) – If you did not know the concept of the SSP has been removed and there is a new service architecture has been introduced for SharePoint 2010 (read my blog here). You get an understanding of that an plan on how to move forward services that were being supported in SharePoint 2007 to 2010.
• Understand the Logical Architecture for 2010 – As well the logical architecture for SharePoint 2010 has changed significantly and it more flexible than the previous version (read my blog here). You have so much more flexibility in the hosting and sharing of services and this should be accounted for when migrated SharePoint 2007 features to 2010.

SharePoint 2010 Migration Getting Started

• SharePoint 2010 Migration Getting Started
  
• SharePoint 2010 Upgrade Scenarios
  
• SharePoint 2010 Upgrade Preparation
  
• SharePoint 2010 Upgrade Testing
  
• SharePoint 2010 Upgrade, Validation and References
  

Introduction

I believe SharePoint Upgrades from 2007 to 2010 is going to be one of the most important topics of discussion for SharePoint consulting. Let me first start off with a history lesson of what I saw with SharePoint 2003 to SharePoint 2007 upgrades. One common scenario I saw was high adoption of WSS 2.0 because it was free, they loved it and wanted to upgrade to MOSS. A second scenario was a client trying to use SP Portal 2003 to support mission critical activities. They understood the limitations, they saw SharePoint 2007 solved their needs and they needed upgrade. It was common in the second scenario to see customizations (custom site templates, web parts, etc.). Typically it was challenging to move forward these customizations because SharePoint 2007 was a complete re-architecture of the SharePoint platform. What we would usually recommend them to lose their SP 2003 customizations because it would be offset by the fact that SharePoint 2007 was just so much better. SharePoint FrontPage modifications typically made things very challenging to complete a full apples-to-apples upgrade. In the end, SharePoint professionals did a good job at moving all the content from SharePoint 2003 to 2007 and then started to build new solutions. Here is a blog that I wrote that provided guidance for moving from SharePoint 2003 to SharePoint 2007.

I wanted to discuss this because I feel that the atmosphere is a bit different now with SharePoint 2007 to SharePoint 2010. These are the commons scenarios that I currently see today:

• I see a lot of organizations that have made large investments into SharePoint 2007. Not just from a cost of software and ECAL, there has been a lot of investment in either IT staff or consultants to build solutions with SharePoint 2007.
  
• SharePoint 2007 is an extremely powerful platform however there are new features of SharePoint 2010 (i.e. enterprise content management, scalability, search, data transparency) are very enticing and many organizations need them to continue to see added return on investment.
  
• Customizations to SharePoint 2007 are not as small and trivial as what we saw with SharePoint 2003. The custom applications and systems that are embedded in SharePoint 2007 need to move forward in full to SharePoint 2010.
  
• The amount of content to be migrated of SharePoint 2007 is significantly more than what we saw with SharePoint 2003.
  
• There tends to be strong user adoption of SharePoint 2007 that there was with SharePoint 2003. Knowing this, it is important to ensure that there is continuity between upgrades to ensure there are little to no disruptions to the business.
  

My honest opinion is before getting "wrapped around the axel" on exactly how to do this upgrade, we should just look at this like any other enterprise application upgrade. Once we understand that we can bury ourselves into the details of how the upgrade process will go. Will it go perfectly, well there is not a lot of data out there just yet on how smooth an upgrade will go and all the exceptions that you will run into. I do see two things:

• First Microsoft has provided us some better tooling to facilitate upgrades from SharePoint 2007 to SharePoint 2010.
  
• The paradigm shift for SharePoint 2007 to SharePoint 2010 is not as great as the previous upgrade. This gives me hope that the upgrade process will go better for SharePoint 2010.
  

In this blog I am going to over some of the various aspects you need to take into initial consideration when doing a SharePoint 2010 upgrade. Microsoft has provided an upgrade cycle that they are using to communicate how upgrades will play out for SharePoint 2010. I actually like it and will use it as the basis for this discussion. I am going to add lots of things which I think are important given what I have seen with SharePoint for the past few years.

• Learn Phase – Focus on understanding what you have today and where you plan to go tomorrow.
  
• Prepare Phase – Detailed planning for SharePoint 2010 upgrade.
  
• Test Phase – Testing the upgrade process.
  
• Implement Phase – Perform the actual upgrade.
  
• Validate Phase – Validate the success of the upgrade.
  

Learn Phase

There are several goals of this phase. I think the most important thing we want to know is what we have today and where we plan to go tomorrow.

Current Status – First you need to get an understanding of what you currently have today. In many cases, your SharePoint environments have probably experienced growth, usage and adoption that you probably have not thought about. Whether intended or not, you need to gain a good understanding of it to make sure there is continuity for the migration. You need to assess:

• The current infrastructure. Understand all the servers in the farm and what services they are supporting.
  
• Review the size of content databases and understand what site collections contain the most content.
  
• Understand the topology of the SharePoint sites and how they are organized today.
  
• Try to get an understanding of how security has been managed up to this point. I know this is a touchy subject with a lot of organizations have had challenges with permission management with SharePoint 2007. Still you need to get a handle on it.
  
• Information architecture and taxonomy needs to be reviewed. This is typically the content types that you may have created.
  
• Need to get an understanding of all the services that have been configured and deployed into SharePoint, for instance Search, Excel Services, PerformancePoint, etc. You should also get an understanding of how the business users are using them too.
  
• Audit all custom development implementations such as Custom Features, web parts, site templates, event handlers, InfoPath forms, BDC, etc. Anything that has been deployed you're your SharePoint environment should be understood and leave no stone unturned. You really need to look at everything and understand what was done and even more important "how" was it done.
  
• Review SharePoint Designer usage. I call this out separately because sometimes access to this tool is given out to more than just developers and allows users to create customizations to SharePoint that not everyone may know about.
  
• Review all your SharePoint ULS Logs, web logs, and event logs on all machines where SharePoint installed. Might as well know if there are lots of errors out there. If you see egregious errors or warning it would probably be good to fix these up before doing the migration.
  

This list is not totally inclusive of everything you may need but it is a great starting point.

Roadmap – Next you need to create a roadmap for SharePoint within your organization along all the same lines that I just discussed.

• First you need to understand SharePoint 2010, understand the new features and how you plan to use them in your organization.
  
• Next you need to understand what requirements of the organization and more importantly the business drivers, business owners and actors who will utilize this. Knowing this will greatly affect both you logical and physical designs of SharePoint 2010 (i.e. we have so much more flexibility with service management in SharePoint 2010).
  
• Next you need to be able to map out by quarter and fiscal year what business objectives need to be supported and when. These timelines can greatly affect your migration approach.
• Need to document all people, process and technology risks associated to SharePoint and create a mitigation plan for each that will be actively managed throughout the migration project.

SharePoint Migration Level Of Effort

I am posting this blog is a little late. A common question is what is the level of effort to migration a out-of-the-box SharePoint 2003 implementation and are there any tools out there that can help me determine this? I have been asked this several times by current and prospective clients. There is a lot of information already out there on the migration from SharePoint 2003 to SharePoint 2007 but this is what I have seen.

Note I am going to refer to SharePoint 2003 generically instead of specifying WSS 2.0 or SharePoint Portal. Same with SharePoint 2007 instead of calling it WSS 3.0/MOSS.

If I had to give a level of effort the size of the content database for SharePoint can be a factor but it really does not influence the complexity of a particular SharePoint migration. Running the prescan tool on your content databases will provide you the best information to understand what you are up against when migrating to SharePoint 2007.

To run the Prescan Tool you must install SharePoint 2003 SP2. The prescan tool can be downloaded here. The Prescan Tool will find

• Sites that are based on languages or that use controls that are not installed
  
• Custom Web Parts
  
• Orphaned data objects
  
• Customized site templates
  

The first one I have not run into yet and the second one is nothing to be concerned about either because most custom web parts "should" be compatible with SharePoint 2007.

The third one could pose some problems but many of the issues can be resolved with applying SharePoint 2003 post-SP2 hot fix. A good resource to get an understanding of errors that are through during the migration process is Bill Baer's blog on the subject. Many of these issues can and will be resolved pretty quickly using this hot fix. You will run the hot fix's new database repair command and then re-run the Prescan tool to determine if the errors have been resolved. If orphaned data objects still remain, you will have to evaluate each one and determine if there are critical pieces of data that must be migrated.

The fourth one is probably the most difficult issue you will come across when doing your migration. I have seen several clients say "we have not done any customizations and we are using SharePoint 2003 out-of-the-box". In many of those cases we found these statements to be un-true where 30% to 80% of their SharePoint implementation had been un-ghosted (customized). This issue is extremely problematic because if a site/page has been customized the presentation of that page will not take on the new SharePoint 2007 presentation; as many want this. A common way a site becomes un-ghosted (or customized) is when FrontPage is used or when a developer has gone in a directly modified the templates in the hive. Note that changing the templates in the hive is an un-recommended practice for either SharePoint 2003 and 2007.

In the end for un-ghosted (customized) site templates you will have to evaluate each one individually and determine what the migration path is for it. If the specific page has been edited with FrontPage, then you could simply revert the page back to the original template. In many cases this is a sufficient solution as many of the changes with FrontPage are presentational in nature. If a SharePoint 2003 site template was purchased or created you will need to migrate the site definition using a XML mapping file that will migrate the template definition to the SharePoint 2007 definition. Creating this XML mapping file requires more effort depending on the complexity. I would ensure that you allow enough time to do several test tries for this. This can be done by simply backing up the content database and bring it back up on different test server.

Using the Prescan tool will help you determine all of this and assist you with understanding the effort for migrating to SharePoint 2007.