Guide on how to transfer OpenCart to a new server

Hello,

One of our customers is using OpenCart and would like to migrate their store to our hosting service.

With this in mind, we have created the following guide

Guide on how to transfer OpenCart to a new server

Using http://docs.opencart.com/display/openca ... new+server as a starting point.

I'd appreciate it if any mods or experienced OpenCart users could take a look at the guide and let me know if we've missed anything (either on here or via the comments section on the guide).

We have also written the guide so that anyone can use it to move servers (not just users moving to us).

Looks good. But it isn't necessary to put them to maintenance mode. Doesn't really make a difference ultimately

Hello MarketInSG

Thank you for the feedback.

The reason we suggested maintenance mode is to stop orders going through during the transfer and being added to the incorrect database.

Generally the phpMyAdmin Export can best be done in "Quick" mode as that is preset for good reasons and offers choice between unzipped .sql and zipped .sql.zip (which often do not, all things considered, significantly differ in size). People who need migration instruction steps in the first place will generally be the ones for whom plug-and-play prevails, for whom Express installations of everything prevail, and for whom textfile as well as gui "Help" are written to no avail other than to exemplify the RTFB principle (unread, blooie, duh, why?). "Custom" mode poses checkboxes and an avoidable temptation to mess with them in inherent deviation from widely established phpMyAdmin and mysql defaults.

Generally the phpMyAdmin Import will be the best means to take in the exactly appropriate format. All too often servers are set up with various panels which themselves are software that are not perfectly set up according to instructions that come with them. Enough of the people who set up the panels blow it subtly or boldly enough to force concern for using phpMyAdmin for BOTH Export and Import. People who need migration instruction steps in the first place will have no clue as to why little things like that matter greatly. (Even separate servers' seemingly identical mysql and phpMyAdmin setups will NOT necessarily be equally capable or incapabable of importing, for example, .csv or other files than .sql files.)

Generally the database should be Exported and Imported before the fileset. Generally based upon those the ftp captive index.php files should be edited to match the new server before anything is uploaded. Generally when the entire fileset is readied, with database awaiting it and with config.php files already properly armed, it should be slipped into place. (Otherwise somebody will putter forth trying to keep config.php versions for both positions straight, or neglect to change something fundamental in both files.)

Otherwise, generally the steps and pictures should make sense, both to somebody who maybe should not try it without help, and to somebody who maybe shouldn't have tried to help. That will often include server support working from notebooks before something goes haywire enough to escalate a ticket that should have been avoidable.

Agree, as to Maintenance mode. Shutting off opportunity to change database prevents having to slip stragglers into place in new database, and downtown can be a matter of a few minutes with adequate, and adequately advance, planning.

And kudos for specifying FileZilla Client by name.

SquirrelHosting wrote:Hello MarketInSG

Thank you for the feedback.

The reason we suggested maintenance mode is to stop orders going through during the transfer and being added to the incorrect database.

That's true, but usually only for those large stores that are coming in with orders so quickly. Else, switching hosts should only be a couple of minutes by switching the files over, then the DNS and everything should be good by then

Depends, and the upshot is, Maintenance mode. "DNS and everything should be good by" whenever traffic pointers take effect WHERE CUSTOMERS ARE. Global propagation of primary pointers (both DNS and stealth and non-stealth redirection) fan out from registrars, take at least 5 minutes if you catch the registrar's own updating just right, take a few hours to spread through a region (say, a USA state or the like), 12-24 hours to spread across a large continent, and up to 72 hours to reach halfway around the globe. The problem is mainly that web traffic is purposely circuitous in order to prevent attacking one node from bringing it down. Traffic to the guy across the street usually zigzags (in hops) through distant nameservers (e.g., from California to California, via Texas, Maine, Maryland, and several others, or from London to London via Paris and Rome, no kidding, it is NOT straightline). EVEN IF registrar and webhost are the same outfit (mixed bag of tricks, usually best two outfits), then, lo, traffic will still encounter propagation involving nameservers sitting thousands of miles away. You can move your entire OC across the street or a few thousand miles to equal effect, you do NOT want both databases fielding customers at the same moment, and not merely to avoid having to draw the stragglers into the new database.

The SOLE way to accomplish an abrupt change with no interruption of database usage is to tie BOTH servers into the self-same database -- which wise hosts prevent for security reasons, but which on a dedicated server at added expense overall you can set up and do. Throwing both old and new OC into Maintenance mode for several minutes while the new one is brought live and run through some preliminary tests (yes, the baby has all its parts and they wiggle correctly), allows the new one NOT to be fielding customers while traffic is already arriving and cannot go back to the old one. Throwing both into brief to short maintenance mode while the last-effective redirection, on the old server itself, is taking effect, allows customers (seeing only Maintenance mode screens) to encounter no database, then to encounter ONLY the new database. A single file, whether .htaccess enforcing redirection or even index.html or index.php with a simple metatag redirection for 72 hours, can send traffic from old OC to new OC with no apparent difference. Maintenance mode is set for a short while, then is unset.

Those sorts of concerns enter into adequately advance, advance planning. Even with experience something can go wrong that can also be anticipated. Without experience a potential "mare's nest" awaits. Plan ahead, respect the worst, anticipate the best. Remember the two laws. Murphy: Whatever can will go wrong. Canby: Murphy was an optimist.