Moving an existing site over to an e-commerce platform

[Jonpolygon]

This is kind of a three part question. I am hoping that someone could offer advice regarding porting over an existing site to an e-commerce platform solution, what they see as the pros/cons and which e-commerce solution might be of greatest use to us.

We have been running our e-commerce site now for over 3 years, obviously a lot has developed since then. The site is completely custom built, this has offered many incentives over the years as it has allowed us to implement new customized features. Since developing the site we have been watching services like Magento and osCommerce develop and grow and I want to explore this further.

Currently we spend a great deal of time and money on custom site developments, this can also get a little messy.

Has anyone had any experience porting a site over in this fashion, if so how easy/hard is this (I know it probably depends on the complexity of the site in question, but does anyone have any examples that went well/bad)? I have read a lot on different e-commerce platforms and now my mind is boggled. Ideally we want something which is still easy to customize, certainly the ability to add in features at the click of a button (or at least without going in and changing the whole architecture of the site or the feature to get it to work). Also we would like a solution which offers a lot of options in terms of cart integration, currently we use PayPal and custom payments through our merchant bank.

 

[MartCactus]

For our shopping cart we have a "data tool" that helps customer migrate their systems - both from earlier versions of our software, but also from CSV or other data files.

We've used this in the past to help customers transition from other systems.

One caveat - generally migrating product data isn't so bad, as most carts tend to ultimately store the same kind of data, even if they format it in different ways.

But migrating over historical customer data (eg like past orders) is often impossible - at least with our system - as we store those past orders broken down into individual invoice rows, and quite often the data we're importing just doesn't have that much detail.

So the amount of data you'll be able to migrate will depend on how much detail your current system stores in the database, and how much is required by the system you decide to migrate to.

There is also the cost to consider - migrating data is quite costly. Generally you've have a dry run phase where you take the data from the old site and then migrate it to the new system, noting exactly what changes you have to make, and where necessary writing macros or other code to help. Then you do a final dry run, to make sure you can complete the process in a reasonable time, and then set a day where you take the live site offline, migrate to the new one and reopen.

 

[Connexions]

Hello Jon,

We regularly port an ecommerce system over to the one we use (zencart). As long as everything is done to avoid loosing traffic, then they have ported over fine and continued as successful and growing business's. Obviously you have to be careful about loosing your organic google rankings, and hopefully replaced with new and better rankings.

If you would like a chat about it, please feel free to call us (office hours) or email.

 

[Jonpolygon]

Thank you for your replies.

Our database certainly contains a lot of data and I can certainly see that transitioning will be no easy feat. I think it would be great for us to do a few dry runs and see how this pans out, it would also be fantastic to get access to the databases that Magento or another cart databases, this way we can see the differences between how these databases are structured compared to our own.

Obviously you have to be careful about loosing your organic google rankings, and hopefully replaced with new and better rankings.

I agree and we certainly do not want this to be a downside. We currently have over 400,000 pages in Google, this is something we do not want to see reduced.

generally migrating product data isn't so bad, as most carts tend to ultimately store the same kind of data, even if they format it in different ways. But migrating over historical customer data (eg like past orders) is often impossible

I can see how this would be the case. In fact I do see how product data could cause issues also. We store numerous file types associated to products in different tables, I am pretty sure that this wont be the same method as other carts, especially as they may not store file version types etc.

I take it that it may be possible to add additional fields to certain cart tables and use this information as well as the standard information provided?

Generally you've have a dry run phase where you take the data from the old site and then migrate it to the new system, noting exactly what changes you have to make, and where necessary writing macros or other code to help.

It could be that we change our databases to reflect the same kind of structure that another cart adopts, we can do this over time without any effect to the service and then transitioning will be slightly easier I would imagine. It is a shame that there is no mod_rewrite style tool for databases, for example tablename x = tablename y and column x = column y, if that makes sense.

 

[MartCactus]

I can see how this would be the case. In fact I do see how product data could cause issues also. We store numerous file types associated to products in different tables, I am pretty sure that this wont be the same method as other carts, especially as they may not store file version types etc.

I take it that it may be possible to add additional fields to certain cart tables and use this information as well as the standard information provided?

It doesn't matter particularly if the data is structured in a different way - the migration can take care of that. What matters is that you have the relevant data in some form.

For example in our software we make a distinction between products and versions. Every product must have at least one version. So imagine you have an album of music for sale eg Thriller... that would be the product, and then you'd have versions of it, eg
- CD
- MP3 download
- DVD
etc

But someone exporting from our system might find the system they are moving to doesn't structure it like this. That isn't a problem, they just export it as 3 separate items
- Thriller (CD)
- Thriller (MP3 download)
- Thriller (DVD)

Similarly we might have the ability to add infinite numbers of product "attributes". Another system might have a fixed number, and add these as extra fields eg ISBN number (for books), etc.

Internally its in the db in a totally different structure, but the end result is the same (well, similar). The same data can be represented in different db structures.

Of course moving your database structure over time to resemble that of the system you wish to move too would certainly make the migration easier.

Generally migration becomes difficult (or even impossible) where you are missing information. Its similar to editing an image... you can always move from a high resolution image down to a lower one - but you can't take a small image 100x100 pixels and blow it up to desktop size without it looking a right mess. Similarly migration is usually possible if you are moving from a system that has very detailed data to one that is less detailed, but its tough to move the other way.

 

[Jonpolygon]

Thanks. Then the first step for us will be to find out how the database of Magento is structured and we will take it from there. Writing code to change column names etc shouldn't be a problem and I am sure we can build our own migration tool for this particular instance.

We are still exploring the adv/disadvantages at the moment and of course what the different carts have to offer. SEO is top of the agenda so a cart that does this well is worth investigating in my opinion.

Having a powerful database which incorporates everything we have will also be very important, it will be equally important to look into solutions which have more than we need to allow us to easily scale later on.

 

[edmondscommerce]

magento's db can be a little tricky to get your head around if you are not used to it.

you might find it easier to migrate your data into oscommerce and then use magento's oscommerce migration tool

 

[Jonpolygon]

Just located the database schema for osCommerce and Magento

magento's db can be a little tricky to get your head around if you are not used to it.

You are not half wrong there, Magento's database is certainly complex, the scheme seems to do a good job of showing how it all works.

Ideally we don't just want to go for the solution that is easy to migrate to, it should be the best for scaling and adding to etc. That said, from the face of it osCommerce would be easy to migrate to and as it is setup in a way thats easy to understand it would probably be easier to tweak and add to.

One thing I have noticed is that these databases don't seem to be setup for user created product data. Our marketplace is setup so that each product has a product owner who then has permissions to edit and change that. In osCommerce I was thinking this could be the manufacturerID? in Magento I have no idea as it is so complex, any ideas?

 

[edmondscommerce]

thats why i suggested migrating manually to oscommerce and then migrating to magento automatically using the oscommerce migration tool

 

[edmondscommerce]

regarding user created content though, no magento is definitely not created with this in mind and you are going to have a hard time making it work that way.

to be honest, it wont be that easy with oscommerce either.

they both work on the classic paradigm of admin and customers, not customers selling their own stuff.

You might find it easier to move across to a decent CMS with user content features, such as Drupal and use the ecommerce extension that goes with it, such as ubercart

 

[Jonpolygon]

You might find it easier to move across to a decent CMS with user content features, such as Drupal and use the ecommerce extension that goes with it, such as ubercart

Thank you for this, it is something we will explore further.

Again this all comes down to features and benefits of using a certain e-commerce platform. If some things have to be custom built on top then this is not much of an issue as we do expect that in some instances this will need to be done. Ideally we just want to limit adding too much and changing too much which may later effect the core architecture of an e-commerce platform and cause conflicts with updates or plugins.