Content Migration Roadmap

7/26/2019 Content Migration Roadmap

http://slidepdf.com/reader/full/content-migration-roadmap 1/7

Content Migration - Seven Steps to Success

Migration Roadmap

Contents

Step 1: Determine Business Constraints

Step 2: Determine Approach & Toolset

Step 3: Determine Source Defnitions

Step 4: Determine Target Defnitions

Step 5: Defne Transormation e!uirements

Step ": Determine #$ecution %ptions

Step : 'n(erta)e *igration

Assurances rom +en(ors suggest there are no issues associate( ,ithmigrating content,hen implementing a successul C*S strateg-. The migration o ,e/ pagesor (ocuments into a Content *anagement S-stem0C*S is oten un(erta)enas a last minute e$ercise. i)e man- other aspects o T implementations it isthe correctness an( +ali(it- o (ata entere( into a s-stem that (etermines its

success or ailure. As C*S technologies mature a successul an( pro+enmigration metho(olog- is )e- in (etermining the suita/ilit- o one +en(orspro(ucto+er another.

The concept o migrating legac- (ata is eas- to un(erstan( as is+isualising the en( result. hat pro+es increasingl- (i6cult is un(erstan(ingthe processes in+ol+e( in mo+ing (ata rom a legac- en+ironment into thetarget C*S. A roa(map is nee(e( ,ith simple rules sho,ing ho, (atamigrationis achie+e(. This ,hite paper presents that roa(map an( (efnes the

implementation steps re!uire( in or(er to achie+e a successul migrationpro7ect. The roa(map has a num/er o (istinct steps an( ollo,ing them canensure a successul migration. #ach step8 or pro7ect phase8 has an associate(9o,chart outlining the specifc processes o each.

Determine Business ConstraintsStart o *igrationDetermine Approachoptions an( toolsets



Determine TargetDefnitionsDetermine SourceDefnitionsDetermine

TransormationDefnitions#n( *igrationDetermine Deli+er-Defnitions

As ,ith all pro7ects it is necessar- to outline the migration /usiness case an(the Time8;unction8 *one-< constraints it must operate ,ithin. These constraintsre!uire em/e((ing,ithin the philosoph- o the migration an( are re9ecte( throughout its

operation. The start o the planning process is the time to clearl- (efne themeasurements or success. emem/er that the migration (oes not impingeinto the area o /usiness change = instea( the o+erall /usiness changepro7ect acti+el- sets the /oun(aries o the migration.

Step 1: Determine Business Constraints

Agree Stan(ar(Constraints o Time8;unction an( *one-

>ro7ect DefnitionDocumentStart DetermineBusiness ConstraintsAgree >ro7ectScope imitationsAgree >ro7ectis) ApproachAgree >rogrammempact o >ro7ectAgree >ro7ect

Approach re esourcesStop DetermineBusiness Constraints>ro7ect DefnitionDocument>ro7ect DefnitionDocument>ro7ect Defnition



Document>ro7ect DefnitionDocument

The /usiness constraints al,a-s (etermine the pro7ect approach an( ,hichmigration toolsetto use. the +olume o migrating (ata is high then an automate( approachis nee(e(.Smaller +olumes8 t-picall- less than 5??? pages8 can migrate manuall-.hile /oth manualan( automate( ha+e a num/er o options8 automate( migrations are themost comple$ tomanage successull-.

Asis *igration source pages an( assets migrate ,ith no change to their

nature or a((itional inormation a((e( to their (efnition. #nhance(*igration source pages ha+e a((itional meta(ata properties create(8 otenas a re!uirement o the target C*S s-stem.

Stan(ar(i@ation *igration source pages /rea) (o,n into smaller le+els ogranularit- ,hich migrate an( reassem/le in the target C*S. This is otenreerre( to as appl-ing stan(ar(templates<. estructure *igration as pages migrate the na+igationelements are up(ate( to re9ect a ne, normation Architecture 0A< Theoptions or automate( migrations /rea) (o,n into our (istinct t-pes: t isimportant to ensure the original pro7ect constraints are /uilt

into these (ecisions. As migrations progress the- ten( to attract a gro,ingre!uirements list. This scope creep occurs i the original constraints an( the/usiness re!uirements the- are oun(e( upon are ignore(. t is important totie /ac) the choices or ,hich t-peo migration is un(erta)en /ase( on the original constraints an( the successcriteria (esigne( or them.

Step 2: Determine Approach & Toolset

Agree Defnition o Content>ro7ect Defnition Document

StartDetermineApproach an( Toolset%ptionsAgree Defnition o>resentationDetermine Storage orContent8 a-out an(



ApplicationsAgree A Stan(ar(sStop DetermineApproach an( Toolset%ptions

>ro7ect DefnitionDocument>ro7ect DefnitionDocument>ro7ect DefnitionDocument>ro7ect DefnitionDocumentSelectBuil( ele+ant Toolset an( Suppliers

Step 2.

Agree Defnition o AssetsAgree Defnition o Application>ro7ect Defnition Document>ro7ect Defnition Document

The ne$t step in the *igration oa(map (etermines the ollo,ing )e-source (efnitions:

1. n Scope Domains

2. normation Architecture 0A3. n Scope >ages an( Assets4. um/er o >age Classifcations5. A+aila/le ranularit- /- Classifcation

The business constraints always determine the project approach and which migrationtoolset to use. If the volume of migrating data is high then an automated approach isneeded. Smaller volumes, typically less than 5000 pages, can migrate manually. While bothmanual and automated have a number of options, automated migrations are the mostcomple to manage successfully.

The options for automated migrations brea! down into four distinct types"

#s$is %igration $ source pages and assets migrate with no change to their nature oradditional information added to their definition.

&nhanced %igration $ source pages have additional metadata properties created,often as a re'uirement of the target (%S system.



Standardi)ation %igration $ source pages brea! down into smaller levels ofgranularity which migrate and reassemble in the target (%S. This is often referred toas *applying standard templates+.

estructure %igration$ as pages migrate the navigation elements are updated toreflect a new Information #rchitecture

It is important to ensure the original project constraints are built into these decisions. #smigrations progress they tend to attract a growing re'uirements list. This scope creepoccurs if the original constraints and the business re'uirements they are founded upon areignored. It is important to tie bac! the choices for which type of migration is underta!enbased on the original constraints and the success criteria designed for them.

Step -

The net step in the %igration oadmap determines the following !ey source definitions"

. In Scope /omains. Information #rchitecture 1I#2-. In Scope 3ages and #ssets4. umber of 3age (lassifications5. #vailable 6ranularity by (lassification

The overall compleity of the migration is in part determined by these source definitions.Identifying the domains in scope for migration and defining the structure of the source I# isthe first of five !ey areas.

The third area relates to specific pages and assets. #ll images and documents that lin! fromweb pages are classed as assets and are handled differently within the migration process. It

is essential to clearly identify all in scope pages and assets within each of the domains.

The importance of page classification and associated levels of granularity in a migration isoften misunderstood. 3ut simply, page classification brea!s down structured or unstructured7T%8 large volumes of pages into a number of common areas or templates. (lassificationignores any page furniture or navigation areas and identifies the most common presentationlayer across the migrating content. The volume of pages that fall outside the commonpresentation layer are identified this allows the migration team to planhow to process these non$standard areas most effectively.

Step 4

7aving defined the source definitions it is necessary to match these with the targetenvironment. It is safe to assume that the target system re'uirements are greater thanthose enabled in the source system. The target definitions are"

. /omain 7ierarchy. I# Structure-. Template /efinitions4. 6ranularity Specifications



5. %etadata e'uirements

7ere the specific re'uirements of the selected (%S are defined in detail. These mayinclude naming conventions, ownership, security, epiry dates, classifications ortaonomies. /efinition of the target system determines the etent and nature of thetransformation re'uirements of the source content. 9nfortunately, it is easy to design acomple solution that is impossible to implement successfully.

Step 5 : /efine Transformation e'uirements

7aving defined both the source and target systems it is now possible to design the contenttransformation rules. The rules must address all aspects of the target system as being theprimary recipient of the legacy data. The target system re'uirements always drive thedefinition and design of the rules ; wor!ing bac!wards from the target to the sourcesystem. The approach is to ensure the source data fits the target data and not to changethe target re'uirements to suit the source.

The source system cannot always supply relevant data to populate the target systemcorrectly. In these instances the rule definitions must include effective auto$generation logic.

#n eception handling formula that addresses these instances of inappropriate source dataor incomplete auto$generation is also re'uired.

In a simple eample the target system may restrict the *Title+ field length to less than 50characters. 7ow does the migration transform source titles of more than 50 characters<=ptions might include truncating the *Title+ field length to 50 characters or flagging the dataelement as *not to migrate+ until the correct rule handling is defined.

Transformation rules brea! down into the following !ey areas"

. /omain ame. Information #rchitecture-. (lassification %atch to Template4. 6ranularity (ross %atching5. 3age (hanges>. #sset e'uirements?. (ontent &nhancement

It is important to fully define and test all transformation rules prior to coding. /es! chec!ingactual pages identified during the classification process proves invaluable ; ensuring therules give the epected results when applied.

&ach rule has an associated @erification &ception and (orrection 1@&(2 document. The@&( determines the test verification criteria, the identified eception and the re'uiredcorrective action.

In the previous eample the verification chec!s that the *Title+ field conforms tore'uirements, the eception is a length greater than 50 characters and the correctiontruncates the title to the first 50 characters and deletes the rest. This is incorporated into thetransformation rule action.



Step > : /etermine &ecution =ptions

#s volumes increase the need for eecuting in a number of smaller batches arises. Whilstunderta!ing a migration of one million pages is possible in one large batch operation,implementing the A# function may prove very difficult.

3art of *Step ; /etermine #pproach and Toolset+ identifies the eact A# re'uirements forthe project. #t this stage it is necessary to design an approach that enables the A#implementation. This typically involves brea!ing the migration down into smallermanageable sub$projects that migrate in either a parallel or se'uential manner.If so, it is crucial to ensure that the co$relation of lin! items is maintained across all the sub$projects. The toolset used to automate the migration must support this dynamic lin!handling in order to maintain the target I# structure.

Step ? : 9nderta!e %igration

The actual underta!ing of the migration is now possible. #ll the previous definitions givean operational framewor! reflecting both the source information and the target systemre'uirements. 7aving defined both the *as$is+ and *to$be+ re'uirements, transformation rulesand eception handling, combined with the A# process all the technical elements are inplace to proceed.

If additional facts come to light during the migration eecution, e.g. unforeseen datasupplies or values, this is documented within updated source definitions and captured inmodified transformation re'uirements.

%atching of the final migration output to the success criteria is etremely important. If amigration does fail it is because the previously defined success criteria, based upon the

transformation rules, are not met. In summary, the %igration oadmap is vital toensure project success. With objectives clearly stated and rules clearly defined there is littleroom

Documents

Content Migration Roadmap