Our Membership Site Migration from ExpressionEngine to WordPress: Discovery

Webster’s Dictionary defines Discovery as…

Just kidding. 😊Hi! And welcome to Part 2 of our blog series on Food Blogger Pro’s migration to WordPress. 

If you want to get caught up, be sure to check out Part 1 here to learn more about our decision to move from ExpressionEngine to WordPress. 

Today we’re talking about Discovery. Aka. The first step in our five-part migration process!

As the first stage of our migration process, Discovery included:

1. Writing an Initial Planning Document
2. Assigning Team Roles
3. Requirements Gathering
4. Evaluating Software
5. Documenting Decision Rationale
6. Creating Development Tasks and Tickets

We’ll cover all of these steps in this post and talk about why they’re important, how they impacted the project as a whole, and how you might want to implement similar steps as you’re starting a big project. 

If you’re doing Discovery on your own project, it might look a bit different! Ultimately, the goal of Discovery is to make as many decisions as possible before you get into implementation. When you’re cooking a recipe, it’s easiest if you buy all of the ingredients in advance — and a huge delay if you have to go to the grocery store to pick up the items you missed.

Before we dive in, it’s important to note that we used Asana, a project management application, to track our progress through these steps. We had a different project within Asana for each phase of our migration project, so everything we’ll talk about today is taking place in our Discovery project.

Ready? Let’s do this!

Writing an Initial Planning Document

One of the first things that our developer, Daniel, requested when he started this project with us was a seven-page Initial Planning Document. 

Daniel was familiar with Food Blogger Pro, but he wasn’t as in-tune with the ins and outs of the business like the other three people (Bjork, Raquel, and yours truly 👋) on the migration team were.

That’s why the Initial Planning Document was so helpful and necessary – it was a place where we could braindump information about our existing ExpressionEngine site and start solidifying our vision for our eventual WordPress site. The Initial Planning Document was the foundation for ensuring everyone had access to the same information.

Our Initial Planning Document covered:

What is the Food Blogger Pro website

In this section, we answered questions like how many existing members we had at the time (~2,600), the key functional components of the site (course videos hosted by Vimeo, forums, deals, live videos hosted by CrowdCast, blog, etc.), how affiliate payments work (recurring monthly affiliate payments are tied to membership signups), and any third-party apps or tools we use on FBP (ActiveCampaign, Intercom, etc.). 

Answers to High-Level Questions

These questions helped guide our planning and helped everyone understand the state of the business. These questions included:

• What’s our yearly revenue? 
• Where does the business want to go and why would this move to WordPress help us get there?
• What are the ongoing costs to run the Food Blogger Pro website?
• Is it necessary to redesign at the same time as the migration?
• Is WordPress the best choice for us? What other CMSs have been considered?
• How do we determine success vs. failure for the migration?
• What risks are involved in this project?
• What research and evaluation has already been done?
• What’s the ideal migration time period?
• What’s the most important functional requirement to the site?
• What systems currently integrate into ExpressionEngine?
• What features can we ditch in the migration process (or use the out-of-the-box WordPress functionality instead)?
• How many total users are there? How many are active at a given time?
• How many forum posts are there in total?
• What day and time would have the least impact?

Potential Software Options

We listed some potential plugin solutions that we’d then evaluate at a later time. More on that in a bit!

Project Timeline

We outlined the preferred launch timing (early April to early May), how long each phase of our process should take (anywhere from 1 – 5 weeks), potential approaches (Waterfall vs. Agile), and team roles (again, more on that soon). We also wrote down any important dates that we needed to be aware of as we headed into this project, like upcoming enrollment periods and team member vacations.

The Initial Planning Document was a crucial piece of our Discovery process because it brought everyone up to speed on the state of the current ExpressionEngine site, while slowly starting to solidify the vision for our WordPress site. 

To be honest, I referred back to this Initial Planning Document a lot throughout the project, just to make sure that we were on-schedule and that our decisions were aligning with our overall vision.

Assigning Team Roles

Part of the Initial Planning Document was assigning team roles, and we had four main roles to fill:

1. Developer – write and fixes code; includes both frontend and backend development
2. QA – prepares requirements documents and performs manual testing against the requirements
3. Project Manager – schedules meetings, takes notes, identifies action items, provides progress updates, identifies and communicates project risks
4. Product Owner – provides definition of product requirements and performs final QA

Why was it important to define who was responsible for what? It helped define expectations and workload for each team member. It also helped underscore that the migration was a team effort, and how we’d work together.

We had only four team members working on this migration project, but we wanted to make sure that everyone’s roles matches up with their strengths and interests as much as possible. Not only would this make the project more enjoyable for everyone (i.e. they’re comfortable with and enjoying the work), but it also helped us ensure that we had the best people on the job.

Gathering Requirements

This was probably one of the most tedious parts of the whole migration project. 

Requirements define the current implementation of our features and they would guide the Development and QA processes. 

That said, we might have gone a bit overboard. 😉

In order to understand which requirements documents needed created, we added separate tasks to Asana, assigned them to the appropriate team member. 

We had a requirements document for each key feature on the site where we’d outline the functionalities, buttons, features, and special cases of each page on the site. We used Google Docs so that everyone on the team could contribute and troubleshoot.

Most of these requirements documents were broken up into three parts: an overview of the feature, frontend requirements, and backend requirements:

One easy way to navigate these often lengthy requirements was to add a Table of Contents at the beginning of each document (click Insert, then hover over Table of contents, then click With blue links). These links allow you to easily jump to any headers within the document. Nifty!

Once the requirements document was completed and signed off, we needed to create implementation tasks for each feature:

These tasks were created in our Development project in Asana, and we’ll chat about them in more detail in a jif. 

We also had a Requirements Overview document where we tracked the statuses, owners, and requirements doc for each feature on the site.

While this overall process was helpful, we went into a ton of detail in our requirements documents. While documenting access restrictions for a membership site is helpful, documenting the default setting on a page that five people have visited in the past six months wasn’t. Example:

We spent time documenting small details that weren’t incredibly useful when we could have been documenting these features in a more “big picture” way. 

Localization settings aren’t necessary for the way our membership site should work, so it wasn’t important to “require” location settings on our new site. Not only that, but we’d only have one English version of our site; there’s no need for a language setting if you can’t change it.

This was definitely a mistake on my part, as I was the one documenting most of our requirements. If we ever had a similar project in the future (😅), I’d try documenting our requirements in a way that prioritized the functionalities that were most important to bring over to the new site.  

Evaluating Software

Another key part of our Discovery process was evaluating the software we’d use, and it was especially important because it would largely impact development needs.

Instead of only looking at the features each plugin solution had, we evaluated each option against the following criteria:

• Frontend Ease of Use
• Admin Ease of Use
• Meets Feature Requirements
• Support Quality
• Roadmap Confidence
• Ability to Customize
• Openness to Contribution
• Available Contractors
• % Unit Test Coverage
• Price

Plugins have a lot of features, and it’s easy to get distracted by all the flashiness when you need to choose the best plugin to support your members. You should steal our evaluation methodology! It helped us understand what we actually needed to make the migration project a success, rather than seeing a feature and saying, “Ooh, that would be cool!”.

We knew we needed plugin solutions for:

• Memberships / protecting content behind a paywall
• Forums
• Courses

With this more holistic approach, we used a Google Sheet to evaluate several different plugins against our quantitative attributes:

Once we found the leaders for each plugin need category, we did a more thorough comparison of the features we actually needed:

We downloaded plugins, searched support articles, and reached out to plugin support teams to find the plugins that were best for us and our members.

We ultimately ended up going with:

• Memberships: Restrict Content Pro – Not only helps us create and manage our memberships, but it also lets us, as the name suggests, restrict content! 
• Forums: bbPress – A simple, easily customizable forum solution for WordPress sites. It’s free, open-source, and has just enough bells and whistles to help us provide a great discussion experience.
• Courses: A custom-built solution.

Let’s spend some time on that last part, shall we? We (aka. Developer Daniel) ended up building a custom course plugin.

There are a ton of powerful, feature-rich course plugins on the market. We even evaluated LearnDash and WP Courseware from top-to-bottom.

After many team discussions, we eventually decided to build our own course solution because:

1. While courses are important to Food Blogger Pro, they’re a fairly simple part of the site

After writing our requirements document for our courses, we realized that our course functionality needs were fairly simple. Courses on FBP are nested (Lesson > Course > Series), and each Lesson has a Vimeo video embed, a written transcript, and a resource box. That’s it!

2. Integrating two plugins is easier than integrating three

Every time we talked about the possibility of implementing a course plugin, Daniel would compare it to having another kid. Life gets much busier and messier when you have a second kid, and then it gets even more busy and messy when you have a third. 

We knew adding a third critical plugin with more bloat than we needed to our tech stack could introduce unnecessary issues and problems that could be avoided by building our own solution.

3. We could take out a lot of the bulk from the course plugins we tested by building our own

We knew we didn’t need quizzes, certificates, prerequisites, timers, or a lot of the extra fluff that came along with the course plugins we evaluated thanks to our requirements! 

4. We could easily build what we liked from the course plugins we tested

Even though there were some unnecessary features in the course plugins we tested, we did find some functionalities that we liked and wanted to incorporate into our new site.

That said, these features weren’t “launch blockers,” so we decided that we could fairly easily build these elements after we had a stable WordPress site.

Documenting Decision Rationale

One of my biggest takeaways from this migration project: the importance of documenting our decisions and why we were making those decisions. 

As with any big project, there are a lot of decisions to be made, and we’ve already talked about a bunch of them in this article! But there’s going to be a time in the future when you look back at some of these decisions and say, “…and why did we decide to do it this way again?”

That’s why it’s critical to actually document your decisions. Whether it’s taking notes during a call or having a Decision Rationale folder on Google Drive or Dropbox so your team can access them, it’s important to document your reasoning. 

Creating Development Tasks and Tickets

So how do you know when your Development phase is done? For us, it was when:

• The majority of decisions have been made
• The majority of Asana development tasks have been created

An important thing to note here is that not all of your decisions and tasks will be made and created. As the Development and QA processes start, you’ll find there will most likely be some outstanding needs, pages, and choices that need to be made after you’ve “completed” your Development process.

And for a big membership site, that’s to be expected. There were hidden thanks pages, coupon nuances, and membership decisions that needed addressed after we started to build our new site.

But the point of the Discovery process is that you’re performing due diligence and outlining as much of the work that needs to be done as possible. Everything from requirements gathering to evaluating software helped us make these Development tasks, and they guided our schedule and workload for the rest of the project.

And that’s an inside look into our Discovery process for our WordPress migration project!

We’re curious: what was your biggest takeaway from our Discovery process? Was there anything that surprised you or that you’d do differently? Let us know in the comments!