Codexonics

Hello Keith,

Thank you for using Prime Mover in your projects! Regarding your comments and our reply:

• “Upto #3, Prime Mover works smoothly. The problem lies in #4 as the customized theme settings are completely replaced by #3’s single site’s settings. Since all theme settings are stored in posts/postmeta tables in DB, I guess there isn’t much room to preserve existing theme’s settings, but would deeply appreciate it if some of them can be preserved.“

Reply:

This is expected because you are migrating a new site to the subsite – it’s settings, post meta, etc will be overwritten with the newly migrated settings. So yes – we can review this implementation to see if we can somehow exclude some post meta or even options from being replaced during migration.

• “In addition to the above theme setting preservation issue, the guid (in wp_x_posts table) was not converted to new domain. I had to manually change it by replace query. The same issue occurs in other DB tables. I have used/tested many migration plugins, and I think this is a kind of common feature nowadays. Plz add the function in your next update.“

Reply:

Yes this is expected also because it is a WordPress recommendation not to change the guid field. We will however add a feature in the future release to override this in cases where this changing this is highly necessary but not enabled by default.

• “For 1GB chunk migration, for usual single site to single site, it takes less than 10 mins, but w/ prime mover for single to multi, it took over 30 mins for one site.“

Reply:

There are lot of factors to consider for example the connection speed to the site, etc. But generally – yes because multi site is more resource intensive than single-sites. It is running several sites inside a single hosting box. Resources are shared within all sub-sites in a multi site so it is why this appears slower than single-sites.

But thanks for pointing out – we already have several performance improvements which will be implemented in future releases. But for now immediate solutions would be to:

• Upload package directly via SFTP to bypass uploading by chunks then restore via package manager.
• If your site is demanding (high users, high number of content, high traffic) – would be best to host this via VPS or dedicated hosting.

That’s it and thanks again for using Prime Mover, wish you best of luck in your projects! Cheers.

Thank you for using Prime Mover and for rating it 5-stars! Happy to hear the migration went well. I think you are restoring it via the default browser upload feature which is slow because it slices the package into chunks to fit your server PHP uploads specifications.

You can speed this up by uploading the entire package via SFTP (or hosting file manager) directly to the export directory and restore it via package manager. This is also supported in free version. Cheers!

Thank you for rating the plugin 5-stars. We are happy to know that you find the plugin easy to use and reliable. Cheers!

Thank you for the question and for using Prime Mover! The best strategy is to always test your site before you roll out to your new server with better specs. This is to make sure that your current site functionality will still work with the new server.

There are several things to test in this case including:

• Visual testing (how the site looks – design related)
• Functionality – the site unique features
• Plugins compatibility (e.g. you might be using plugin that is not compatible with newer PHP version ,etc.)
• Themes compatibility (e.g. your theme might not work with newer PHP version).
• Database compatibility – you might be using custom functionality that still depends access on older database version.

In this case – it would be best to test it in an environment similar to your new server (e.g. same PHP version, same server (e.g. Apache, Nginx), same OS (e.g. Linux or Windows server), same MySQL version, etc.).

You can do all this test in your local environment if you can have it. It is always better to test locally so you can easily debug things just in case something is not working.

Full local testing before moving to new production server will give you an idea of your site compatibility with the new server. Once you see that your site fully works in that new server specs. This is the only time to move to production.

You can use Prime Mover to do all the site migrations (e.g. from your current server to local server, current server to new server ,etc.). You can also use Prime Mover to backup things first before you test (e.g. update plugins ,or do some experiments, etc.)

Hi Dareko,

Thank you for using Prime Mover! First, some quick troubleshooting are as follows before you do the export:

• Does the site front end and back end fully works without any database or SQL errors? Usually if the site is broken due to SQL errors then this must be fixed first before exporting the site.
• Does your new SQL 8 configuration allows PDO connection to third party app (e.g. plugins)? You can test this by writing a simple connection code using PDO. If you cannot connect it, it is why you get connection refused error. You might need to check this with your host on how to connect to your dB.

If the above troubleshooting does not able to pinpoint the issue. We are interested in knowing more about this problem and how this happens.

In this case – we would like to take a deeper look in your simple environment in order to reproduce this issue. Please open an official ticket to our technical support here. Once we received the ticket – we will request some server logs or migration logs that will pinpoint the issue. For security reasons – these server logs cannot be post in public forum.

So I’m closing this one and we will continue the discussion on our official tech support panel. Thank you!

Hello Danereh,

Thank you for using Prime Mover! Regarding your question – if you want to restore a package with a different ID. You can do any of the following solutions:

• Create a new subsite /blank subsite matching a specific blog ID of your package. For example – if the package has a blog ID of 2 during export – you need to restore the package to blog ID of 2 as well to match it. So you need to create a subsite with blog ID of 2. If you are starting with a blank multisite – this is easy because you simply need to add a new subsite and it will assume an ID of 2. If you have an existing multisite with many sites already – you need to use the method mention in the tutorial link. Once the blank subsite is created wit h the target blog ID – you should now be able to restore the package.
• If you still have access to your original / source site – you simply need to create another export targeting to the correct blog ID of the target site. This requires though re-creating the export which is only necessary if you need to.

If you want to get the blog ID associated with the package, you can read this tutorial. For details, below are the tutorial links that will help resolve this issue:

• Can I change the exporting Blog ID to another site importing blog ID?
• How to get the blog ID of the WPRIME package?

Please take note that some of the above solutions are included in the Prime Mover PRO. If you have further questions pertaining to a PRO feature – please let us know about it in our official support channel. It is because support of PRO features are not allowed in this forum. Thanks again!

Hi, thanks for using Prime Mover! We have receive similar ticket on our official support system. We are closing this one as duplicate and continuing the discussion there.

For your privacy – please remove the link in your original post and it was meant only for developers. You already sent us a copy of that. Thank you!