1

first time posting and really hope someone can help me!

We are trying to EXPORT our data from an old installation of CiviCRM on a drupal server IMPORTED into a new installation of CiviCRM on WordPress. All of the data has been exported using CiviCRM's built in export so we have all of the fields etc.

When importing Contacts using the CiviCRM import option you of course have to match all the fields to what is in your spreadsheet and here is where we run into a problem ... we have exported the contact ID and have contact ID for all contacts but there is no field Internal Contact ID to select / match to when importing data!

enter image description here

When we import Members there are TWO required fields, internal contact ID AND external contact ID ... we can't import internal contact ID to internal contact ID here, because since there was no option to do that when importing Contacts, all the contacts we imported were given different auto increment contact ID's.

We were thinking that when we import contacts we will map Internal Contact ID -> External Contact ID (since there is not an Internal Contact ID option to import to) .... then when we import members we again map Internal Contact ID -> External Contact ID .... then the External Contact ID will be the same for both members AND contacts .... effectively connecting them ... so that is what we tried ...

When importing contacts we mapped Internal Contact ID -> External Contact ID. Then we made a blank column in the spreadsheet we were importing, which we named Contact ID and which was blank for every row, and when importing mapped the this blank field -> Internal Contact ID and the ACTUAL Internal Contact ID's from the old system -> External Contact ID's ... this way external id's would match for contacts and members, linking the two .... but we got error that Internal Contact ID's do not match (the blank value in the members import does not match the auto-incremented ID in the contacts table).

I did a test where I tried importing only one Membership record, where I took the new auto-incremented Contact ID and replaced the Contact ID that from the old system and this imported, properly linking the Contact and Member.

How come when you are importing though there is no option to import Internal Contact ID? Without using some complicated MySQL Query, only using the CiviCRM export / import, how am I able to do this without having to manually match every Member Record Internal Client ID with the newly created auto-incremented Internal Client ID created when I imported the clients?

I Hope this all makes sense. Please help!

EDIT: Thanks for your responses guys!

I know my post was a bit confusing so I'll try to explain it again more simply. We had CiviCRM on a Drupal system. We want to import the existing data into our new WordPress system (fresh install of CiviCRM).

When we import the contacts (which were exported from CiviCRM so we have all the fields) there is no option to import the internal contact id, so all the contact id's are now auto incremented and not the old ones. Then when we import members the contact id's don't match.

Because of this, on import we mapped the old contact id's to the external id field. Then when we import members though, even though we have mapped the contact id -> external id field for both (so they could sync that way) we saw that contact ID was a required field with asterix next to it .... but mapping the new auto incremented contact id's would require a TON of manual work!!!

I THINK WE GOT IT WORKING THOUGH!!!!

At first we tried making a new blank column that we would map to the "required" contact id when importing members but that gave an error that the contact id's were not valid (because they were all blank).

What we tried next, which I can't believe worked, was just setting the "required" contact id field to NOT IMPORT .... and it SEEMS to have imported all of the members records and properly synced them by their external id's!

I don't know if that made any more sense unfortunately.

| improve this question | | | | |
  • 1
    I think the * required is a bit misleading and not all of these fields are required so using the external id for membership import is enough. You could also have exported contact id and external id from contacts and then used a lookup to fill the new contact id on the file for membership import. Glad you have found a solution anyway. – Mick Kahn Feb 17 at 8:27
  • Ya that * will get ya! I spent way too much time on that one. – Lucasmang Feb 18 at 20:50
3

We had a similar problem importing from an old (non CiviCRM system) and I wanted to make the old membership numbers the Contact ids on the new CiviCRM system. Fortunately membership numbers 1 & 2 were not in use so no clash with the initial admin and organisation contact records. There were some gaps in the old membership numbers and I was also quite happy that new Contact ids would also include none members. All I needed was for them to be unique and increasing.

In my contact import file, I added dummy records for all the missing Contact ids (except 1 & 2) and added an "ZZZZ" in the last name field with the rest of the fields in a valid format, but meaningless. I imported real and dummy records matching Contact Id as (new) External Id and then deleted the records with "ZZZZ" in the last name. All the kept new records have the same Contact Id as the old system membership numbers (or old Conact Id in your case.

If the expanded import file is very large, you will probably need to split it to avoid timeouts.

You can then use the Contact Id to match the membership records.

Hope that helps.

| improve this answer | | | | |
2

Was this all driven by wanting to move from Drupal to WordPress? If so, you can do this at the database level since most of Civi's data is independent of the CMS.

See https://docs.civicrm.org/sysadmin/en/latest/misc/switching-cms/switch-cms/

| improve this answer | | | | |
  • Yes it was from moving from WordPress to Drupal. I tried those steps to move by the database level actually but it completely broke everything, not sure what I did wrong. The version of Drupal that had been running was like 5 years past end-of-life and so was the version of CiviCRM maybe that's why this didn't work. Next I installed same outdated version of Civi (to avoid having to update Drupal) and do a migration but that also didn't work. In the end it seemed easiest to just install the latest version of Civi and do data export / import. – Lucasmang Feb 18 at 20:47
  • If the versions were that old then you also have to take into account the version of php that they can run with. I'd probably do the Civi/Drupal/php upgrades first on a copy of the old system, then change CMS. When you switch CMS you want to have old and new at the same Civi version. – Aidan Feb 19 at 10:24
  • Yup we did account for the version of PHP and rolled back to PHP 5.6 before trying those changes and nothing worked. Even if it had worked though, for anyone else trying to do the same thing - it is significantly easier to just export and import the data, than trying to make outdated drupal civi work with outdated wordpress civi, on outdated version of php, and then trying to update the version of wordpress civi. – Lucasmang Feb 21 at 17:47
1

To get that field to appear in the dropdowns, then on the first page of the import steps you need to choose Update or Fill for "For Duplicate Contacts".

| improve this answer | | | | |
  • If you are referring to contact import, I don't think that helps because you can't use that to import to a contact id that doesn't already exist. If you are referring to membership import, the Contact id is always there. Must admit I got a bit lost in the description of what Lucasmang tried – Mick Kahn Feb 16 at 13:20
  • Ya I'm not updating anything, I'm importing contacts and then I am importing members. The contacts all have id's already, which I mapped to the external id field when importing them (since it wont let me map it to the internal contact id field). Then when importing members I also mapped the member / contact id's to the external id field (so they would sync this way) .... but when importing members there is a "required" contact id field ... well this isn't so required because we set it to "do not import" and everything seems to have worked and linked members to contacts by the external id – Lucasmang Feb 16 at 20:22
  • Ok glad you got it working in the end. – Demerit Feb 16 at 20:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.