Moving magento site from one server to another server - magento

i have a magento site version 1.4.1.1.
And i upgraded the site to 1.7.0.2.
Now want to move the upgraded magento into another server .
How can i do this?
i planed to do this by downloading all files and upload it into new server.and import the database into the same databsae name.
If there is any problem occur when i following the above steps.
Or if there is any rules to move magento site from one server to another server?

If your sites are not publick then just move the files and db and fix base_urls on db.
If your site is live then here's a thing or two to note down on moving sites:
CODE:
this is straightforward, static assets can be moved beforehand to new server
easy enough to perform with rsync or version control or even with plain old ftp
verify file-structure and permissions
DATABASE:
this is more complicated as you have to avoid the gap of getting more orders on old server database after you have switched to move your site database you need to take our site down for the time you move your database
first step move the database to new server for testing , test if everything works
make a not of all queries you need to run to make it work on new server (base urls etc)
repeat this process when you take down the site and open the other
THE PROCESS ON CODE AND DATABASE:
add a maintenance page on your old page with proper http header
while site is down move the database to new server
open up your new site and do a short run on verifying if all works
next step is to change the domains to point to a new server
MOVING THE DOMAINS
again moving domains is a bit tricky thing as there is a possible DNS blackout that some clients will see the old site and some are seeing the new.
change your domain rules to point to a new server
clients who's DNS is not changed jet will see the maintenance page
clients who have the new DNS already will end up on moved sites
this way you can ensure that you will not get orders on both sites. If your domain-changes completely then you also need to remap your URLS to new domains for every search engine

Related

Accessing old / new site at the same time using hosts file

This is an odd request, but one I can't get my head around. We are currently building a new site on a new server, but don't want to update the DNS settings until it's ready to go, since we need a live, working site. In order to gain access to this to build it, I changed my hosts file (in Terminal) so that it would pull from that IP. Example
00.000.000.000 mywebsite.com www.mywebsite.com
The problem is, I need to import images from the old site into the new site, but since I have the hosts file setup it's not able to pull it. Any ideas of a workaround? I have multiple computers, but it needs to be done on the same computer since I need access to the backend of the new site at the exact same time of the old site, so that it can pull that image over.

Move OctoberCMS website from Ubuntu VM to a CentOS 7 VM

Our web developer picked OctoberCMS to develop our new website (his skill). Unfortunately before completion he rapidly left us due to health reasons and is no longer available. His Ubuntu environment has some problems and we need it on CentOS 7 anyway. The rest of us are OctoberCMS newbies, but want to learn it.
We built a CentOS 7 VM and installed OctoberCMS and want to move his work over.
We can not find any instructions on how to "export" the work he has done thus far and import it into our new OctoberCMS.
He is using 10 plugins and 3 he developed. (I don't know if that is relevant)
Is there an easy way to do this or at least instructions?
We have been googling, youtubing, IRC'ing for a week and still at a loss.
Any help would be most appreciated.
There really isn't anything special you need to know about moving an OctoberCMS install to a new server compared to moving over any other PHP application.
I am assuming you know how to do the basics of setting up a LAMP stack, such as setting up a virtual host for the domain you want to host the site on and setting up a MySQL database and user/password to access the database. There are of course many variants on how you could accomplish this such as using a management tool like Plesk or cPanel, or just configuring the services manually via the command line.
1) Ensure your new server is running at least roughly the same version of Apache, MySQL, and PHP.
2) Copy over the directory that contains all of the web files from the old server into the document root for your domain on the new server.
3) Do a database dump from the old server and copy it to the new server. If possible, use the same database name and username and password as the old server. This way you don't have to worry about updating the configuration of the website.
4) Pull up the site and troubleshoot any errors that come up. It is helpful if OctoberCMS debug mode is on.
Following the above method will ensure that you have the exact same setup on your new server that the old server had. This will copy over all of the plugins, data, etc.
There are of course many complexities that can come up during a switch over like this, but this should at least get you started and you can come back to StackOverflow with some more specific hurdles.
Hope that helps.

How do you replicate rules between SonarQube servers?

We currently have two SonarQube servers (v4.5.1) running on two separate Windows 2012 servers each with its own MS SQL database server. One is our Development server and the other is our production server. The idea being that we test out all rule changes on the development server first, once we are happy that they are correct we port them to the Production server.
When we first setup the two servers we simply took a backup of the Development server database and restored it on the Production server. At this point both systems were in sync.
We have recently made some modifications to the Development rules set, however when we tried the same approach to move these to the production server it did not work.
The production box seemed to remember the previous rule set. There seems to be a cache of the previous rules that we can't work out how to clear.
Before restarting SonarQube with the new DB in place we deleted the temp folder as that appears to keep a cached H2 database, but that did not solve the issue. We also tried starting it up and using the /setup url but this did not appear to work either.
Is there a way to completely reset the SonarQube server prior to restoring the database so that it has no knowledge of the previous rule set?
Alternatively is there a better way to export and re-import the entire rule set between two servers?
We looked at exporting the rule profile, but this did not appear to contain the full detail of the rules.
Thanks
Pete
For the moment, this is not possible to fully synchronize rules and quality profiles between 2 servers because of SONAR-5366. You can watch and vote for this ticket.
Concerning the cache that you seem to have, this is probably the E/S indexes which are located in <install_dir>/data/es folder. What you can do is:
stop you server
fully delete the <install_dir>/data folder
restart the server: your rules should be in sync with the DB

Moving one add on website to a new cPanel host

For several years now I have freely hosted several local organizations web pages at no cost. One of those organizations wishes to move to their own server that they manage with their own server provider (alas, not A Small Orange--a little too expensive for them).
They have
a couple add on domains/websites
advanced DNS records with Google Apps
several mailing lists
a database or two
and of course their hosting directory
I was just wondering if there is a way to just export that stuff, so it can be imported in another cPanel?
OPTION ONE: One by one move all the stuff to the new host. Create the mailing lists, manually import the databases, set up the DNSs, and upload the files.
OPTION TWO: I could export the entire site, download the entire site, go to the new provider and upload it, and then delete all my content.
OPTION THREE: Is it possible to export their parts of the site, and import that to the other hosts cPanel?
Or another option all together? No email, and I don't even need the hosting history to be there (but it would be nice).
if you are moving from cpanel hosting to another cpanel hosting then just create a full backup of the website that you want to move from WHM which will backed up emails , databases , SSLs , sub domains , addon domains , everything in .tar.gz file format. Download that back up file then upload it to the new servers and restore it from WHM from Restore backup option in WHM.
OR
You can do live migration from WHM itself with Copy Accounts function from WHM which will be easier option to move the websites and the stuff.
However after migration you will need to make sure that you have assigned dedicated IPs , have configured the name servers properly ( the DNS part ) etc..
I would suggest to hire an expert to do this migration in order to avoid any possible issues.

Magento upgrading process and infrastructure for smallest possible downtime

I have a client who currently has one server with Magento and his admin takes down whole site for updates for multiple hours. I would like to make it instant process so that I wanted to propose new solution on how he should have set it up:
Magento Production Server 1 (WEB+DB)
Magento Production Server 2 (WEB+DB)
Magento Dev Server 1
DB would have to be synced somehow between those 2 servers (cluster? replication?) and I was thinking that for the smallest downtime possible first the updates should be tested on Dev Server (DB / WEB synced from Production server just before upgrading) and after checking it works fine and knowing how the process looks like I would be disabling LoadBalancing or RoundRobin DNS to only Server 1 then doing upgrades/updates on Server 2 and then Switching to server 2 as production server and updating server 1. When both are done switch on LoadBalancing/Round Robin on.
I come from Windows environment so this is how I would do it on Windows (maybe with seperate Database and Web too) and with tools like RedGate SqlCompare/Sql Data Compare etc it should work.
But I don't know Magento at all so please let me know what's possible and maybe how this should be done if the client don't want to end up with his shop being down...
You'll definitely need a production server, and some sort of staging/version management system.
I recommend checking out Subversion or Git for version management.
Changes can be committed to a repository first, and then updated to the live site with no downtime. This would be more than sufficient for a development environment.
For bigger changes, like a Magento version upgrade, you might still want/need to take the site down for a few hours in the middle of the night, as this is a much bigger process.
As for multiple servers, as an example I run a load balancer which balances between a primary and a secondary server. There is one database server that is separate. Changes are made to a development server, committed to the primary server with Subversion, and then any changes between the primary and secondary servers are rsynced to the secondary server every 60 seconds.
For this solution, session and cache data are stored in the database.
IMHO, with a good hosting environment, you won't need multiple servers unless you literally are in the thousands of simultaneous visitors. Plugins are the usual cause of admin-related problems.
We've had great success with "cloud" environments. Instantiate a new cloud instance, get that IP, then in your "hosts" file, point something like dev.yourdomain.com to it for testing. The only real downtime is that you should freeze the production site while the database converts to the new version, which can be a couple hours. Our mySql DB backup is 3 GB or so, but thankfully tgz's down to 280 MB.
We're using nginx and php-fpm and they are obscenely fast.
Typical migration path for me:
backup production site
start new cloud instance and copy production site to dev site
(restore production database)
try upgrading dev site one step at a time to see what breaks
start new cloud instance and do completely fresh install of newest
magento version
once working, restore production database and watch as it grinds on
converting it, see what breaks
pick between upgrade versus fresh install
back up production mySql, put production site in maintenance mode
while dev site converts the database
point domain to new IP address

Resources