Sometimes, your business tools and applications become outdated. Or perhaps, with all the choices we have — continue reading
Sometimes, your business tools and applications become outdated. Or perhaps, with all the choices we have today, you find better options for your needs. You’re at your laptop and think: how do I best switch from one tool to the other?
Software migration is the process of moving your applications from one environment to the other. For example, you might want to change from a custom-built platform to Microsoft Azure or Amazon Web Services.
Or perhaps, just like Greenpeace Greenwire, you want to move from a legacy community platform to Open Social’s solution.
For those who may not know: Greenpeace International is a worldwide independent nonprofit organization that aims to protect the environment and promote world peace. Originally founded in 1971, the organization is now active in 44 countries and has 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.
The blog post explains the first step of our software migration process for Greenpeace Greenwire: identifying the missing gap features and evaluating how to best integrate the strengths of the old platform with the new one.
This is the first post in a three-piece series that explains the software migration process of Greenpeace Greenwire to Open Social.
How to do software migration right
There are various different software migration strategies out there, and they differ according to time and practices. However, they all have something in common: a high level of vigilance.
Open Social tackled the migration of Greenwire to Open Social with the following (broadly outlined) steps below.
- Step 1: Minding the gap
- Step 2: Writing the migration script
- Step 3: Executing the migratio
These will be subsequently explained in each blog post, beginning with the initial software assessment and the gap features.
Minding the gap (features)
Initial software assessment
We conducted an initial software assessment to detect the differences between the two platforms, any flaws in the current structure, and code quality, architecture, and automated test assessments. This assessment also identified the gap features, which are defined as any features the old platform has that is necessary in the new platform for the community to continue to grow.
Developing the migration process
After the assessment, Open Social was able to provide Greenwire with the overall cost and time of the project and create a migration guide, the main document that outlines the migration process. We also reached out to all national and regional Greenwire organizations (NROs) that run the individual platforms that will all be migrated to Open Social.
Introducing the migration to Greenwire
Several meetings and workshops took place to explain the migration process and introduce the current NRO site managers to Open Social. The workshops consisted of two parts, firstly an explanation of all (new) features and afterward an interactive part in which the site managers could play around with Open Social with some challenges.
Identifying gap features
During this first phase, it’s critical to identify the important features for Greenwire that aren’t available (yet) in Open Social.
A full feature comparison was made so that the importance of each feature can be identified and replicated. We compared the Greenwire feature list to Open Social to determine the gap and spoke with the communities and their managers to understand how features are used.
As it turned out, one of the major differences was that the groups in Greenwire are much more flexible than the current groups in Open Social. They have much more flexibility in determining how content is placed within groups and they could create hidden/secret groups.
Our solution was to create two new groups types:
- Flexible groups. This group type allows community members to choose how members can join groups and the content visibility options (public, private, community-only) for the content inside this group.
- Secret groups. This group type can only be created by site managers and no one can find the group unless they receive an invite.
This means that Greenwire has flexible options when creating groups for different use cases; planning local events, secret rallies, or sharing sensitive knowledge. And can, therefore, function as they did on their old platform!
Don’t skip any steps!
We’ve learned a lot during our first steps of migrating the Greenwire platforms to Open Social. It’s only fair of us to share our biggest pieces of wisdom with you!
Be diligent with every platform. When migrating projects that have multiple domain/sites platforms, you need to identify the differences per individual platform. Avoid picking one as an example of the rest, which could lead to missing features – each one is a unique community.
Create a proper test data set for each migrating platform. This step might take time but it t saves the hassle of sanitization and avoids missing features. It’s also advisable to make it large enough to get a proper estimation on throughput times.
Coming next; migration scripts
Now that the gap analysis was complete, we started working on the migration scripts! Stay tuned for our next blog post on our process.
