Migrating from old stack to new stack

Keywords: WordPress Multisite - AWS - Technical issue - Upgrade

bnsupport ID: ed1414d2-7d0f-d358-c038-be00fac8dc2d

bndiagnostic output:

? Apache: Found possible issues
? Connectivity: Found possible issues
? Resources: Found possible issues
? Php: Found possible issues
https://docs.bitnami.com/general/apps/wordpress/administration/use-pagespeed/#disable-pagespeed
https://docs.bitnami.com/general/apps/wordpress/troubleshooting/debug-errors-apache/
https://docs.bitnami.com/bch/apps/moodle/troubleshooting/deny-connections-bots-apache/
https://docs.bitnami.com/general/faq/administration/use-firewall/
https://docs.bitnami.com/installer/faq/linux-faq/administration/increase-memory-linux/
https://docs.bitnami.com/general/apps/wordpress/configuration/configure-phpfpm-processes/

bndiagnostic failure reason: The suggested guides are not related with my issue

Description:
We’ve been using Bitnami WP MS stack on AWS for a while and it was a godsend for our little non-profit.

I wanted to update VM to the latest available from Bitnami and realized now that you guys have changed a lot in the stack and the old instructions (export DB, compress configs and htdocs, transfer everything to the new VM and import/decompress) are no longer applicable.

Short of paying for AIO WP Migration Multisite, are there any other ways of moving our content from the old stack to the new stack?

I’m not a WP expert, the directories structure is different with the new stack so I’m looking for some guidance on how to adapt the old migration instructions to work with the new stack.

Also, why did you guys move from mysql to MariaDB?

Also, what’s the equivalent of sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1 in the new stack?

Hi @stangri,

As it’s not straightforward to migrate without using the plugin I recommend asking in the official WordPress forum for more information about how to proceed.

The only relevant difference is that the wordpress data is now in “/opt/bitnami/wordpress” while it used to be in “/opt/bitnami/apps/wordpress”. If you can’t find a particular file I recommend using “find”:

sudo find /opt/bitnami -type f -name FILENAME 

And directories:

sudo find /opt/bitnami -type d -name FOLDERNAME

This is mainly because of differences in licensing.

The newer stacks don’t have a Bitnami banner.

Regards,
Michiel

On top of that the /opt/bitnami/apps/wordpress used to contain conf directory and htdocs directory, neither one of which exist under /opt/bitnami/wordpress. To me that’s more relevant difference.

If the only relevant difference is above, why is it not straightforward to migrate then? There used to be a guide on exporting database and transferring the WP files from one instance to another, if just the path has changed, why not publish another guide if only the path has changed? Why push us to a paid plugin for a simple path change?

Also, do you not think it’s a bit hypocritical that you made the old stack, the new stack, you know all the differences between them, yet you’re sending me to a different community for help trying to identify the differences and how to overcome them while migrating?

Hello @stangri,

I think that what my colleague was proposing was to ask in the official forums for guidance regarding other options and plugins to migrate your multisite instance.

You do have other options besides AIO plugin, one of them being making a backup of your current WP instance and then restoring it in your new instance.

In the plugin’s department, although our recommended AIO is not valid for multisite instances, there is a multitude of other plugins focused on instance migrations and data backup/restoration. Making a quick search, the Migrate Guru is a well-liked plugin and one of the best options for multisite migration. Having said that, as we haven’t investigated this (or others) plugins focused on multisite migration we do not have a guide on it currently.

Keep in mind to create backups of your Wordpress and database before you start using any of the available options.

Regards,
Francisco de Paz