Return to Answer

Never try the upgrade on live :)

Take small steps. Sometimes CiviCRM chokes on a minor upgrade step, but you can get the upgrader to run from v1.2.3 all the way to v4.5.6 ... in that case, you'll have a more robust process if you don't try to do it all in one leap. You can automate the upgrade to v4.5.6, then work out what's breaking at the next step. (Some examples of why this is even a thing might be helpful? Version numbers in this paragraph are made up.)

Automate the process so that it's repeatable, and therefore can be tested thoroughly. This means investing a little extra time in writing a bash script which performs the upgrade steps, and then using that script only to perform each test run. This approach means that any extra steps (eg adjusting some index) end up in the script, and the process is repeated as consistently as possible. Some upgrades can take hours, and you want to avoid pressuring yourself to "just make a small change" in order to save starting over.

Have a fast test environment. On the one hand, it needs to accurately mirror the environment you'll perform the final upgrade on. On the other hand, if you can use a system with solid state drives, or put all of MySQL's data into RAM during the upgrade, you'll save a lot of time. Tune your MySQL. (A couple dozen upgrade runs will give you plenty of data in mysqltuner also...)

Observe DB activity during the upgrade. Use mytop, to shows current SQL queries as they happen. (You can do this in SQL with SHOW FULL PROCESSLIST, but mytop is convenient.) This will let you know if a query is taking a long time, and might inform your approach to help you reduce upgrade time. (Maybe, it's taking eight hours to upgrade a chunk of data you no longer needed, or maybe you can speed the process by adding an index in your upgrade script, then removing it after the upgrade is done.) Note also the CiviCRM debug log as mentioned in Jon's comment.

Observe upgrade progress also: SELECT version FROM civicrm_domain ; - the result will change as CiviCRM progresses through the upgrade steps.

Generate a reduced dataset for testing. I might bring the total contacts down to a couple thousand from the original dataset, and similarly reduce other large tables to a small sample of the original. This means the process is no longer an accurate test of the upgrade, but it does ensure you are testing schema changes, and if it can reduce each repeated upgrade run by minutes, it can save you hours down the track. If doing this, make sure you then test the full upgrade a few times before deploying - by this stage, it will run without your attention anyway, since (3).

Dump data for components you don't care about. Some tables in CiviCRM can grow huge, and can steal more time then they deserve. Look at the table sizes (MySQL: show largest tables) and decide which are worth pruning. You might decide to drop mailings more than two years old, or an activity type you retired a while back, or ... (Jon also mentions this here.)

Consider turning off logging. CiviCRM's trigger logging may affect upgrade performance, and you could turn it off during the upgrade. (This needs to be an informed decision, since a large chunk of data changes "off the radar" during upgrade may not be acceptable to your org.)

Ask for help. You might find some assistance here or on CiviCRM chat if you're stuck. If you have a challenging upgrade to deal with, it's worth finding a good team to support your CiviCRM site!

Never try the upgrade on live :)

Take small steps. Sometimes CiviCRM chokes on a minor upgrade step, but you can get the upgrader to run from v1.2.3 all the way to v4.5.6 ... in that case, you'll have a more robust process if you don't try to do it all in one leap. You can automate the upgrade to v4.5.6, then work out what's breaking at the next step. (Some examples of why this is even a thing might be helpful? Version numbers in this paragraph are made up.)

Automate the process so that it's repeatable, and therefore can be tested thoroughly. This means investing a little extra time in writing a bash script which performs the upgrade steps, and then using that script only to perform each test run. This approach means that any extra steps (eg adjusting some index) end up in the script, and the process is repeated as consistently as possible. Some upgrades can take hours, and you want to avoid pressuring yourself to "just make a small change" in order to save starting over.

Have a fast test environment. On the one hand, it needs to accurately mirror the environment you'll perform the final upgrade on. On the other hand, if you can use a system with solid state drives, or put all of MySQL's data into RAM during the upgrade, you'll save a lot of time. Tune your MySQL. (A couple dozen upgrade runs will give you plenty of data in mysqltuner also...)

Observe DB activity during the upgrade. Use mytop, to shows current SQL queries as they happen. (You can do this in SQL with SHOW FULL PROCESSLIST, but mytop is convenient.) This will let you know if a query is taking a long time, and might inform your approach to help you reduce upgrade time. (Maybe, it's taking eight hours to upgrade a chunk of data you no longer needed, or maybe you can speed the process by adding an index in your upgrade script, then removing it after the upgrade is done.) Note also the CiviCRM debug log as mentioned in Jon's comment.

Observe upgrade progress also: SELECT version FROM civicrm_domain ; - the result will change as CiviCRM progresses through the upgrade steps.

Generate a reduced dataset for testing. I might bring the total contacts down to a couple thousand from the original dataset, and similarly reduce other large tables to a small sample of the original. This means the process is no longer an accurate test of the upgrade, but it does ensure you are testing schema changes, and if it can reduce each repeated upgrade run by minutes, it can save you hours down the track. If doing this, make sure you then test the full upgrade a few times before deploying - by this stage, it will run without your attention anyway, since (3).

Dump data for components you don't care about. Some tables in CiviCRM can grow huge, and can steal more time then they deserve. Look at the table sizes (MySQL: show largest tables) and decide which are worth pruning. You might decide to drop mailings more than two years old, or an activity type you retired a while back, or ... (Jon also mentions this here.)

Consider turning off logging. CiviCRM's trigger logging may affect upgrade performance, and you could turn it off during the upgrade. (This needs to be an informed decision, since a large chunk of data changes "off the radar" during upgrade may not be acceptable to your org.)

Ask for help. You might find some assistance here or on CiviCRM chat if you're stuck. If you have a challenging upgrade to deal with, it's worth finding a good team to support your CiviCRM site!

Never try the upgrade on live :)

Take small steps. Sometimes CiviCRM chokes on a minor upgrade step, but you can get the upgrader to run from v1.2.3 all the way to v4.5.6 ... in that case, you'll have a more robust process if you don't try to do it all in one leap. You can automate the upgrade to v4.5.6, then work out what's breaking at the next step. (Some examples of why this is even a thing might be helpful? Version numbers in this paragraph are made up.)

Automate the process so that it's repeatable, and therefore can be tested thoroughly. This means investing a little extra time in writing a bash script which performs the upgrade steps, and then using that script only to perform each test run. This approach means that any extra steps (eg adjusting some index) end up in the script, and the process is repeated as consistently as possible. Some upgrades can take hours, and you want to avoid pressuring yourself to "just make a small change" in order to save starting over.

Have a fast test environment. On the one hand, it needs to accurately mirror the environment you'll perform the final upgrade on. On the other hand, if you can use a system with solid state drives, or put all of MySQL's data into RAM during the upgrade, you'll save a lot of time. Tune your MySQL. (A couple dozen upgrade runs will give you plenty of data in mysqltuner also...)

Observe DB activity during the upgrade. Use mytop, to shows current SQL queries as they happen. (You can do this in SQL with SHOW FULL PROCESSLIST, but mytop is convenient.) This will let you know if a query is taking a long time, and might inform your approach to help you reduce upgrade time. (Maybe, it's taking eight hours to upgrade a chunk of data you no longer needed, or maybe you can speed the process by adding an index in your upgrade script, then removing it after the upgrade is done.) Note also the CiviCRM debug log as mentioned in Jon's comment.

Observe upgrade progress also: SELECT version FROM civicrm_domain ; - the result will change as CiviCRM progresses through the upgrade steps.

Generate a reduced dataset for testing. I might bring the total contacts down to a couple thousand from the original dataset, and similarly reduce other large tables to a small sample of the original. This means the process is no longer an accurate test of the upgrade, but it does ensure you are testing schema changes, and if it can reduce each repeated upgrade run by minutes, it can save you hours down the track. If doing this, make sure you then test the full upgrade a few times before deploying - by this stage, it will run without your attention anyway, since (3).

Dump data for components you don't care about. Some tables in CiviCRM can grow huge, and can steal more time then they deserve. Look at the table sizes (MySQL: show largest tables) and decide which are worth pruning. You might decide to drop mailings more than two years old, or an activity type you retired a while back, or ... (Jon also mentions this here.)

Consider turning off logging. CiviCRM's trigger logging may affect upgrade performance, and you could turn it off during the upgrade. (This needs to be an informed decision, since a large chunk of data changes "off the radar" during upgrade may not be acceptable to your org.)

Ask for help. You might find some assistance here or on CiviCRM chat if you're stuck. If you have a challenging upgrade to deal with, it's worth finding a good team to support your CiviCRM site!

Never try the upgrade on live :)

Take small steps. Sometimes CiviCRM chokes on a minor upgrade step, but you can get the upgrader to run from v1.2.3 all the way to v4.5.6 ... in that case, you'll have a more robust process if you don't try to do it all in one leap. You can automate the upgrade to v4.5.6, then work out what's breaking at the next step. (Some examples of why this is even a thing might be helpful? Version numbers in this paragraph are made up.)

Automate the process so that it's repeatable, and therefore can be tested thoroughly. This means investing a little extra time in writing a bash script which performs the upgrade steps, and then using that script only to perform each test run. This approach means that any extra steps (eg adjusting some index) end up in the script, and the process is repeated as consistently as possible. Some upgrades can take hours, and you want to avoid pressuring yourself to "just make a small change" in order to save starting over.

Have a fast test environment. On the one hand, it needs to accurately mirror the environment you'll perform the final upgrade on. On the other hand, if you can use a system with solid state drives, or put all of MySQL's data into RAM during the upgrade, you'll save a lot of time. Tune your MySQL. (A couple dozen upgrade runs will give you plenty of data in mysqltuner also...)

Observe DB activity during the upgrade. Use mytop, to shows current SQL queries as they happen. (You can do this in SQL with SHOW FULL PROCESSLIST, but mytop is convenient.) This will let you know if a query is taking a long time, and might inform your approach to help you reduce upgrade time. (Maybe, it's taking eight hours to upgrade a chunk of data you no longer needed, or maybe you can speed the process by adding an index in your upgrade script, then removing it after the upgrade is done.) Note also the CiviCRM debug log as mentioned in Jon's comment.

Observe upgrade progress also: SELECT version FROM civicrm_domain ; - the result will change as CiviCRM progresses through the upgrade steps.

Generate a reduced dataset for testing. I might bring the total contacts down to a couple thousand from the original dataset, and similarly reduce other large tables to a small sample of the original. This means the process is no longer an accurate test of the upgrade, but it does ensure you are testing schema changes, and if it can reduce each repeated upgrade run by minutes, it can save you hours down the track. If doing this, make sure you then test the full upgrade a few times before deploying - by this stage, it will run without your attention anyway, since (3).

Dump data for components you don't care about. Some tables in CiviCRM can grow huge, and can steal more time then they deserve. Look at the table sizes (MySQL: show largest tables) and decide which are worth pruning. You might decide to drop mailings more than two years old, or an activity type you retired a while back, or ... (Jon also mentions this here.)

Consider turning off logging. CiviCRM's trigger logging may affect upgrade performance, and you could turn it off during the upgrade. (This needs to be an informed decision, since a large chunk of data changes "off the radar" during upgrade may not be acceptable to your org.)

Ask for help. You might find some assistance here or on CiviCRM chat if you're stuck. If you have a challenging upgrade to deal with, it's worth finding a good team to support your CiviCRM site!

Never try the upgrade on live :)

Take small steps. Sometimes CiviCRM chokes on a minor upgrade step, but you can get the upgrader to run from v1.2.3 all the way to v4.5.6 ... in that case, you'll have a more robust process if you don't try to do it all in one leap. You can automate the upgrade to v4.5.6, then work out what's breaking at the next step. (Some examples of why this is even a thing might be helpful? Version numbers in this paragraph are made up.)

Automate the process so that it's repeatable, and therefore can be tested thoroughly. This means investing a little extra time in writing a bash script which performs the upgrade steps, and then using that script only to perform each test run. This approach means that any extra steps (eg adjusting some index) end up in the script, and the process is repeated as consistently as possible. Some upgrades can take hours, and you want to avoid pressuring yourself to "just make a small change" in order to save starting over.

Have a fast test environment. On the one hand, it needs to accurately mirror the environment you'll perform the final upgrade on. On the other hand, if you can use a system with solid state drives, or put all of MySQL's data into RAM during the upgrade, you'll save a lot of time. Tune your MySQL. (A couple dozen upgrade runs will give you plenty of data in mysqltuner also...)

Observe DB activity during the upgrade. Use mytop, to shows current SQL queries as they happen. (You can do this in SQL with SHOW FULL PROCESSLIST, but mytop is convenient.) This will let you know if a query is taking a long time, and might inform your approach to help you reduce upgrade time. (Maybe, it's taking eight hours to upgrade a chunk of data you no longer needed, or maybe you can speed the process by adding an index in your upgrade script, then removing it after the upgrade is done.)

Observe upgrade progress also: SELECT version FROM civicrm_domain ; - the result will change as CiviCRM progresses through the upgrade steps.

Generate a reduced dataset for testing. I might bring the total contacts down to a couple thousand from the original dataset, and similarly reduce other large tables to a small sample of the original. This means the process is no longer an accurate test of the upgrade, but it does ensure you are testing schema changes, and if it can reduce each repeated upgrade run by minutes, it can save you hours down the track. If doing this, make sure you then test the full upgrade a few times before deploying - by this stage, it will run without your attention anyway, since (3).

Dump data for components you don't care about. Some tables in CiviCRM can grow huge, and can steal more time then they deserve. Look at the table sizes (MySQL: show largest tables) and decide which are worth pruning. You might decide to drop mailings more than two years old, or an activity type you retired a while back, or ... (Jon also mentions this here.)

Consider turning off logging. CiviCRM's trigger logging may affect upgrade performance, and you could turn it off during the upgrade. (This needs to be an informed decision, since a large chunk of data changes "off the radar" during upgrade may not be acceptable to your org.)

Ask for help. You might find some assistance here or on CiviCRM chat if you're stuck. If you have a challenging upgrade to deal with, it's worth finding a good team to support your CiviCRM site!

Never try the upgrade on live :)

Take small steps. Sometimes CiviCRM chokes on a minor upgrade step, but you can get the upgrader to run from v1.2.3 all the way to v4.5.6 ... in that case, you'll have a more robust process if you don't try to do it all in one leap. You can automate the upgrade to v4.5.6, then work out what's breaking at the next step. (Some examples of why this is even a thing might be helpful? Version numbers in this paragraph are made up.)

Automate the process so that it's repeatable, and therefore can be tested thoroughly. This means investing a little extra time in writing a bash script which performs the upgrade steps, and then using that script only to perform each test run. This approach means that any extra steps (eg adjusting some index) end up in the script, and the process is repeated as consistently as possible. Some upgrades can take hours, and you want to avoid pressuring yourself to "just make a small change" in order to save starting over.

Have a fast test environment. On the one hand, it needs to accurately mirror the environment you'll perform the final upgrade on. On the other hand, if you can use a system with solid state drives, or put all of MySQL's data into RAM during the upgrade, you'll save a lot of time. Tune your MySQL. (A couple dozen upgrade runs will give you plenty of data in mysqltuner also...)

Observe DB activity during the upgrade. Use mytop, to shows current SQL queries as they happen. (You can do this in SQL with SHOW FULL PROCESSLIST, but mytop is convenient.) This will let you know if a query is taking a long time, and might inform your approach to help you reduce upgrade time. (Maybe, it's taking eight hours to upgrade a chunk of data you no longer needed, or maybe you can speed the process by adding an index in your upgrade script, then removing it after the upgrade is done.) Note also the CiviCRM debug log as mentioned in Jon's comment.

Observe upgrade progress also: SELECT version FROM civicrm_domain ; - the result will change as CiviCRM progresses through the upgrade steps.

Generate a reduced dataset for testing. I might bring the total contacts down to a couple thousand from the original dataset, and similarly reduce other large tables to a small sample of the original. This means the process is no longer an accurate test of the upgrade, but it does ensure you are testing schema changes, and if it can reduce each repeated upgrade run by minutes, it can save you hours down the track. If doing this, make sure you then test the full upgrade a few times before deploying - by this stage, it will run without your attention anyway, since (3).

Dump data for components you don't care about. Some tables in CiviCRM can grow huge, and can steal more time then they deserve. Look at the table sizes (MySQL: show largest tables) and decide which are worth pruning. You might decide to drop mailings more than two years old, or an activity type you retired a while back, or ... (Jon also mentions this here.)

Consider turning off logging. CiviCRM's trigger logging may affect upgrade performance, and you could turn it off during the upgrade. (This needs to be an informed decision, since a large chunk of data changes "off the radar" during upgrade may not be acceptable to your org.)

Ask for help. You might find some assistance here or on CiviCRM chat if you're stuck. If you have a challenging upgrade to deal with, it's worth finding a good team to support your CiviCRM site!