RE: Migrating CMS content from one server to another

"Mitchell, Christine L \(EM, PTL\)" <[email protected]> Tue, 16 Aug 2005 11:15:12 -0400
Newsgroups gmane.comp.cms.cms-forum.general
Message-ID <D08C3E5ECE087D4DA051EA0E8D4258610C93C040@RDGMLVEM01.e2k.ad.ge.com>
You might find this interesting. It's a PowerPoint summary and the final documentation of a migration we did this past winter. Again I must say to anyone who is considering a migration from one CMS to another there is a way to automate some, if not most most, of the migration.  The tools now exist to do this.

Christine L. Mitchell
Penske Truck Leasing
Content Manager
610.775.6494
[email protected] <mailto:[email protected]> 

Tension is who you think you should be. Relaxation is who you are. - Chinese proverb



-----Original Message-----
From: Adriaan M. Bloem [mailto:[email protected]]
Sent: Tuesday, August 16, 2005 9:42 AM
To: Mitchell, Christine L (EM, PTL); 'James Robertson';
[email protected]
Subject: RE: [CMS] Migrating CMS content from one server to another


Well--

I find myself agreeing with both James, Jerry and Christine, a lot of
sensible points were made. Summing up for myself I think the main problems
in using automated migration are: 

- Inadvertently migrating the old structure; it's very hard to migrate
(large amounts of) content without implicitly importing the old structure as
well. In general, content isn't (yet) classified well enough to be migrated
"smartly" to a new location based on the actual content; so if you want to
migrate to a new content (or site) structure, which is often one of the
reasons of the migration in the first place, it can only be automated to the
extent of migrating an item (or a group) at a time (which does not
necessarily mean copy/pasting by hand);

- Breaking the content context, rendering it unintelligible; a content item
may not make sense when taken from its original comfortable environment
(both navigation, design and other content items); so if you do change
structure and move content around, you still have to make sure it's still
understandable in the new context, which again can only be done by hand;

- The content itself may have to be restructured (e.g., when you migrate
from a page-oriented system with lots of embedded HTML to a component-based
XML system, there's no easy solution to classifying parts of the original
file as sensible XML fragments) and in many cases content isn't "clean"
content, it's mixed with design (especially in page-oriented CMS'es were
often text, images and HTML are intertwined, but many XML based systems
don't have a clean information architecture either and XML tags are often
abused as a "higher level" kind of design elements).

Which means the success of automated migration rather depends on the degree
those three problems occur. In my experience, most migrations have to be
done almost entirely by hand, for exactly the reasons James described. But I
always investigate if at least partial automation is possible and what the
outcome of the "time investment in automation vs. time saving in manual
migration" equation is. Ideally, you'd be doing a migration of say, a
database of 20.000 CD's and DVD's in an on-line store that have to be moved
to a new eCommerce system. Then, automated migration makes a lot of sense,
is feasible and worth the investment. Structured sites like those are ideal
candidates.

In the reality of most complex and diverse websites though, I'd be happy to
finally see a situation where even automating the export of content from the
old system would save time over manual cut & paste. Unless the main reason
for a migration is features in a new system or updating the old system, but
the structure and design of the site are fine, and then tools like Exorcist
are great ;)

In short, I'd say automating the migration would be great, if possible. I'd
rather regard the cleaning up of outdated or underperforming content as the
silver lining of a manual migration than see it as a good reason not to
automate. Never just immediately choose either extreme of fully automated or
fully manual though, but investigate options case to case.

Adriaan M. Bloem
__

Project Leader Implementation CMS, ICS Webcommunication,
& Internet Coordinator, Faculty of Law

Leiden University
Visiting address: Steenschuur 25, room C0.13
Postal address: P.O. Box 9520, 2300 RA Leiden, The Netherlands
Telephone: +31 71 527 7897



> -----Oorspronkelijk bericht-----
> Van: [email protected] 
> [mailto:[email protected]] Namens Mitchell, 
> Christine L (EM, PTL)
> Verzonden: dinsdag 16 augustus 2005 14:35
> Aan: James Robertson; [email protected]
> Onderwerp: RE: [CMS] Migrating CMS content from one server to another
> 
> The reality is that meaningful migration of content is almost 
> always cut-and-paste, although automated tools can help to 
> some limited degree.
> 
> I would have to disagree with this conclusion.  I have done 
> both cut & paste migrations and automated migrations and the 
> advantage of a good atuomation plan cannot be pooh-poohed.
> 
> The real issue is that this isn't a technology problem:
> 
> * In most cases, you will be redesigning your site as part
>    of the migration. This eliminates any simple one-to-one
>    mapping of content.
> 
> If you plan properly, you can certainly map from one design 
> to another. We had comment code in place that was used to 
> clip just the content while leaving the old design elements 
> behind. The content was then added to the new design 
> templates automatically. It worked beautifully.
> 
> * You will also want to review all content during the migration
>    to ensure that only "good" content is transferred.
> 
> This is true, but you don't need to cut and paste thousands 
> of documents manually to accomplish this.  Your content audit 
> can be completed before the actual migration takes place so 
> that it CAN be automated.
> 
> * This will involve having someone knowledgeable about the
>    content to assess each and every page. A lot of content can
>    probably be deleted, while other material will need to be
>    rewritten or updated.
> 
> True again. See above.
> 
> Migration of content is certainly the most painful part of 
> any CMS project. 
> 
> Amen to that! 
> 
> What you aren't looking for is an automated way of migrating 
> existing poor-quality content. Instead, use this as an 
> opportunity to review and improve the content, thereby 
> delivering tangible benefits to end users of the site.
> 
> These two goals are not mutually exclusive.  You can review, 
> clean, purge and automate.
> 
> In general, I'm against any form of "automated" migration 
> tools, as it makes it too easy to ignore the content...
> 
> This, of course, has to do with the project manager and the 
> team doing the migration work and their emphasis on quality, 
> not on the method, whether copy and paste or automation. You 
> can certainly successfully automate a content migration, from 
> database to database, from databse to file system, etc., if 
> you lay the proper groundwork.  You will always have some 
> manual clean up even with an automation but it can be MUCH 
> less and much faster to employ some automation.
> 
> Christine L. Mitchell
> Penske Truck Leasing
> Content Manager
> 610.775.6494
> [email protected] <mailto:[email protected]> 
> 
> Tension is who you think you should be. Relaxation is who you 
> are. - Chinese proverb
> 
> 
> _______________________________________________
> cms mailing list
> [email protected]
> Subscription controls:
> http://lists.cms-forum.org/mailman/listinfo/cms
> Netiquette FAQ and related CMS lists - [cms-forum], [cms-pr], 
> [contentmanagers], [cmpros] 
> http://www.cmsreview.com/NetiquetteFAQ.html
> http://www.cms-lists.org
Content Migration Summary.ppt (application/vnd.ms-powerpoint, 646 KB) - not displayed
Migration Documentation Final.doc (application/msword, 38.5 KB) - not displayed