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
On Friday, April 11, 2014 6:42:50 PM UTC-4, Richard Hauer (5 Limes) wrote:
>
> 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] <javascript:> [mailto:
> [email protected] <javascript:>] *On Behalf Of *Jian Huang
> *Sent:* Saturday, 12 April 2014 3:35 AM
> *To:* [email protected] <javascript:>
> *Cc:* [email protected] <javascript:>
> *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] or go
> to www.siteport.net.
>
>
>
> Alex
>
> http://siteport.net
>
>
>
>
>
> On Tuesday, April 8, 2014 10:44:39 AM UTC-7, Jian Huang wrote:
>
> 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
>
>
> On Tuesday, April 8, 2014 12:18:02 PM UTC-4, Joel Kinzel wrote:
>
> 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.
>
>
> 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] <javascript:>.
> To post to this group, send email to [email protected]<javascript:>
> .
> 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.
