Is it possible to migrate data between any two of the most popular open source CMS systems?
August 16, 2004 12:42 PM Subscribe
Is it possible to migrate data between any two of the most popular open source CMS systems? {The reasons for this rather odd request follow}
I am bidding to build a client´s site using Typo3 CMS. However, they are concerned that at some point of the development we might hit an (at present unknown) snag. In order to put their minds at rest, I am trying to find some CMS software which would allow me to switch horses in the middle of the stream, if need be. Ideally, it would be some well known, enterprise-level CMS packages.
I am bidding to build a client´s site using Typo3 CMS. However, they are concerned that at some point of the development we might hit an (at present unknown) snag. In order to put their minds at rest, I am trying to find some CMS software which would allow me to switch horses in the middle of the stream, if need be. Ideally, it would be some well known, enterprise-level CMS packages.
Response by poster: i_am_joe's_spleen: you're right, of course. The client is antsy, I'm trying to mollify them, that if at some (unkown, undefined) point we run into X problem, we won't be completely screwed. Which of course I can't 100% guarantee, so I'm trying to say "look, worst case scebario, wew can always jump ship to...."
posted by signal at 3:35 PM on August 16, 2004
posted by signal at 3:35 PM on August 16, 2004
If you say "we can always jump to system X", your client might well respond: "why not do it in X in the first place then?" Offering an alternative solution in case of trouble indicates a lack of faith in your chosen platform. You need to demonstrate that you will not get into trouble in the first place.
Your client is antsy. If you don't know WHY they're antsy, you can make them even antsier with a response that doesn't address their real concerns. If I understand you correctly, you want to say: "If anything goes wrong, we'll change CMS". That isn't necessarily much of a solution to a lot of problems, and it sure doesn't inspire confidence.
If I were you I would be trying to weasel their specific fears out of them. If they're worried about you personally, find referees, and emphasise the resources you can call on to work with you. If they're worried about Typo3, find reference sites. If they are worried about integration with a legacy system, offer a proof-of-concept deliverable that demonstrates integration. Etc.
Returning to your specific question, any CMS that allows you to extract templates, stores docs as XML or other parseable markup, and has good metadata is as good as another.
posted by i_am_joe's_spleen at 4:20 PM on August 16, 2004
Your client is antsy. If you don't know WHY they're antsy, you can make them even antsier with a response that doesn't address their real concerns. If I understand you correctly, you want to say: "If anything goes wrong, we'll change CMS". That isn't necessarily much of a solution to a lot of problems, and it sure doesn't inspire confidence.
If I were you I would be trying to weasel their specific fears out of them. If they're worried about you personally, find referees, and emphasise the resources you can call on to work with you. If they're worried about Typo3, find reference sites. If they are worried about integration with a legacy system, offer a proof-of-concept deliverable that demonstrates integration. Etc.
Returning to your specific question, any CMS that allows you to extract templates, stores docs as XML or other parseable markup, and has good metadata is as good as another.
posted by i_am_joe's_spleen at 4:20 PM on August 16, 2004
Response by poster: Just in case you're still reading this, iajs, we got the project! Basically we told the client "this is the best package we can find,no system (this or any other) is 100% foolproof, but being that it works on open standards, we can always switch to another one if we run up a against a solid brick wall".
Thanks.
posted by signal at 1:23 PM on August 18, 2004
Thanks.
posted by signal at 1:23 PM on August 18, 2004
This thread is closed to new comments.
How difficult it is depends on:
- how well structured the source data is
- whether it is kept in an open format (text) or a closed one (some god-awful packed binary).
- whether it is persisted somewhere you can get at it (an RDBMS, individual text files) or not (a big blob of bytes in one file)
- whether the vendor of the source package provides an API for sucking assets out or whether you have to roll your own.
However:
What kind of snags are you talking about, signal?
'Cause usually, when you use a CMS to build a content rich site, the customisation is in the design of templates, the editorial workflow, the user interface for content creation, import routines for content feeds from outside, etc. Unlike content assets, these are usually not very portable. If you're going to switch, you want to do this just before you start implementing these things. Migrating content is one thing, migrating business logic is another.
Logically, the risk of hitting an unknown snag is inherent in any CMS you choose (although it's lower for ones you're more familiar with). So if you encounter snag X with CMS A, and decide to switch to another CMS, who's to say you won't encounter snag Y with CMS B?
I think you need to tease out what specific fears your client has and address those.
posted by i_am_joe's_spleen at 2:30 PM on August 16, 2004