Author Topic: Server Migration (Read 2588 times)

Upperholme · January 13, 2012, 05:01:01 am

Despite the excellent guide at http://wiki.civicrm.org/confluence/display/CRMDOC40/Moving+an+Existing+Installation+to+a+New+Server+or+Location migrating a CiviCRM installation remains a fairly royal pain. I know Drupalists that pretty much rule out Civi as a solution simply because of the hassle involved in including Civi's migration issues in their development workflow. Are there plans to make life simpler for migration?

Does anyone have any tips about how to make life easier in terms of moving an installation and/or working with Civi in a dev/staging/live workflow?

trevorwood · January 13, 2012, 05:09:20 am

I'm regularly moving a Joomla/CiviCRM package from a lice server to a developent server for further testing and development. It's a pain but I've found a minimum number of steps that I need to do

I use Akeeba backup to create a full backup of the live site.

I delete the database and all the files on the development site - I've found that on the odd occasion if I don't do this some files can't be written because of protection issues

Here's the rest

Upload the .jpa backup file & kickstart.php. Create directories tmp and kicktmp, change their permissions to 777
restore the website by running kickstart.php

after restoration theres some tidying up and permissions to fix

Delete the kicktemp directory
Enter the administrator directory
Change the permission of cache to 777
Go to /httpdocs/components/com_akeeba and change the permission of backup to 777
Go to /httpdocs/media/civicrm and change the permission of upload to 777
Go to /httpdocs/media/civicrm/templates_c/en_US and change the permission of en_GB to 777
Go to /httpdocs/images and change the permissions of company_logos and individual_avatars to 777

Here's the CiviCRM section from the DR doc I've written for the client

CiviCRM is very strange. Sometimes it doesn’t reinstall properly and needs reconfiguring. If you’ve recovered from a different server it definitely needs doing. On the back end go to Components/CiviCRM and see if everything looks OK. Errors can include blank screen, incomplete screen, ACL settings wrong, etc. If there are any errors you will need to reinstall CiviCRM
Unpack the CiviCRM zip file – you’ll get a directory called com_civicrm with 2 files and 2 other directories in.
Using your FTP software, upload this directory into the tmp directory
Log in to the back end of The Business Club website
“Extensions/Extension manager”
Click on “Manage”
Find CiviCRM – it’s probably on the next page
Click on the green tick on the CiviCRM line – it’ll turn into a red dot
Go to your FTP software and delete the following files
•   /httpdocs/administrator/components/com_civicrm/civicrm.settings.php
•   /httpdocs/components/com_civicrm/civicrm.settings.php
•   /httpdocs/media/civicrm/templates_c/en_US/ConfigAndLog/Config.IDS.ini
Go back to the website back end and click on the “Install” tab
In the Install from Directory box enter “/var/www/vhosts/the-businessclub.org.uk/httpdocs/tmp/com_civicrm” and click “Install”. Now wait
When the install is complete, you’ll be asked to upgrade the database. Click on “CiviCRM Database Upgrade Utility” to make sure the database is at the right version. It should be, but it is possible that you’ve tried to install an older (or newer) version of CiviCRM. If you’ve installed an older version, the upgrade will fail and you’ll have to start this whole thing again (sorry!)
Click “Extensions/Extension Manager”
Click "Manage”
Find CiviCRM and click on the red dot – it’ll turn back into a green tick

they then have to go and reset the ACLs as these are set back to the default

Upperholme · January 13, 2012, 05:15:19 am

Thanks trevorwood. This sort of confirms my point really. If CiviCRM is to maximise the potential for growth that the integration with Wordpress promises then I'd say it is imperative that this issue is addressed. It's fiddly, time-consuming (and something that clients really don't want to pay for), and as far as I can see it doesn't need to be this way.

Maybe it needs and MIH?

trevorwood · January 13, 2012, 08:08:10 am

Yeah - some of this i've reported as bugs (reseting ACLs for example). The other is down to locations being hard coded in settings files. Not very friendly. Although there's a way to reset directory paths, it cant be dobe when moving to a different server because the directory paths all point to the wrong place.

I've been working on a site that uses CiviCRM for the last 6 months and the more I use it the more I wish I hadn't and just custom written a crm/event management package

Donald Lobo · January 13, 2012, 09:00:48 am

Quote from: Upperholme on January 13, 2012, 05:15:19 am

Thanks trevorwood. This sort of confirms my point really. If CiviCRM is to maximise the potential for growth that the integration with Wordpress promises then I'd say it is imperative that this issue is addressed. It's fiddly, time-consuming (and something that clients really don't want to pay for), and as far as I can see it doesn't need to be this way.

Couple of thoughts and comments:

1. In drupal using drush to manage dev/test/prod is quite common. Quite a few people have contributed code to make the drush integration stronger and easier to do so

2. 4.1 has made some strides in some of the current issues. Specifically moving things to a settings table and allowing an over-ride of any setting via the civicrm.settings.php file. Thus theorotically u can use the same DB across test/dev/prod with different settings files to override various directory paths

3. If there are sponsors willing to seed the MIH we'd be happy to post an MIH to make things even easier.

4. Yes i think easing the effort between test/dev/prod is quite important. But its also very site specific with regard to some of the hurdles that we may not be aware of. For my school site, i migrate the DB between prod/test via a simple mysqldump / restore and resetting config_backend and its literally a 1 min operation. Its a simple site also. I could potentially automate the dump/copy via drush but have not bothered to do so

lobo

lobo

Donald Lobo · January 13, 2012, 09:07:13 am

Quote from: trevorwood on January 13, 2012, 08:08:10 am

I've been working on a site that uses CiviCRM for the last 6 months and the more I use it the more I wish I hadn't and just custom written a crm/event management package

at some point (sooner rather than later), you might want to re-evaluate and see if it makes sense for you to continue using Civi. Sometimes it worth it to cut your losses and move onto something that is more applicable / more relevant / something u like working with. A relationship like you describe above does not help you or the project

lobo

Upperholme · January 13, 2012, 02:21:27 pm

Quote from: Donald Lobo on January 13, 2012, 09:00:48 am

2. 4.1 has made some strides in some of the current issues. Specifically moving things to a settings table and allowing an over-ride of any setting via the civicrm.settings.php file. Thus theorotically u can use the same DB across test/dev/prod with different settings files to override various directory paths

lobo

This sound a like a major step forward and most welcome. This should make life significantly easier in terms of managing a workflow as well as creating copies of sites for development or simply moving to a new server.

Resetting config_backend can, as I understand it delete lots of valuable configuration information, especially on multi-lingual sites, so we really do need to tackle this issue.

trevorwood · January 15, 2012, 10:21:18 am

Quote from: Donald Lobo on January 13, 2012, 09:07:13 am

Quote from: trevorwood on January 13, 2012, 08:08:10 am
I've been working on a site that uses CiviCRM for the last 6 months and the more I use it the more I wish I hadn't and just custom written a crm/event management package

at some point (sooner rather than later), you might want to re-evaluate and see if it makes sense for you to continue using Civi. Sometimes it worth it to cut your losses and move onto something that is more applicable / more relevant / something u like working with. A relationship like you describe above does not help you or the project

lobo

Unfortunately a bit too late for that

The site is already live

Hershel · January 15, 2012, 12:28:13 pm

Quote from: Upperholme on January 13, 2012, 05:01:01 am

Despite the excellent guide at http://wiki.civicrm.org/confluence/display/CRMDOC40/Moving+an+Existing+Installation+to+a+New+Server+or+Location migrating a CiviCRM installation remains a fairly royal pain. I know Drupalists that pretty much rule out Civi as a solution simply because of the hassle involved in including Civi's migration issues in their development workflow.

Doesn't make sense to me. I migrate CiviCRM installs on a very regular basis and I don't have such troubles. I have never had to take all of the steps outlined by trevorwood.

Whereas the wiki does mention more steps than I use, I have not found them strictly necessary. But there are also two types of migrations:

Initial Migration

To move an install from one server to another where the second has no site at all, I do:

Dump the database(s) in entirety.
Archive the web files and DB(s).
Move the archive to the new server
Unpack the archive
Delete template files
Import the DB(s)
Adjust settings.php (or configuration.php for Joomla) and civicrm.settings.php files manually
Reset civicrm_domain backend settings with a simple SQL call
Check the site and see if it's necessary to rebuild menus or not

That's it. OK, the client now may have to redo some settings, that's true. But that's the only real drawback. AFAIK.

Update an Existing Site

If you have a production and development version of a site, I don't see why transferring the production DB to development should be any more difficult than the Drupal DB (I always use two DBs). The only possible drawback is that if you copy the entire DB, you will lose settings. Thus you can ignore the civicrm_domain table I think. But the rest should just be dump and export--like lobo said.

Why not?

onderzoekspraktijk · February 12, 2012, 07:56:22 am

Hi,

I am used to Joomla components. These are very much more user friendly to operate and adminstrate than civicrm.

I admire the functions of civicrm on the crm front. I never understood the reasons why database location data are hardcoded and have to be searched for and reset manually and at different file locations everytime I want to create a functioning backup. I find this takes time and effort. It regularly goes wrong and inspires fear and doubt every time again I have to try and do it.
I read here that there are people that can do this effortlessly. What are you trying to prove with these kind of statements?

I will try the latest beta as I understand it is less difficult to handle.

Thank you

Paul

CiviCRM Community Forums (archive)

News:

Author Topic: Server Migration (Read 2588 times)

Upperholme

Server Migration

trevorwood

Re: Server Migration

Upperholme

Re: Server Migration

trevorwood

Re: Server Migration

Donald Lobo

Re: Server Migration

Donald Lobo

Re: Server Migration

Upperholme

Re: Server Migration

trevorwood

Re: Server Migration

Hershel

Re: Server Migration

onderzoekspraktijk

Re: Server Migration