Support

May 23, 2016 at 4:04 am

Hi there,

Each site is different as people setup their events differently, so in terms of ‘normal’ the above may well be. It depends on the amount of events, registration etc that need to be migrated and how much your server can cope with.

The default ‘step size’ for each migration is 50, this is the amount of rows that are updated within the database within each step, however EE will also attempt to throttle the steps if the queries start to take longer amount of time than expected (to prevent timeouts)

We recommend testing the migration on a development copy of the site to see how long it will take on your site before running it live as it gives you an idea of much downtime you will have on the live site. You then run the migration on the live site at a convenient time or migrate the dev site to live (although it depends on the use case if you can do this)

Did you finish the migration and EE4 is now up and running?

May 24, 2016 at 4:39 am

What kind of server is the site running on?

Check how much memory is available on the site, you’ll want at least 96MB but more if available.

As mentioned if EE detects that the queries are taking longer than expected it will drop down the step size to prevent timeouts. If your server is under load or does not have enough resources then the migration is going to take longer.

Do you have a development server you can copy the site to?

You could use something like Duplicator to copy the site over to the other server and run the migration there.

May 24, 2016 at 6:24 am

You can’t, not easily.

You would need to put the live site into maintenance mode to prevent further registrations, migrate the site, run the EE4 migrations and then migrate the data back to live.

The reason for testing on a dev server (which should be different) before attempting this is to see if the migration runs quicker on that server. If so then the above will likely be your best method to migrate the site.

Note before making any changes, make sure you have a good working backup of the current site.

May 24, 2016 at 7:22 am

Yes, I understand that which is why I said test on another server and see if it migrates quicker.

The steps would be.

Create a clone of the site as it is now (for example using Duplicator) and install that on another server, run the migrations there. You leaving the site active for now as your testing to make sure you can run the migrations within a reasonable time frame on another server.

Monitor how long it takes on the dev server and confirm if the migration works as expected, so your testing the migration away from the live site, using all of the live data, to confirm that it works, and does so within a reasonable amount of time.

The dev site should NOT be the same server the live site is on and should have enough resources available to be able to run the migrations. As mentioned before I’d recommend at least 96MB.

If the migration runs fine on the dev site and you’ve tested and confirmed all works well, you have an idea of how long the migration will take.

Then when ready to migrate the live site, put the live site into maintenance mode.

Copy the live site to another instance on the dev server (you will need to migrate the database to run on the dev site).

Run the migrations (you now know roughly how long they will take because you’ve tested this already) and once complete migrate the site back to the live server.

—–

If you prefer to just run the migrations on the live site you can check you have enough memory available on the live site first and retry.

Make sure you backup the site before running the migrations.

—–

Whichever step you chose you can not take live registrations whilst migrating the data as it is not easily transferred from EE3 to EE4 once the migrations have been ran.