Upgrade from Drupal 5.x / E-Commerce 3.x

The best place for questions like this is in the issue queue http://drupal.org/project/issues/ecommerce

But the basic answer is that I have not yet developed the upgrade path. The biggest issue is that since a lot of the modules have been renamed I need to find a method of changing the names and then running the upgrade for each of them. I think I need to bootstrap the upgrade process from ec_anon to fix up the system table so that the upgrade can be run, but I have not yet worked that out.

The one thing that I do know is that you will need to be on the latest version of 5.x-2.x to do the upgrade.

The good news is that I am starting a project in the next few weeks which will pay for upgrading ec_recurring and implement recurring payments, which will be a great thing.

If you are able to help with the upgrade process in some way it would be most appreciated.

--
Gordon Heydon

Got distracted for a bit on day-to-day work, plus finalizing the legal stuff on the two little girls that my wife and I just adopted. But I haven't forgotten about this. I'll post my current thoughts, in case they are of benefit to anyone else. Or in case anyone wants to tell me that I'm crazy, reinventing the wheel, etc.

My goals are modest:
1) get enough historical data into the system to create tax/sales reports
2) honor our existing subscriptions, expiring them when appropriate
This means that I don't necessarily have to port every single piece of old data. For example, I don't absolutely have to have all the old Authorize.net transaction ids. I could keep the old tables around and manually dig that out should the need arise.

So, I'm thinking I'll create our new Drupal 6 store from scratch, with all new products and settings, then write a script that imports our old transactions. The script will roll through each old transaction and do the following:
1) if necessary, create an entry in ec_customer for the old uid (see below)
2) create a new transaction, mapping several of the fields (see below)
3) create a receipt for the transaction
4) store the old subscription data (ec_recurring tables) somewhere
For #2, I'll need to make sure to map the product identifiers in ec_transaction_product between old and new values.

I'm still working out the details on #3 and #4. Will post those when I get closer.

Fields for new rows in the ec_customer table
ecid = automatically generated
type = user
exid = uid (assume this is an external id, which we’re not actually using.)
uid = pull from old transaction table
name = pull from users table
token = set to empty ????????????????????

Fields in the old ec_transaction table:
txnid => autogenerated for new transaction
ecid => created as we roll through transactions
type => xfers (all my old ones are “cart”)
mail => xfers
payment_method => xfers
allocation => map from old “payment_status” field
workflow => map form the old “workflow” field
shippable => set to zero
currency => set to USD
gross => xfers
created => xfers
changed => xfers
duedate => xfers
token => set to empty??
additional => set to NULL??

old “payment status” field values:
1 = pending
2 = completed
3 = failed
4 = denied
5 = refunded
6 = canceled
7 = received

New ec_transaction.allocation field values:
0 = pending
1 = partial
2 = completed

Payment_status to allocation field mapping:
1 => 0
2 => 2
3, 4, 5, 6, 7 => 0

Old “workflow” field values:
1 = received
2 = invoiced
3 = shipped
4 = awaiting response
5 = canceled
6 = completed
7 = security violation

New “workflow” field values:
0 = In Progress
1 = Complete
2 = Canceled

Mapping of old to new workflow fields (I'm only mapping values actually used in our db)
1 => 0
5 => 2
6 -> 1

Heh. Sounds like my timing is as good as ever. :-)

I'll give the upgrade process a try on our data and let you know how it goes.