Product Center

Migrations Scripts: Moving from Old to New Community Platforms

This blog post explains how we are using software migration scripts to migrate over 10 Greenwire — continue reading
Posted by Ronald te Brake
September 11, 2019

This blog post explains how we are using software migration scripts to migrate over 10 Greenwire platforms to Open Social. Currently, three platforms are already up and running.

For those who may not know: Greenpeace International is a worldwide nonprofit organization that aims to protect the environment and promote world peace. Originally founded in 1971, the organization is now active in over 40 countries and has more than 2.8 million supporters.

Greenwire and Open Social have a long history! Here’s the short version:

  • In 2010, GoalGorilla was asked to create the first version of Greenwire 1.0 for The Netherlands using Drupal 6.
  • In 2013, Greenwire 2.0 was created using Drupal 7 and rolled out globally after receiving the following challenge: “We want to create the best open-source social platform ever made by mankind and save the planet. No pressure ;)”.
  • Greenwire 3.0 was successfully created in 2015 with new functionalities and a 600% increase in volunteering.
  • Greenwire won the Dutch Interactive Award 2015 in the category Social & Communities.
  • Open Social was created after the demand for online communities such as Greenwire increased.
  • Now, Greenwire 4.0 will be migrated completely to Open Social.

Greenwire 3.0 in 2015

This is the second post in a two-piece series that explains the software migration process of Greenpeace Greenwire to Open Social. Read about how we identified missing gap features in the first post!

The ‘whats’ and ‘whys’ of migration scripts

When you decide to change your old tools to new ones, whether it’s a CMS or community platform, you need to migrate your data from the old to the new version. While this seems pretty straight-forward, it can be tricky to get it right.

We decided to use a migration script to move the data from Greenwire 3.0 platforms to Open Social’s community software.

What is a migration script? For the non-techies out there, a migration script is used to change a database from one version to another by ‘mapping’ the data so that it can be migrated to the right locations.

For the techies out there, our migration script consists of Drupal modules and custom implementations for repetitive tasks such as getting the latest migration configurations, creating in-between database backups and measuring the duration.

Why do we use this technique? We use migration scripts because it ensures that we can make database changes (like moving data from one platform to another) without breaking the database integrity and preventing data loss.

We can also re-use this ‘script’ for every Greenwire platform, which means we can migrate the data more efficiently than with a custom migration.

 Advantages of using scripts

  • Saves time by re-using tested and proven technology to migrate data for multiple platforms.
  • You have more stability during the runtime of the migration.

Disadvantages of using scripts

  • Using a migration script instead of a custom implementation can be slower per platform.

Migration script running

How to run a migration script

There are a few steps involved to complete a successful migration. Warning: this will get technical.

Before running the scripts, we sat together with the Greenwire teams to explain the planning and ask for any critical information. It also took a few weeks to actually map out the script for the first platform migration.

Before long, we could migrate!

  1. The main platform, Greenpeace Greenwire 3.0, goes into a temporary content freeze so that no new data is created. All platforms are informed of the freeze.
  2. We download the latest public and private content data files and conduct a ‘database dump’.
  3. We power up a clean installation of Open Social and start running our ‘script’ – moving the new data into Open Social. We make regular backups in case we run into any issues.
  4. After all the data is migrated, we conduct sanity checks to make sure it all went smoothly. This also includes some manual checks (e.g., disabling migration modules, running all the queue workers, and updating the search index).
  5. We then upload the new Open Social database to the hosting platform.

From there on, the new community can conduct their own checks and adjust the Open Social community platform according to their wants and needs. They give us the green light to go live!

Successful migration to Open Social

We’ve worked hard to ensure successful migrations for Greenpeace Greenwire 4.0. So far, three platforms (Germany, France, and Russia) are up and running on their new Open Social platform.

What does a successful migration even look like? We consider a data migration a success when:

  • The script has run within an acceptable time period and without unexpected errors and notifications.
  • When the customer completed a successful user acceptance testing (UAT) and no new large issues are found.
  • When all the high priority bugs have been solved.

After the migration is complete, we focus on fixing low priority bugs and stabilizing the platform by making sure there are no performance issues. We ensure that our customers have the best platform possible with regular check-ins.

Our final lessons for you

We’ve learned a lot during the migration of Greenwire platforms to Open Social. It’s only fair for us to share our biggest pieces of wisdom with you!

When conducting a software migration, make sure to:

Estimate how long the migration will take. Some migrations took a few hours, while others took days. When you take time to understand how long the migration will be, it’s easier to plan everything else and set up realistic expectations for customers.

Understand the source of bugs. If you find bugs during this process, investigate whether these are product-related or script-related. Script bugs need to be fixed before the final migration takes place and therefore, have a higher priority. Product-related bugs can be added to the backlog for after the platform is live.

Use larger test samples. When you test the migrated data, use large test samples (various topics, groups, events) because some people may use the same content types differently and therefore, result in different errors.

It’s a big job to migrate over 10 platforms from one software to another! It takes patience, open communication with clients, and a great team. We are open to sharing more about our process.

If you are looking to migrate software or are thinking about migrating to Open Social, don’t hesitate to reach out to use for questions and information. 

 

Greenwire 4.0 showcase

In this article we discuss

Related articles