Push vs. pull migrations

The short explaination is that it is the direction of the migration. If you pull data, you move data from remote site to the site you are executing migration at. The opposite, where you push data, you move data from the current site to the remote site.

The reason both exist when they have the same functionality, is because they solve a specific issue. That is firewalled environments. Very often, one of the ends in the migration is firewalled. That could be your local development environment, which is or should be firewalled.

Consider this scenario:

Pull migration from production to local development environment

You want to get data from customer1.com site to your local site customer1.local, that you are running on your local machine.
In this case, it would not possible to push data from the customer1.com site, as it would be blocked by the firewall protecting your local network.

Therefore you have to pull the data from the inside, which will be allowed by the firewall.

If we examine another example:

Pull from production site to staging site

In this case, both sites are "out" on the Internet, not limited by any firewall. That means that you can use push and pull just how you like. The only choice here is to choose the site where you will run the migration. Lets just say we want to do our migrations on staging.customer1.com and we want this site updated with the production site customer1.com. In this instance we would pull the data from customer1.com to staging1.customer1.com as indicated by the arrow.

Still using free version? - Upgrade to PRO with 14 day free trial

PRO version makes it possible for you to migrate files between your sites and to automatically make a database backup before migration.
You will get support for Basic Authentication and email notifications on success or failure. You also get access to priority support