Many of the steps documented on the "Migrating a site" wiki page are handled automatically now. Here's my recipe, which is far from perfect, but is much closer.
Copy the entire filesystem to the staging server. Git works well for this, but when it's not an option, we'll use SFTP or create a tarball.
Dump the database using mysqldump, either directly or ...
Below are the simplified instructions taken from Moving an Existing Installation to a New Server or Location, but specific to answer your question.
Open the file wp-content/plugins/civicrm/civicrm.settings.php in any text editor and change the value for CIVICRM_UF_BASEURL with your new domain name
For CiviCRM Version 4.7 open the file wp-content/uploads/...
How can we extract the data of our CiviCRM install without support from the hosting provider?
MySQL via network / phpMyAdmin / DB backups
If your hosting company provides CPanel, remote MySQL, or a web interface like phpMyAdmin, then you may be able to take a snapshot of your database. This is the core of your CiviCRM data.
You'll need your hosting ...
Honestly without a significant amount of detail regarding your current database, how you're going to use CiviCRM, what kind of site it is being connected to, etc, no one can give you anything but a huge range - I've seen it done for as cheap as $3,000 and as high as $30,000.
Some things to consider:
How clean is your data? Is there going to be a ...
Before pronouncing the old database deceased, I would make sure the structure is correct and if not what is broken. You can try this: https://github.com/progressivetech/civi-schema-harmonizer or http://wiki.civicrm.org/confluence/plugins/servlet/mobile#content/view/86213632. The current dB may be ok.
I would double check the civicrm.settings.php file to make sure the paths and URL are updated in there. For example:
define( 'CIVICRM_UF_BASEURL' , 'http://foo.example.com/' );
While you are in there make sure the server paths look right:
$civicrm_root = '/home/path_to_html/sites/all/modules/civicrm';
define( 'CIVICRM_TEMPLATE_COMPILEDIR', '/home/...
The API approach you're using is the "best" approach - but agreed it can be slow. There are alternative approaches though:
Delete all the records in civicrm_contact with a direct SQL call - except the default organization and logged-in user. This will remove most of the other records (e.g. contributions) via cascading deletes. However, it doesn't delete ...
Looks like you've a couple of hangovers! These are usually in the CiviCRM Administer > System Settings > Resource URLs, and Administer > System Settings > Directories pages. Update those, clear cache, and you should be good to go!
Xavier, your answer would have worked if I had had the luxury of re-importing.
It turns out that there is a single function in the CiviCRM DB that for some reason uses a hard-coded username and password. I went in to the DB, located the "civicrm_strip_non_numeric" function and updated the username and password. Problem solved.
Try these, in this order:
Check that the CIVICRM_UF value in civicrm.settings.php has been updated to reflect the changed host CMS
Try visiting /wp-admin/admin.php?page=CiviCRM&q=civicrm/admin/setting/updateConfigBackend&reset=1 to make CiviCRM recognise the shift from Drupal to WordPress
Clear the contents of your civicrm_uf_match table
Make sure you have migrated Drupal correctly and all of the non-CiviCRM portions of the site function correctly.
Sometimes the .htaccess file doesn't get transferred with FTP and
it is an important file.
Also, migrate the same filesystem/version
from one server to the other, and be sure to upgrade as needed to
keep things secure (either before or after ...
There is some documentation here that should help: https://docs.civicrm.org/sysadmin/en/latest/misc/switch-servers/
Are you copying the Wordpress database as well?
You are trying to switch servers and upgrade at the same time. I would strongly suggest you do that in multiple stages: first move to the new server using the same versions of Wordpress and ...
You should double check your civicrm_settings.php file. Particularly the section on File System Paths. Make sure the setting $civicrm_root is the correct path to civicrm for the new server.
Hope this helps...
It looks like your error message is truncated, which makes this a little hard to troubleshoot, so if you can find a way to generate a non-truncated version of this message, I think the solution should be clearer.
That said - I'm looking at a CiviCRM database dump. The first two tables to be created are civicrm_acl and civicrm_acl_cache. Your error ...
Many of these "lost session" issues (which stem mainly from redirect_canonical correcting CiviCRM's malformed URLs) are solved in more recent versions of CiviCRM. All I can really do is suggest you upgrade. FWIW, you can pick through the PRs that deal with URLs here:
If your site has been migrated to a different version of the Drupal codebase, then make sure you've run the database updates (drush updb or visit update.php)
This will update your Drupal DB to match the new codebase, and clear lots of caches etc as well.
You may want to move log tables from main database to specially created database via settings in civicrm.settings.php. Of course, new empty database has to be created first. After that please find this in civicrm.settings.php:
* CiviCRM Logging Database
* Used to point to a different database to use for logging (if desired). If unset defaults to ...
This can be done on the commandline. You can pass a list of tables to mysqldump and omit the tables starting with log_.
(Below, testdb is the name of the DB we're using. You may want to add other parameters, eg auth details to connect.)
To get the list of tables you want, exclude the log_ tables using grep. (Seems you can't SHOW TABLES NOT LIKE.)
Maybe you do not have ssh access and MySQL access. But this can also done from the user interface. To rebuild the triggers use the url:
(This is documented in the system admin manual.)
Recreating the Case Views can be done by disabling the case module and enabling it again (...
Similar to the accepted answer, in my case there were two case views which contained the incorrect definer information. Performed the alter query on the view and it was fixed.
Those view names were - civicrm_view_case_activity_recent and civicrm_view_case_activity_upcoming. Steps performed -
Execute this statement.
SHOW CREATE VIEW ...
did you dump the old site and restored it on the new server?
check that mysql dump file, it should contain the olduser string, replace it in that file with the new one before doing the restore and it should work fine.
If you wish to transfer the content of the database
a) export the existing data. You can do this as an action from the search/find screens. Export contacts, activities, memberships, contributions as separate files.
b) on the new system, import each file. Use the old contact_id field as the external_identifier to help all the records match up.
This is easy ...
You mean with your own CMS? you will mostly have to deal with the authentication and permission system.
look at what is done in civi for WP, J+, Drupal to give you a sense of the scope. I personally would not invest this time for no obvious value, but I would not either "hand code" my site, so YMMV ;)
I wouldn't say that it is easy, but it might be possible. You could even look at something like a multi-site setup (https://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+Installation) for some ideas. That said, I don't know that CiviCRM can run without a CMS of some sort. Permissions have to be handled somehow. Normally the CMS also handles the ...
WP Engine is a quirky host--it makes lots of configuration decisions for you with the goal of optimizing for WordPress sites, but that often makes things more difficult for CiviCRM. This is in stark contrast to Linode, where you have full control over your hosting configuration.
A 500 error could be any number of things; you'll need to find a log message ...
You'll likely need to make some temporary changes to your files to avoid the foreign key error. I do the same when I have to do an import to fix schema integrity.
Here's the page I am referencing: https://wiki.civicrm.org/confluence/display/CRMDOC42/Ensuring+Schema+Integrity+on+Upgrades
Here's what it says:
A note on possible Foreign Key Constraint ...
As answered by @davejenx here ("Cannot redeclare class CRM_Core_ClassLoader" in backup site) this could be your issue.
It sounds as though there is either a cached path to ClassLoader.php somewhere or there are two copies of the CiviCRM code under your modules directories. Various scenarios and solutions are discussed in this forum post: svn ...