RedDot migration to Drupal - anyone?

[wsfn]

I've just been given the heads up that in 1 or 2 years we'll be
migrating to Drupal. Has anyone worked with a RedDot 10 to Drupal
migration and have any resources or advice to get started? I don't
want to be blindsided if at all possible. It might be we can be doing
stuff now that will improve our changes of success later...

Thoughts, links, suggestions?

~F

[kimdezen]

In a nutshell.. manual process!!! Completely different platform/
technologies - you wont be able to resuse anything unfortunately.

You will have to build up your site from scratch in Drupal and then
import then content in by hand out of RedDot

[Andreas Thumfart]

I don't know anything about Drupal.
But a few months ago we migrated to another system by publishing xml files and importing these files into the other system.
That means you "only" have to create the templates and structure in the new system and can import the content from the old one.

[JJB]

How was the process? I am facing the same issue.

Was is a manual or automatic process?

[Joel Kinzel]

Check out site  siteport.net, I got a random e-mail from them not too long ago. It looks like their tool is able to migrate OT to a variety of different CMS systems.

[Jian Huang]

Ahh, siteport.net.  Personally, I think they are cashing on the catch phrase of "linking into existing CMS".  It is not needed.

1.  One can make a new project variant, and have CMS publish the existing content out in XML format.  Then use any existing FREE drupal migration tools to import the XMLs.

2.  Why even go into CMS?  You have the published HTML files, use an HTML to XML converter, then use any existing FREE drupal migration tools to import the XMLs.

-Jian

[Joel Kinzel]

Good to know. I never thought of the XML variant! 

[Richard Hauer (5 Limes)]

** This got misfiled by my email as a new thread **

Was just speaking to Siteport last week. This is what they said...

"Currently, Siteport’s target connectors include Sitecore, EPiServer, and OpenText(RedDot) - with Adobe CQ and Drupal on the roadmap to be added soon."

So you might get lucky with your 1-2 year timeframe.

While migration tools can be useful for extracting a volume of content, you will end up with a non-best-practice Drupal project as a result. You need to evaluate the  capabilities of the new CMS and rebuild your site accordingly. There is no push-button solution.

I have no personal experience with Drupal, but I'm sure its strengths and weaknesses are quite different to RD.

Richard.

[Alexandra Barcelona]

Hi Jian,

Alexandra from Siteport here :) You've brought up some good points, but there are several reasons why we connect to the source and target CMS for migrations:

- By connecting through the API, we're able to maintain the hierarchy of the pages (e.g. we know the parent/child relationships)

- We're also able to maintain componentization (in OpenText's case, we know which components are within each container and what their order is)

- We're able to maintain links between pages and to images within rich text fields by knowing their internal links instead of the published link locations

- We're able to migrate all metadata (categories and keywords)

- In some cases we're even able to migrate workflows and authorization package information

- Last, we can do all these things while reducing the content freeze window for content editors to something as small as a single day. They can continue to edit content while the migration is being set up and tested.

None of these would easily be possible with an XML export or publish of the content from OT WSM.

That's all for my shameless self promotion :)  

If you want more information, please email us to in...@siteport.net or go to www.siteport.net.

Alex

http://siteport.net

[Jian Huang]

Hi Alex,

Glad to have you here to answer some question.  I apologize in advance if my questions and responses may convey a negative tone, I am simply approaching this from the perspective of a potential customer's IT department.

- By connecting through the API, we're able to maintain the hierarchy of the pages (e.g. we know the parent/child relationships)

Don't need the API, with the published pages, one can use http://www.coffeecup.com/sitemapper/ or a free sitemapper to create IA of the entire site.

- We're also able to maintain componentization (in OpenText's case, we know which components are within each container and what their order is)

Drupal and OpenText WSM are different products, componentization should be done differently.  A one to one translation will result in a sub optimal implementation.  Should one still wish to go ahead, converting HTML to XML can still keep the componentization information.  After all, it is just data and structure, either represent it in memory within siteport or XML, it really doesn't matter.

- We're able to maintain links between pages and to images within rich text fields by knowing their internal links instead of the published link locations

The link conversion will need to happen either way, CMS to Drupal, or static to Drupal.  One will come with siteport, the other one will need to be created via a custom post import process.

- We're able to migrate all metadata (categories and keywords)

Metadata  (categories and keywords) is just information, like the text and images on a site,  If it is in the HTML (even hidden), it can be converted from HTML to XML.

- In some cases we're even able to migrate workflows and authorization package information

Workflow and authorization depends on user and user group, will existing users and user groups be migration?  Even LDAP users?  What functionality will I gain/lose with the Drupal workflow and authorization?

- Last, we can do all these things while reducing the content freeze window for content editors to something as small as a single day. They can continue to edit content while the migration is being set up and tested.

Converting the published HTML to XML has no impact on the content editors, so with the HTML to XML method, there is almost no content freeze either.

So far, the estimated cost for the HTML to XML method is $35 + 160 hours for a 10000+ pages site with 10 unique templates.

What is the cost of siteport in this case?

Best,

-Jian

[Richard Hauer]

Actually Jian, there’s one bit you’ve missed there.

 

Siteport claims (I haven’t used it yet) to not only export, but import as well.

Your “competitive analysis” only covers the export side.

 

I have taken this exact approach for converting an OT project before – the XML approach – and in 80 hours we converted over 100 templates to XML.  The publishing is then trivial.  The problem becomes the massive volume of code needed to import that in a sensible way on the other side.

 

So while I agree there is little value in buying Siteport to simply export XML, it makes a better value proposition when you consider the cost of building, testing, and executing the import.

 

And while you’re running that import, you’re authors are under code freeze – typically for at least a week while you iron out all the bugs and remake connections (on the remote side, not the XML).

 

PS.  At 80 hours of effort, the client is still up for $12k (AUD) at least; assuming they don’t have internal resources capable of doing the job, which might halve that cost.  Still the effort isn’t free and you’ve still got half the job to go.

 

 

Rich

(Devil’s advocate, on this occassion)

--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reddot-cms-use...@googlegroups.com.
To post to this group, send email to reddot-c...@googlegroups.com.
Visit this group at http://groups.google.com/group/reddot-cms-users.
For more options, visit https://groups.google.com/d/optout.

[Jian Huang]

Hi Richard,

Yes, I only covered the export portion.  For import, there is Content Import Manager (CIM) that comes with the product.  No entirely free, but it might also be really price competition.  Note CIM only does bulk import, it doesn't do import based on structure.  The structuring part will need to be manually applied, though not much work, like 30-60 minutes max, but it is still nice to see another product that can save time on the post import process.

For the 160 hours I have estimated,

    - 80 hours for gathering/building the set of tools, refining the import process

    - 80 hours for post import configuration and clean up.  That is where I would like to learn how siteport would make this easier.  Assuming siteport will require configuration too, would it take less than 80 hours from start to finished project?

Scale-ability

    - first project 160 hours

    - projects after, 80 hours each

Content Import Manager can process 5-10 pages per second.  Impprting 10000+ pages will take 15-30 minutes?  15-30 minutes of content freeze ins't bad.  Users can still modify existing content, while the other team refine the import process with slightly outdated data.  When ready, just generate a new set of XML and import, hence I don't expect code freeze period to be long at all.

Content export and import is not difficult.  The most time consuming part is understanding the process and define it down to a repeatable science.  If siteport can assist in managing that part and really take the human (errors) out of the equation, then it is a true groundbreaking innovative product.

Best regards,

-Jian