CiviCRM Community Forums (archive)

Greetings,

The specs of our existing CiviCRM implementation are accurate in my profile stats. We started out on Civi 2.0.x on Drupal 5. With the long upgrade saga that has brought us to 3.4.8, various things have gotten broken.

Would it be possible to take just Civi "off line", export current data, purge orphan data from the export / clean it up / make minor corrections / and import to a brand new fresh install of the latest Civi 4.3.x series WITHOUT having to take down Drupal? (At least Drupal would not have to be in site maintenance mode for the majority of that process I am hoping.)

I am mostly inquiring / concerned about this integration between Drupal and CiviCRM:

New Member Join Process
Involves connecting together three CiviCRM capabilities:
● Contribution --> http://en.flossmanuals.net/civicrm/ch027_configuring
● Membership --> http://en.flossmanuals.net/civicrm/ch037_configuring
● Profile --> http://en.flossmanuals.net/civicrm/ch012_profiles

The Profile is responsible for creating a Drupal user account as well as
collecting contact information.

Two payment gateways (PayJunction and PayPal) times Membership Duration
possibilities (Yearly / Monthly) = Four Contribution Pages

Is unchecking the Drupal module for CiviCRM "CiviMember Roles Sync" the correct way to temporally breaking the user login link between Drupal and CiviCRM?

Presently I am building a local Virtual Machine instance of the desired new webserver configuration, with a higher release of the Linux OS capable of supporting the latest CiviCRM's requirements. Once that is completed, we may go through this CiviCRM upgrade scenario, and once worked out perform it (hopefully more quickly) on the production server.

However, for the production site... we will disable new member joins, donation contribution pages, etc... turn as much of production CiviCRM off as possible to quiesce the CiviCRM environment. Meanwhile, existing members should be able to login to and make use of the rest of the site... Drupal and related services which Drupal logs them into.

Thoughts / comments / things I have not thought of? Thank you!

Thank you, Hershel. So just for clarification, you would err on the side of keeping the Drupal site off line check box checked for the ENTIRE CiviCRM rebuild process?

Then I best emphasize the practice upgrade on the local VM copy of the server, and perhaps retain import files of what was promoted back to the new instance... then export from real production tacking on any new members which had joined... oh... and catch up any matching retained site members as their data could have changed... this is starting to get tedious... hhhmmm...

To avoid anyone trying to register/donate or some such in the middle...

I was planning to take all contribution pages off-line during the live migration. So existing members could continue to login to the site, however new visitors could not join, no one could make donation contributions, etc...

I was thinking the Drupal CiviCRM module that performed role sync was Drupal reaching over to CiviCRM to find out if in Civi's opinion should be able to login to the site. Thus by unchecking that module, I was thinking that would break the tie to CiviCRM, and the existing current members would be able to use the site minus CiviCRM.

No?

if you're careful with the public CiviCRM pages, including profile edits however... (which I don't know if you can or would want to disable).

I cannot think of a spot where we allow members to edit their CiviCRM data... I will check on that.

The way I understood that bit was being concerned that an existing member will try to update their addy / CC info? I believe if we communicate with current members well enough, "addy / CC changes will not be possible during site maintenance" then anyone who did not obey, tough, we warned you, you will need to update your addy / CC again".

I believe we have a non CiviCRM form to accept addy / CC updates. People fill out that form, then a site admin updates CiviCRM. (I believe.)

Thank you so much for your detailed discussion, Hershel. I appreciate you sharing your time very much.