Tag: migration

Quest Software

Michael Bratley / / Migration

Quest Software offer a SharePoint migration tool, which can migrate SharePoint 2003 to 2007 and 2007 to 2010.

Quest enables remote migration by offering a web based console that can be accessed from any web browser. It also helps you to easily manage your migration project with the use of, pre-migration assessments, migration job controls, real time progress reporting and scheduling.

Quest will migrate SharePoint sites including content and security settings directly to the new platform. It also enables you to reorganise your site structure during the migration process. Once the migration is complete you can also update any changes to the original sites on the target sites. Quest can even migrate any customisation you may have on your sites including web parts.

Quest also offer a tool that states it can migrate SharePoint 2003 to 2010 directly without the need to migrate to the interim 2007 version. This can be seen in this video “Migrating SharePoint 2003 to 2010“.

More on this can be found at: Quest.

AvePoint

Michael Bratley / / Migration

AvePoint is a third party tool that enables the final stage of migration from SharePoint Server 2010 to SharePoint Online and Office 365.

The AvePoint tool offers the following advantages:

  • Seamlessly migrate existing enterprise content from more than 14 legacy systems to SharePoint Online with a single install.
  • Minimize business disruptions caused by the migration or the deployment of change to sites, content, configuration, and solutions by maintaining co-existance of on-premise and online SharePoint deployments.
  • Reduce risks associated with migration from various disparate repositories or managing hybrid SharePoint environments.
  • Simplify testing, course correction and rollback during migration, deployment or publishing processes.
  • Publish content from the on-premise staging farms to the cloud for global scalability and seamless hybrid management.
  • Staged approach for migrating and publishing enterprise content reduces the number of connection paths required, helping to control bandwidth utilization and ensuring all network resources stay fully optimized.

More details can be found at: http://www.avepoint.com/sharepoint-online-migration-docave/

Migrate from SharePoint Portal Server 2003 to SharePoint 2007 Server to SharePoint Server 2010 (that’s quite a mouth full)

Robert Everatt / / Migration, Office 365

We now have a migration check list!

I have recently found an extremely useful document on Microsoft’s TechNet page that details the transition from Microsoft SharePoint 2007 Server to SharePoint Server 2010. This document can also be used to aid our transition in to Microsoft Office 365.

The document can be found here:  http://lncn.eu/jx7

If we are to upgrade to Office 365 by first upgrading to SharePoint 2007 and then to SharePoint 2010, these are the steps we would take:

  • Prepare to upgrade to SharePoint 2007
    • Determine how to handle customizations
    • Develop new custom site definitions and create upgrade definition file
    • Run the Pre-upgrade scan tool to determine compatibility
  • Prepare to upgrade to SharePoint 2010
  • Perform Pre-upgrade steps (see http://lncn.eu/hjz)
    • Install all perquisites
    • Run and test a full backup in SQL Server
    • Deploy upgrade definition files and new site definitions
    • Upgrade custom Web Parts packages
  • Create the temporary Office SharePoint Server 2007 farm
    • Download the software for the temporary farm (a trial version of SharePoint 2007 can be used if we do not have a full version as a trial version will last 180 days)
    • Prepare the 2007 environment (see http://lncn.eu/fp26)
  • Create the temporary SharePoint Server 2010 farm
    • As SharePoint Server 2010 is not our final destination we will only be setting SharePoint 2010 up as a temporary virtual server much like SharePoint 2007
    • As our method isn’t covered by the document mentioned earlier we will not be creating a full SharePoint Server 2010 farm but a virtual temporary one instead
  • Perform first upgrade (full details see http://lncn.eu/jvx5)
    • Ensure that the pre-upgrade scan has been used, the upgrade will not work otherwise
    • Back up the content databases
    • Restore the backed-up copies to temporary farm
    • Add the databases to the Web applications to start the upgrade process
    • Profile information will also need to be imported (see http://lncn.eu/guw2)
  • Verify the first upgrade
    • Review the upgrade log file
    • Review the transferred sites to ensure they have transferred properly
  • Perform the second upgrade
    • Use the pre-upgrade checker this time
    • Carry out the same actions as before to upgrade to 2010
  • Verify the second upgrade
    • Same as before

Once this is complete, the system will be ready to migrate into Office 365. Unfortunately I could not find any documentation for migrating to Office 365 amongst Microsoft’s documentation. I asked on the community website, one guy said that Microsoft have a list of partners that offer Migration services, these are people that will guide the user through the planning and migration to Microsoft Office 365.

Alternatively a third party application could be purchased such as AvePoint, Quest or MetaVis. These applications have the ability to migrate data from SharePoint Server 2010 to SharePoint Online, retaining all the customization and security settings. If the user were to migrate manually they may lose all content and security settings.

This document has been extremely helpful; it may have taken some time to find all this information without. Anyone considering upgrading their SharePoint server, I strongly recommend giving it a thorough read.

RE

Handling Customisations When Upgrading

Michael Bratley / / Capabilities, Limitations, Migration, Upgrades

Should you be upgrading from SharePoint 2003 to 2007 or 2010, you may need to consider how to handle any customisation you have implemented on your current site.

There are a three options that are available for consideration:

  1. Keep the customisations.
  2. Replace the customisations.
  3. Redo the customisations.

The first option is to keep the customisations in place, which will allow you to keep the same look and feel as the current system, however you would not be able to take advantage of any new capabilities at this stage. If this is the option that would best suit you, there are three options; complete an in-place upgrade, do a gradual upgrade and keep the site in the previous version environment (do not upgrade the site) or you can do a gradual upgrade and upgrade the site , but don’t reset any pages to the site definition.

The second option to replace the customisation is a good option if you are planning on a complete site redesign or significantly changing the information architecture. You can accomplish this is one of two ways; one is to complete an in-place or gradual upgrade and then reset all the pages to the default pages from the site definition. The other way, if you do not need the structure or content is to start a complete fresh.

The final option is to redo the customisation. This method allows you to take advantage of the new capabilities and modify the design slightly if that is required and make it more manageable. You could take advantages of the new master pages to apply your design, rather than customise each individual page. There are three ways to redo the customisations. The first is to complete an in-place or gradual upgrade and do not reset the pages to the site definition version. After the upgrade, modify the appropriate master pages and page layouts of the upgraded site to take on the previous version’s look and feel, and then reattach the page layouts to all customised pages. The next option is to complete an in-place upgrade and do not reset the pages to the site definition. After the upgrade, open the site and copy the customisations, and then reattach the page layouts and reapply your customisations to the master pages and page layouts as appropriate. The final way to complete this method is to complete a gradual upgrade and, in the upgraded site, reattach the page layouts. Then transfer the customisations from your original site to the master pages and page layouts in the upgraded site by using Office SharePoint Designer.

 

The full article can be found at: http://technet.microsoft.com/en-gb/library/cc263203(office.12).aspx

Planning an upgrade from SharePoint 2003 to 2007

Robert Everatt / / Migration, Office 365

From research, it has become clear that the most common way to upgrade from SharePoint Server 2003 to Microsoft Office 365 (SharePoint Online), is to first upgrade to MOSS 2007. However there are some third party tools available to facilitate the migration, this will be discussed in another post.

Good planning in advance seems to be the key thing when upgrading a large portal and there are a handful of analyses that should be conducted which are detailed below..

Type of Analysis Measure Description
Logical Implementation Number and Type of existing sites Understanding this will enable the orgaisation to determine usage and whether or not the sites are used etc.
Logical Implementation Audiences for existing sites Understanding the audiences will help to determine the configuration to support the security and access structure.
Logical Implementation Site access methods and requirements Understanding methods of access, both current and future desired state enables requirements to be met with MOSS.
Logical Implementation Site feature usage and requirements A list of utilized features should collated to ensure that the current site templates are appropriate and satisfy requirements.
Physical Implementation Size of existing sites content database organisation Once numbers and types of sites has been established, a primary input to the planning of migration and organistion for MOSS will be how the physical structure of SPS exists.
Physical Implementation Size and placement of existing server farm infrastructure Both the physical layout of the servers within the farm as well as the physical implementation of sites within the virtual servers inside SPS Virtual Servers to newly design MOSS Web Applications.

In a further blog post we will be looking at the next steps required when migrating.