Today we’re pleased to announce the official release of WP Migrate 2.5, which brings High-Performance File Transfers out of beta and into its new role as the standard file transfer method in WP Migrate. This means if you migrate big sites with lots of files, your migrations just got a whole lot faster.

We first introduced a public beta of High-Performance File Transfers in WP Migrate 2.4. The idea was born out of the reality that every network request takes some amount of time to process regardless of its size. This overhead usually amounts to a fraction of a second per request, but quickly adds up over hundreds or even thousands of requests when moving large WordPress sites.

Early Strategy and Benchmarking

If we could pack more data into each request without compromising our chances of success, then this would lead to fewer requests, reduced overhead, and faster migrations.

The results spoke for themselves. For a closer look at our testing process, check out the results of our benchmarking efforts in the 2.4 release post.

We were feeling good about this new approach to file transfers, but before going all in, we wanted to be sure it was the right decision for our users. And so began the public beta.

Public Beta

Over the last two months, users across a wide range of hosting and development environments have had the opportunity to try the new file transfer mode by opting into a checkbox at the bottom of Push and Pull migration profiles.

During this public beta period, we gathered feedback, validated the approach, and even managed to make further improvements to the speed and reliability of file transfers.

The New Standard for File Transfers

In WP Migrate 2.5, High-Performance File Transfers will be the standard for new and existing migration profiles going forward. The opt-in checkbox has been removed, and the improved approach is now automatically applied to any migration that includes files.

Behind the Scenes

When you start a new push or pull migration that includes files, the process now looks something like this:

1. Ramping Up – If the migration profile is being run for the first time, a conservative maximum request size of 1MB is used to start the migration. With each successive request, the maximum request size increases, gradually including more data in each new request.
2. Falling Back – If an error is encountered, the request size steps down to match the value of the last known successful request and try again. After 5 failed retries, the request size will be reset back to 1MB and make one final attempt before stopping the migration altogether and communicating the failure.
3. Optimizing the Next Migration – When a migration succeeds, the last known maximum request size is preserved so that future migrations can start from that value instead of the default 1MB. This means subsequent migrations will get even faster as they spend less time ramping up.

Caveats

• These improvements only apply when migrating files, not the database.
• Any migration that includes files will benefit from High-Performance File Transfers, but the most noticeable improvements are observed when migrating large sites with many media, theme, and plugin files.

And More

For a full list of new features, improvements, and bug fixes, see the 2.5 Changelog.

Next Up

Full-site exports are just around the corner alongside drag-and-drop support for importing directly into Local.

Until then, how much are High-Performance File Transfers speeding up your big site migrations? Let us know on Twitter or in the comments below.