0211 Essential Guide Migrating it Content

8/3/2019 0211 Essential Guide Migrating it Content

1/6

February 2011

The Essential Guide to

Migrating SharePointContent

By Colin Spence

SPECIAL ADVERTISING SUPPLEMENT TO SHAREPOINTPRO CONNECTIONS


2/6

SharePoint migrations provide many challenges,but i done properly they can yield signifcantbenefts to an organization. This Essential Guideprovides an overview o the options you should

consider when migrating to SharePoint 2010, includ-ing assessing readiness to migrate, an overview o thestandard Microsot options, and the advantages o usingAvePoints DocAve SharePoint Migrator tool. The guide

also covers DocAve compatibility with non-SharePointdata repositories.

The term migration summons orth images o birds orother animals moving in an orderly ashion across greatdistances, and is quite apt when talking about the datathat needs to be moved. You can argue that an In-PlaceUpgrade isnt technically a migration, but Ive ound thatthese are ew and ar between and generally dont meetthe needs o most organizations (I discuss this below).While many dierent types o SharePoint migrations arepossible, due to the large number o SharePoint-brandedproducts that have been released by Microsot over

the past decade, this guide ocuses on the most typi-cal migrations occurring today, which tend to be romSharePoint 2007 to SharePoint 2010.

Although SharePoint 2003 (2.0) and even SharePointPortal Server 2001 (1.0) environments are still in pro-duction, they are less common and pose additionalchallenges due to the age o the sotware. For example,no direct migration path rom the 1.0 or 2.0 versions oSharePoint technologies, including SharePoint PortalServer 2001, SharePoint Portal Server 2003, SharePointTeam Services, and Windows SharePoint Services 2.0 toSharePoint 2010 is supported using Microsot out-o-

the-box tools. Using Microsot techniques, the only wayto migrate these older SharePoint environments to 2010is to upgrade the servers and sites to SharePoint 2007frst, and then ollow one o the valid migration paths.AvePoint oers tools to migrate SharePoint 2003 contentto SharePoint 2010, but these tools arent reviewed indetail in this guide. However, the interaces and capabili-ties o these tools are similar to the SharePoint 2007 to2010 migration tools discussed.

Assessing Reasons to MigrateWithout lingering unduly on the topic, an organization

should have clear reasons to move rom one SharePointplatorm to another. Just because a new version oSharePoint (or any other sotware) is on the marketdoesnt mean that it makes solid business sense or theorganization to migrate. However, once the decision hasbeen made and beore too many commitments are madein terms o the timeline, you should review the existingSharePoint environment (assuming 2007 or this guide)to predict the challenges that might lie in the way. Bygetting a better understanding o the current state o theSharePoint 2007 environment, IT can better decide on theupgrade path and process.

You should review the overall health o the SharePoint2007 environment. A quick checklist ollows:

Check the server logs on the SharePoint ront-endserver(s) and the SQL back-end server(s). Experi-enced server administrators will quickly be able todierentiate between the nuisance warnings andalerts and the errors that could indicate confgura-tion or perormance issues.

Review the sizes o the SQL content databases tohave a sense or how much data there currently is,and how much storage space will be needed in thenew environment.

Review the SQL maintenance plans to ensure thatlog fles are being shrunk, and that the databaseconsistency checker is running.

Test a recent backup o the SharePoint 2007environment. Just because the backup looks like ithas been completing doesnt mean it can actuallybe restored, and many (most?) organizations donttest restores oten enough.

Compare the production arm to a new, uncustom-ized arm with a tool such as WinDi and look ordierences.

Review the web.confg fles or the productionIIS web sites (typically located in the C:\inetpub\wwwroot\wss\VirtualDirectories older), lookor sae controls that arent Microsot, look orapplication keys (or example the text stringPublicKeyToken).

Look in the GAC (typically the C:\Windows\As-sembly older); third-party DLLs are a sure sign

that there might be something custom in theenvironment.

Look in the solution store (Central Administration> Operations tab > Global Confguration> SolutionManagement), because many customizations aredeployed through solutions.

Look in the SharePoint hive, especially in thelayouts, images, and themes olders (generally inC:\Program Files\Common Files\Microsot Shared\Web Server Extensions\12).

Review the programs rom the Control Panel to

look or third-party applications.

Service Pack 2 or SharePoint 2007 includes a pre-upgrade check utility that lets administrators check thereadiness o their environment or upgrade to SharePoint2010. This pre-upgrade check runs as an extension to theSTSADM command-line tool. Assuming the SharePoint2007 environment is completely upgraded to SP2, youcan run this tool with minimal risk because its read-onlyand makes no modifcations to any o the fles on theserver. Run the pre-upgrade check by typing

stsadm -o preupgradecheckThe pre-upgrade check tool runs through a number o

tests and checks the environment or compliance withSharePoint 2010 requirements. It produces a detailedreport that outlines which areas o the existing arm areready or upgrade, and which ones are in need o reme-diation beore they can be upgraded.

Another best practice is to create an Excel grid o thedierent site collections and sites and then record inor-mation o interest that will be useul during the migra-tion. For example, a key piece o inormation is whetherthe site or site collection will be migrated. Similar tothe process o moving to a new house, a migration is agood time to hire a dumpster and get rid o stu that

is no longer o value. Many old sites or even whole sitecollections havent been modifed in months or years,and IT may determine that this content does not need tobe migrated. Instead, IT might choose to use SharePointbackup tools to back up the whole site collection to drivestorage or tape, or use the stsadm o export command toexport individual sites.

As mentioned in the checklist above, testing a restoreo a SharePoint 2007 site collection or even the wholearm is always a good idea. True, it will take a number ohours to confgure one or more new virtual or physicalservers and then install SharePoint and restore the site


3/6

collections or databases, but then IT will know it worksand hopeully overcome any issues encountered alongthe way. A test environment is oten recommendedwhen organizations are migrating so the productionenvironment isnt impacted.

In-Place UpgradesIts a airly rare situation where an In-Place Upgrade is

the best approach. That being said, it might be a logicalstep to take or certain SharePoint 2007 implementa-tions, where the server hardware meets the rigid re-quirements o SharePoint 2010 and is new enough to bejudged as oering the reliability and perormance thatwill meet the collaboration and document managementneeds o the organization or the next three to fve years.

To consider an In-Place Upgrade, the basic require-ments or SharePoint 2010 technologies need to be metby the existing hardware. These are

Windows Server 2008 x64 or Windows Server2008 R2 x64

SQL Server 2005 x64, SQL Server 2008 x64, or SQLServer 2008 R2 x64 or the database

Service Pack 2 or WSS 3.0 and MOSS 2007

In many cases, the existing SharePoint 2007 hardwaredoesnt meet these requirements, so the option or theIn-Place Upgrade is o the table rom the beginning.Note that SharePoint 2010 has higher recommenda-tions or RAM and processor capabilities that can alsoprovide challenges, as Figure 1 shows. In many caseswhere the SharePoint 2007 arm was confgured basedon recommended Microsot specifcations several years

ago, these recommendations might not be met. Theproducts supported by Microsot or In-Place Upgradesinclude the previous versions only, as Figure 2 shows.

Finally, the risks involved in perorming an In-PlaceUpgrade generally outweigh the benefts. The basicrisk is a ailure during the upgrade process, which canhappen even in a relatively simple or small SharePoint2007 environment. Even i the In-Place Upgrade goesperectly, legacy code will still be on the server, whichcould cause uture problems. For these and otherreasons the In-Place Upgrade is generally not the bestupgrade option or most organizations.

Database Attach MethodFor many reasons, the Database Attach process is bettersuited or most organizations running SharePoint 2007that want to keep all the data in the new environmentand dont want to change the taxonomy signifcantly.Due to the relative ease o the process, this methodis also well suited to organizations that have timeconstraints and that need to perorm the upgrade overshort periods o time, such as overnight or over a week-end. When the migration takes place its done one con-tent database at a time and its perormed by attaching

the content databases rom the SharePoint 2007 arm tothe new arm and then perorming the upgrade.

IT has the opportunity to install newer, typically morepowerul hardware to run SharePoint 2010 and therebygain perormance benefts. In addition, you can con-fgure the SharePoint 2010 arm rom scratch to meetbest practices and leverage many o the new eatures inSharePoint 2010, such as managed accounts.

Also, the new SharePoint 2010 servers contain nolegacy code, which many purists preer. And knowingthat the server has been reshly built and confguredor SharePoint 2010 use helps many SharePoint armadministrators sleep better at night.

Note that in the Microsot o cial steps (http://technet.microsot.com/en-us/library/cc262483.aspx),the Database Attach Method involves confguring thenew SharePoint 2010 arm, then detaching the contentdbs in SQL Server Management Studio, and then takingthe arm o ine. Then the content dbs are attached inSQL Server Management Studio or the new SharePoint

2010 arm to upgrade the content. As the next sectionpoints out, one the Microsot hybrid upgrade methodscan reduce the down-time when compared to the pureDatabase Attach Method.

Visual Upgrade OptionVisual upgrade is an option in SharePoint ProductsConfguration Wizard or both the in-place or DatabaseAttach upgrade, where the administrator can chooseto keep the existing look and eel o SharePoint 2007sites or upgrade to the SharePoint 2010 look and eel. Insome cases, it makes sense to not immediately upgrade

to the new SharePoint 2010 look and eel because endusers might not have been trained on the new eaturesand interace, or because IT wants to upgrade selectsites to ensure that nothing breaks in the process. Notethat My Sites immediately assume the new SharePoint2010 look and eel, so the visual upgrade options dontapply to My Sites.

Hybrid Upgrade MethodsMicrosot also oers the option o hybrid upgrades,labeling them as the Read-Only Database approachand the Detach Databases approach (see the Technet

URL reerenced in the previous section). As this sectiondiscusses, the Read-only Database approach is really justa slight variation on the pure Database Attach method.

In the Read-only Database approach, the newSharePoint 2010 arm is confgured, then the SharePoint2007 environment is set to read-only, and the contentdatabases are backed up rom the old arm and restoredto the new arm. The databases are then attached in SQLServer Management Studio and the upgrade processruns, upgrading the content dbs. In general, this is apreerred method or perorming a SharePoint 2007to 2010 upgrade. The risks are minimized because the


4/6

SharePoint 2007 arm is let operational and is simply inread-only mode.

The second hybrid approach is the Detach Databasesmethod, where the SharePoint 2007 arm is taken o ine,the content databases are detached, and an in-placeupgrade is perormed on the SharePoint 2007 arm, whichwill upgrade the other databases but not the content data-bases that have been disconnected. The administrator thenreattaches the content databases, upgrading them in the

process. This essentially breaks the process into two steps,which will alert IT to any problems with the upgrade o thenon-content databases prior to attempting to upgrade thecontent dbs.

This second hybrid approach is generally seen as overlycomplex without immediate apparent benefts, becausei the upgrade ails ater the content databases have beendisconnected, the arm will be down until it can be fxed orrebuilt.

DocAve SharePoint MigratorMany organizations take time to investigate third-party

migration tools. There could be a number o reasons or thisresearch; or example, some organizations test one or moremigration methods discussed above, only to fnd that theupgrades or migrations dont complete successully andthen decide to investigate third-party options. Other orga-nizations might have needs not met by the out-o-the-boxoptions, and they look or these eatures in third-party tools.

The ollowing sections cover a number o capabilities pro-vided by the DocAve SharePoint Migrator tools that providevalue to organizations with more complex migration needs.

Support for Multiple Data SourcesA common requirement in many companies is the need to

migrate content rom sources not supported by the out-o-the-box migration tools in SharePoint Server 2010. Asan example, some organizations have multiple versions oSharePoint implemented, and they want to consolidate andmigrate to a single, high-perormance SharePoint 2010 arm.Such a migration is complex without the aid o third-partytools. Take or example an organization with a WSS v2 arm(Farm1) and a SharePoint Server 2007 (MOSS 2007) arm(Farm2) that wants to consolidate content to a SharePointServer 2010 arm (Farm3). An out-o-the-box upgrade wouldrequire frst upgrading the Farm1 WSS v2 to WSS v3, thenupgrading WSS v3 to MOSS 2007, and then upgrading that

to SharePoint Server 2010. And thats just Farm1. Farm2would need to be upgraded to SharePoint Server 2010, andthen the content needs to be migrated rom Farm1 andFarm2 to Farm3, which requires additional steps. Throwinto the mix a need to migrate content rom ExchangePublic Folders, one or more fle shares, and content in otherthird-party document management or enterprise contentmanagement (ECM) tools such as Documentum or LiveLink,and the process becomes even more complex.

The DocAve Migrator product amily supports the ollow-ing data sources:

SharePoint 2001

Windows SharePoint Services (WSS) v2

Microsot SharePoint Portal Server (SPS) 2003

Windows SharePoint Services (WSS) v3

MOSS 2007

Exchange Public Folders

File Systems and Networked File Shares

Documentum eRoom v6.0 and above

EMC Documentum v6.5 and above

Lotus Notes v.6.5 and above

Open Text Livelink 9.5 and above

Open Text Vignette v7.x and above

Oracle/Stellant v7.x and above

DocAve products support the ollowing migration targets:

WSS v3, MOSS 2007

WSS v2, SPS 2003 (or Exchange Public Folders and

SharePoint 2001)

Microsot Exchange 2007/2010 (only or the LotusNotes to Exchange Migrator tool)

SharePoint Foundation 2010, SharePoint Server 2010

Note that the appropriate combination o DocAve clientsmust be purchased and installed and you need to budgetor those costs. The DocAve administrative console must beinstalled, and the agents must be installed on one sourcearm server and one destination arm server. To oset thiscost, typically the costs o outside consulting or increasingsta ng levels during the migration project are reducedby use o DocAve migration tools. The dierent DocAvecontent migration modules are available or evaluation pur-poses to test with limited amounts o data (generally 1 GB),which is helpul, because try beore you buy is a key step inproduct evaluation.

DocAve SharePoint Migrator WalkThrough

This section provides an overview o the process you needto go through once the DocAve tools are installed on thesource and destination servers. The basic options that areaccessible to the administrator are SharePoint 2003 to 2007,

SharePoint 2003 to 2010, and SharePoint 2007 to 2010modules. For this guide, Im concentrating on SharePoint2007 to 2010 migrations. Ill review the tools needed tobuild a migration plan, as well as some o the more poweruleatures available rom the Mapping and Filter tools.

Much o the magic happens in the Plan Builder (Figure3). As the name suggests, the Plan Builder lets you confgurethe details o the migration. You can schedule the migrationto run later, or immediately. DocAve allows or the defnitiono Filters and Mapping Settings separately; these defnitionsare then reerenced rom the Plan Builder. This approach lets

Figure 2: Products Supported by Microsoft for In-Place Upgrades


5/6

you confgure these standards separately and reuse them inthe Plan Builder, rather than having to defne all these vari-ables repetitively. The ollowing section walks through theprimary capabilities o these tools.

Figure 3 shows the Migration Settings tab in the PlanBuilder. The interace is intuitive, with the source contentdeined in the let-hand pane, and the destination deinedin the right-hand pane. You simply choose which site col-lections, sites, lists, or even items that are to be migrated.

Then you select a destination or the items. Figure 3shows an example where three sites rom the sourceSharePoint 2007 arm are selected and will migratedbeneath a subsite (subsite1) in the destination SharePoint2010 arm. Note that you can migrate the source sites tospeciic content databases, which you can also set romthis interace.

You can then schedule when the job will run; or example,you can schedule the job to run late at night, or you canclick the Run Now button to run the job immediately. Endusers wont be impacted because SharePoint object modelis used or all activities, so downtime is typically not needed.Note also that you can schedule jobs to run at predefned

intervals (such as weekly) on a Full or Incremental basis. Manyorganizations fnd value in being able to migrate a portion ocontent, test the results, and then migrate any changes aterthrough testing; or example, a week later. The Incrementaloption allows or this level o migration.

Links are provided to the Filter and Mapping tools, aswell as shown under the Migration Settings tab in Figure 3.Mapping setup confguration provides options in the ollow-ing areas:

Common Settings

Site Collection / Site

List

Permission

Alerts

Characters

Permission Confguration

List Level Confguration

Site Level Confguration

While I dont have room to review all these options, some keyoptions in the Mapping Setup let you make the ollowingdecisions or modifcations:

Preserve the look and eel o existing SharePoint sites,

and allow end users to update their sites user experi-ence. This lets you set the Visual Upgrade settings romthe DocAve interace.

Restore all permissions, only site permissions, only

list permissions, only older permissions, only itempermissions, or do not restore any permissions. Thesedierent options let you determine which combina-tion o permissions are restored. In some cases, the useo unique permissions on items, olders, or lists cancause administrative headaches, and IT might want tosimpliy overall governance o SharePoint by no longerallowing or enorcing item- or older-level permissions.

Migrate alert o the list, library, older, item, and docu-

ment levels.

Set maximum length o the SharePoint URL, older

name, or fle name. Out o control URLs can causeproblems and IT might use the migration process totruncate these.

Map to a new destination domain name. Reorganiza-

tions or acquisitions might require a change in domainname, which is easily mapped during a DocAvemigration.

Map source users to new destination names. User

names might also change when migrated to a newdomain, which is also easily confgured.

Change source columns to a new column type, such

as a Managed Metadata column on a list level or ona site level. A key list that is used by many users on adaily basis can be tuned or modifed to comply with

Figure 3: DocAve SharePoint Migrator Plan Builder Screen


6/6

best practices (such as replacing a Single Line o Textcolumn with a Managed Metadata column).

Replace a source template ID with a new template

ID on a list or site level. This could be used to changesites created rom a Team Site template to a custom-ized template to add unctionality to correspondingsites.

Filter options include:

Time Range settings based on created time or modi-

fed time

Version flters to set the number o versions captured,

and whether major only or major and minor versionsare captured.

Although this partial list o Mapping options and Filteroptions might seem overwhelming or organizations want-

ing to use the migration process as a means o cleaning upthe data that ends up in the SharePoint 2010 lists and librar-ies, they can be very valuable. By using the flters, IT couldmigrate content that has been changed in the last two yearsto a new production site, migrate older content to an archivesite, and thento urther reduce total data migratedmigrate only the last major version o documents.

As youll also see in in Figure 3, the Plan Builder providesseveral options or managing archived data. I the DocAveStorage Optimization tools were used to archive data, youcould migrate this content without needing to frst restoreit to the SQL Server content databases. This is also true i theyou archived content by using the ree DocAve Extender.

The DocAve Extender o oads SharePoint BLOBs to fle-based storage and utilizes Microsot EBS and RBS interaces.Once in SharePoint Server 2010, you can then migrate romEBS BLOB API technology to the newer RBS technology onSharePoint Server 2010 or content externalization.

Reporting on the results o the plan are very exible, andthe logs o the migrations are quite detailed. This allows IT tobe alerted when migrations fnish, and fnd complete detailso the migration rom the DocAve interace. Figure 4 showsthe basic job detail available rom the Job Monitor ater ajob has run. Note that the basics o the job are summarized,such as start and fnish time, as well as type o migrationand results in terms o site, web, lists, and items migrated.

Clicking on the Detail button lets you peruse the results itemby item, which can be very valuable when youre migratingmission-critical data.

Note that in these discussions o the DocAve Migratortools, no mention was made o In-Place Upgrades, DatabaseAttach Method, or Hybrid upgrades and migrations. DocAve

needs a source (which can be a variety o products, as dis-cussed above) and a SharePoint 2010 arm (or other target,as discussed above) and then its engine takes care o migrat-ing the content to its new home without orcing additionalwork on the part o the IT team responsible or the migra-tion. The new source does need to be confgured and readyto receive content, but the DocAve migration tools make thisvery easy and intuitive. Should the organization choose tocull or trim older data, or reduce the number o versions odocuments migrated, or change templates used, or levels opermissions migrated, these options are all possible throughthe DocAve tools.

Going ForwardA basic set o preparation tasks to perorm prior to an up-grade or migration to SharePoint 2010 are provided, alongwith the hardware and operating system requirements or

SharePoint 2010 that IT should be amiliar with beore em-barking on a SharePoint upgrade or migration. By perorm-ing these tasks and being amiliar with the requirements orSharePoint 2010 IT can start to get a sense o the organiza-tions best migration and upgrade path.

Ive provided a solid grounding in the out-o-the-boxupgrade and migration options. Ive also discussed the o -cial Microsot methods and reviewed the DocAve SharePointMigrator toolset with an eye toward the tools that you wouldhave at your fngertips.

For organizations with smaller, simpler SharePoint 2007implementations, the hybrid Read-Only Database approachis typically the recommended method rom my experience

because its the least impactul on the source data. Shouldthis process ail, or i an organization realizes that the moresophisticated toolset provided by AvePoint in the DocAveSharePoint Migrator product would ease the migration pro-cess, I recommend that the product be evaluated and tested.

Colin Spence, an MCP and a MCTS in SharePoint and aPartner at Convergent Computing, perorms in the roles oSenior Architect, Practice Manager, and Technical Writer orthe organization. He ocuses on the design, implementation,and support o Microsot-based technology solutions, with acurrent ocus on Microsot SharePoint technologies. He hasbeen implementing SharePoint-based solutions since 2003

and has over 20 years o experience providing IT-relatedservices to a wide range o organizations. He has workedwith AvePoint products since 2007. Colin has authoredseveral best-selling books on SharePoint products, includingSharePoint 2010, contributes to numerous publications andspeaks regularly on SharePoint technologies.

Figure 4: Job Detail Viewed from the Job Monitor

0211 Essential Guide Migrating it Content

Documents

Transcript of 0211 Essential Guide Migrating it Content