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)

 

From: [email protected] 
[mailto:[email protected]] On Behalf Of Jian Huang
Sent: Saturday, 12 April 2014 3:35 AM
To: [email protected]
Cc: [email protected]
Subject: Re: RedDot migration to Drupal - anyone?

 

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


On Wednesday, April 9, 2014 7:16:18 PM UTC-4, Alexandra Barcelona wrote:

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 [email protected] 
<javascript:>  or go to www.siteport.net <http://www.siteport.net> .

 

Alex

http://siteport.net

 

 

On Tuesday, April 8, 2014 10:44:39 AM UTC-7, Jian Huang wrote:

Ahh, siteport.net <http://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


On Tuesday, April 8, 2014 12:18:02 PM UTC-4, Joel Kinzel wrote:

Check out site  siteport.net <http://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.


On Thursday, August 11, 2011 12:18:24 PM UTC-5, wsfn wrote:

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

-- 
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 [email protected] 
<mailto:[email protected]> .
To post to this group, send email to [email protected] 
<mailto:[email protected]> .
Visit this group at http://groups.google.com/group/reddot-cms-users.
For more options, visit https://groups.google.com/d/optout.

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/reddot-cms-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to