uff, my favorite problem. ;-/

1) Yes a database is a database, probably.... but no concrete5 won't have any idea what to do with your joomla database. So you might be able to run the old joomla site and the new concrete5 site on the same web space. You could have two different databases and just deal with a hybrid install where the products were running out of Joomla and the rest of the content was in concrete5. This generally sounds like a nightmare to manage, but there's been cases where we've cooked up similarly architected solutions. We once built a Magento/concrete5 hybrid where the products, cart, and checkout were all magento and the rest of the site was concrete5. We even hacked some single signon solutions...
It works: http//barefootbooks.com It wasn't easy.

2) There can always be a programming solution but it is hard to know which is the better bang for your buck. Likely what you're talking about is outputting the content as XML with a custom script (perhaps something exists for joomla that would work as a starting point, but its hard to not see a few days of a bright programmer tinkering involved)... Then you're going to have to import that XML into concrete5, again perhaps using a starting point as there's an ecommerce csv import, there's a API you can use to generate pages, etc... Regardless, I'd budget a week or two of a bright programmer tinkering around.

Then you have cross linking and image issues. So if Product A links to Product B in your source data, you're going to have to keep track of that link and do a second pass after the first pass import into concrete5 (as there is no product B when you import product A). You're going to have similar issues with any linked resources like images or PDFs..

oh and you might want to think about legacy URLs and redirects along the way, chances are your client will want the old URLs to point to the new pages so building a htaccess file as you go would be handy.

You may run into timing issues as well. If they're actively using/adding to this database while someone's working on all of this, you're basically going to have to either stop that or build and test it all as a dress rehearsal and schedule some fancy running of it with a QA period after..This is all about people and process but certainly impacts costs and approaches...

Additionally, you're going to want to do QA on that. It's quite feasible that things will go wrong that you can't predict, that's life. Now you're doing it 1,800 times, so count on it. Someone should really go through and make sure each one looks accurate, or be okay with discovering later that a stray quote made some product description die half way through a paragraph.

That's your basic approach on importing something like this. Hard no fun expensive work with lots of potential to go wrong and the best result being "yeah this looks like what we had before..."

Sometimes it's just gotta happen though.

So given that.. Sometimes we look at this type of problem and ask hard questions about approach. Any bright programmer will always want to design a sexy new shovel before they just want to start making a hole with the old rusty one, but depending on the size of the hole you might be better off just digging in. 1800 records is a lot, but its not 180,000. You might do some math like this:

1800 products
10 minutes per product to cut and paste its content from one window to the other by hand.
18000 minutes / 60 = 300 hours @ $15/hr highschool intern = $4,500 + margin for qa, mgmt, coffee and sanity = $5-6k to do it by hand and have had a human look at each page. Who knows what else they might find off in the source data, and what other bright ideas they might have along the way...

Even at 15 minutes per product you get to $6,750 with no margin for coffee/mgmt
Very little risk beyond the intern quitting.

Vs. import scripts
30-60 hours of a bright programmer (can't really tell how long without spending more time in the details)... maybe you're paying them $100/hr (for easy math) = $3-6k to get the script working at all, hopefully but plenty of risk here, could easily take 80+ hours and now yer at $8k...
Then you have to do QA - maybe the programmer gives you a nice list to click through so its really just 2 minutes per page and you have the same type of intern do it... $1,000

Plus some management... you're looking at similar efforts, but higher risk for the import.

Now if you have tens or hundreds of thousands of records to import, that same math makes the answer clear.

Also bear in mind I'm totally spitballing on both. If these products are super complicated importing might be weeks not a week or two... Super simple and I might be over thinking it.

Wish I could give you a better answer, but this has been my experience on this type of thing. No one is jazzed. No answer is a slam dunk.

> Any bright programmer will always want to design a sexy new shovel before they just want to start making a hole with the old rusty one, but depending on the size of the hole you might be better off just digging in

You really like your shovel metaphors lately ;)

Anyway, completely agree with what was said there. It really does depend, another thing is that frequently when moving across CMS's your themes change and things like that, so if you're using HTML for any of your content, there can be a decent likelihood that that sort of stuff might break on a page by page basis when you do a content import, so even if you do get a programmer to import, you're still going to want to do some grunt work doing verification. Then again, if you can get a programmer to do a rough import of all 1800 pages within 10ish hours, then send your intern or high school worker through with a spreadsheet and a checklist, you might get the best of both worlds.

That said, I've done a couple sites now that had 200-300 products all on static html pages, and I went ahead and made the decision to manually do them myself rather than trying to parse html. Took me about 2-5 minutes per product but I was sure it was going to be done right and that I wasn't missing some obscure bit somewhere that would bite me later.

Many thanks to Franz for such great detail, and to Joe also. Just to clarify:

This will be a responsive C5 site - a custom build from PSD templates by an über-talented graphic designer. Not more than about 25 pages if you exclude database-driven product pages that are assembled dynamically. Three or four polished PSD designs will inform the look and feel of all the other pages, so I guess you could call it a templated approach with lots of flexibility. When we need a custom block we'll build and test it in Espresso, then bring it into C5, sometimes via Designer Content.

No importing of content; we'll gather and place that manually. Only the need to re-use the existing Joomla product database, if possible. It's tempting to try a hybrid approach or custom programming of a translation filter, but I can't help feeling like a fresh start (re-entering product text - and images too, unfortunately) will give the client the greatest flexibility and value over the long term...

And of course that's part of what we're selling when we advocate C5, anyway. We'll impress on the client that whatever the solution, we need to think it through and do it right the first time — their first comprehensive rebuild [of the original Joomla site] should be their last comprehensive rebuild.

In any case we continue to welcome add'l thoughts on this. Thanks!

Charlie

@EC Game on, I'm a sucker for a mixing up strained metaphors when
navigating tough beasts.
;)

@charlie
If you know you're going to need new images to fit the new design, and
you're not importing some functional data that is important (prices,
historical records, complex meta data), at a few thousand records, go for
the cut and paste.

Less risk, more time with the actual product (your content...)

Many thanks to everyone for your input and ideas. Senior dev Will Woodgate (you may be hearing from him when/if he decides to build C5 blocks and themes) had a *brilliant* idea. Sharing it in case it helps someone w/ a similar prob. If anyone has follow-on thoughts about this solution, please feel free to opine.

We've opted for doing all-new data entry - via a custom block that will have toggle functionality. How it works:

We have a Product Grouping page, essentially a grid of multiple boxes that groups similar products as a family. Clicking one takes the user to a Product Detail page.

By designing a custom block that displays a button that toggles users between the Grouping page and the Detail page, we'll be able to enter ALL details about a product one time (simultaneously creating the database entry). At the front end, users toggle between the two views, and voila...

This also makes it easy for the client to add products — and more importantly it eliminates damage they could do if they were adding products themselves via SequalPro! :-)

Hope this helps. Add'l thoughts welcome.

Cheers,
Charlie

Please watch this discussion :http://www.concrete5.org/community/forums/promotion/mage5-cms-solut...