Recently I had to move a Magento 1.7 (if you are in a similar situation, please suggest to upgrade at least to Magento 1.9.X) website from a Linux server with SSH access to an hosting solution that has only FTP and a CPanel access.

The first two parts are generic, the third is specific for a Magento 1.X website migrated to a new web hosting with PHP7 only.

First part: The DB migration

How to move a large MySQL database to the new hosting?

Obviously you cannot think to upload it with PhpMyAdmin or similar, even if you try to compress it. Too large.

So a solution can be to split somehow the DB in smaller chuncks, and upload the chunks one by one.

Let’s start.

Step 1: Backup

Let’s say the our database is called lsdb, with the mysql user username with the privileges to perform this backup.

We can use a tool like mysqldump as follows (very simple version here, take a look at  man mysqldump for your options, or use your preferred tool to perform a backup):

mysqldump -u username -p lsdb > lsdb_dump_20171116.sql

Enter the password for username.

Step 2: Split the big dump in smaller parts

We can use the split linux command for this.

We can choose to split by size of output file (ex.: maximum 20 megabytes). The tool will not cut a line because it pays attention to line breaks.

 split -C 20m --numeric-suffixes lsdb_dump_20171116.sql dump_sect_

Now we have a series of dump_sect_XY files, where X and Y are numbers.

We can compress them, too, before uploading it. For the solution adopted in this article (next section), we are going to compress the files with gzip, even if I prefer .tar.bz2 files.

for x in dump_sect_*; do gzip $x; done

So we have now a series of dump_sect_XY.gz files.

Step 3: Importing the database with a tool

You can think to import the generated files through PhpMyAdmin, too.

If you do not have timeouts, or you want to create smaller but many other chunk files, it can be a solution.

Anyway, you will still suffer of foreign keys check problems.

Another solution is to use a tool: bigdump for example. It supports few file types, check the website for additional information and to choose your preferred one (this is why I have adopted the gz files).

With bigdump, you can upload through FTP or the CPanel file manager all the DB dump chunks in the same directory as the bigdump.php file. At this point, pointing to the bigdump.php URL in your browser, you will see the list of the chuncks, with a button to start the import process.

The only thing you have to do once you have downloaded the PHP file is to edit it to change the database name, username, password and host, according to the ones of your new web hosting.

Now you can upload it through FTP, too.

Let’s say that we have created a /dump directory containing the chunks and the bigdump.php file.

We can now point our browser to http://mynewhost/dump/bigdump.php to see the list of our chunk files and start importing our chunks one by one!

Step 3.1: Foreign key checks problems

If you have problems importing the chunks because of foreign keys problems, please clean the tables of your DB before continue.

Now, let’s modify the bigdump.php file, specifically we want to use the pre-queries: SQL queries to be executed at the beginning of each import session.

Edit the bigdump.php file.

Find and decomment the line:

// $pre_query[]='SET foreign_key_checks = 0';

This will disable the foreign key checks for the import session, and you can import your dump without problems.

Upload again in the dump/ directory and retry again in your browser.

Part 2: the code

Now we have finished the hardest part, the DB, and we have to upload our files.

Here there is not so much you can think of. An FTP upload of a compressed file is probably the fastest way to accomplish this task.

You can extract the compressed file with the CPanel File Manager as shown below:

Part 3: Magento 1.X and PHP7

There are some core files that need to be changed in order to fix some errors shown running Magento 1.X with PHP7.

As usual you should never change core files, there are a lot of articles around to show how to perform these tasks.

I suggest Overriding Magento blocks, models, helpers and controllers by Inchoo.

Please note that Inchoo has developed a PHP 7 compatibility extension for Magento 1.X, too, by I have not tried that.

Now, let’s see where the errors are.

app/code/core/Mage/Core/Model/Layout.php:
Fatal error: Uncaught Error: Function name must be a string in app/code/core/Mage/Core/Model/Layout.php:555

In PHP7 should be explicitly stated that you are calling the $callback variable as a function.
So you should change

$out .= $this->getBlock($callback[0])->$callback[1]();

with

$out .= $this->getBlock($callback[0])->{$callback[1]}();

Similar error happens for

 Uncaught Error: Function name must be a string in lib/Varien/File/Uploader.php:259

We are going to change

$params['object']->$params['method']($this->_file['tmp_name']);

wth

$params['object']->{$params['method']}($this->_file['tmp_name']);

Other changes:

app\code\core\Mage\ImportExport\Model\Export\Entity\Product\Type\Abstract.php:99

This issue affects the export functionality of Magento.
So replace this:

$data['filter_options'] = $this->$data['options_method']();

with

$data['filter_options'] = $this->{$data['options_method']}();

Another export problems, but for customers, is found at:

app\code\core\Mage\ImportExport\Model\Export\Entity\Customer.php:250

Here, replace:

$data['filter_options'] = $this->$data['options_method']();

with

$data['filter_options'] = $this->{$data['options_method']}();

A possible sessions error is related to:

     app\code\core\Mage\Core\Model\Resource\Session.php:218

The problematic code in this line can prevent your users to log in.

We have to typecast the variable returned by the read($sessId) function. Replace:

return $data;

with

return (string)$data;

There can be a problem with the grand total calculation and other deprecation warnings like the ones for iconv_set_encoding (this was true starting from PHP5.6).

Good sources for these and other problems are: How can solve error Magento 1.xx on PHP 7? (StackOverflow) and http://scriptbaker.com/tag/magento-1-9/.