Add existing recurring donations to new CiviCRM install?

[grandesigns]

I am moving a CiviCRM install from one server to another while upgrading to 4.4.4, and have found that my old database is regarded as unfixably corrupt by the new version, so I'm going to have to start fresh. This isn't actually a huge problem, as I use CiviCRM just for processing payments, and not for my long-term record keeping, but it does present one issue, which is this:

How do I recreate the recurring donation profiles for my existing recurring donors? Obviously I can import the PEOPLE themselves manually via the Import Contacts functionality, but the "new contribution" functionality does not include a "recurring" option...

The one thought I've had is to create a NEW recurring payment profile (by making a contribution as a donor), then duplicate it (in the database) and then change its details to match one of the OLD payment profiles I need to carry over. (And repeat until all profiles exist again.)

Before I sink a bunch of time into it, does this approach seem viable to those here? Do you have any better ideas? Thanks!

[mdlueck]

From what I recall checking into this point some time ago, CiviCRM tracks recurring transactions by some transaction identifier. When a recurring notification comes in, CiviCRM checks the table for a matching transaction id, if found then applies said details to the located recurring transaction found.

As for fixing up legacy recurring transactions in a brand new database, several things to try come to mind... I would also be interested in the official correct way to handle such messy tasks.

I am thankful,

[grandesigns]

Update on the above... I have added a line to the contribution_recur table recreating an existing recurring donation. Said donation now shows up properly in the CiviCRM interface, but manually resending the IPN from the last "tick" of the donation results in a 406 error, which is novel and unhelpful.

Advancing on the theory that the 406 error is somehow related to either the fact that the donation was created in a fashion that indicated to CiviCRM that an initial should have already occurred, or that there was no "first" donation in the sequence to pull values forward from, I have tried entering a different recurring donation in the same fashion, but scheduled to trigger tomorrow. I have also manually created a back-dated "first" donation to go with it (and edited its database entry so it shows up properly as a recurring donation associated with the recurring donation in question), so CiviCRM has a reference to look at.

So, we'll see what happens with that.

[grandesigns]

Update to the above... it did not work, but I did not get a 406 error either.

The problem now seems to be that Paypal is returning the old ID of the user in question as part of the IPN - I had expected that the matching was being done via other variables (such as the invoice #) and so hadn't looked for that. So... next experiment is to repeat the prior step, but match up the user's ID as well.

[Donald Lobo]

you have to match up various parameters - including at least one hash that confirms this is a valid transaction from a paypal server (or the relevant PP)

if i had to do this:

a. I would recreate the contributon recur record and other auxilary records

b. I would probably write a new script called matching IPN which matches the old params to the new civi db and basically calls most of the current IPN functions

lobo