Advice for Streamlining Your Community Migration

Featuring Expertise from a Panel of Community Managers

Last week, 7Summits hosted a webinar detailing best practices for ensuring a successful community migration from your legacy platform to Salesforce. It featured insights and advice from a panel of expert community managers, who shared some of their experiences overseeing dozens of successful migrations.

While we recommend you check out the webinar in its entirety, audience members raised some questions about migrations that were not able to be addressed in the live presentation. The questions below contain our panelists’ responses to questions that came up in the webinar, as well as a handful of those they did not have time to address. The end of the post also contains responses that our Director of Community Enablement Shannon Gburzynski shared as a part of a migration panel at TheCR Connect.

Questions Addressed in the Webinar

Can you describe what a typical migration looks like from a project standpoint?

James Davidson: Typically, in terms of weeks, we first look at a define phase, which can be about 4-6 weeks of discovery depending on the size and complexity of the community. It focuses on understanding requirements, mapping the legacy environment to Salesforce, going through UX design and structure and developing a change management plan. Then, depending on scope again, we typically look at three build sprints of about three weeks apiece to kind of migrate you from a legacy environment to Salesforce. There’s obviously a methodical step in how we migrate data, and we first have to move users and content. 

Shannon Gburzynski: To add onto that, I think in terms of migrating the actual content, we want to give you the opportunity to take a look at what you’re migrating over. We do many dry runs of small pieces of content so you can get into the environment quickly, and then prepare the tooling and make sure everyone is comfortable with the new experience.

JD: And I think the last step is probably the QA and deployment. Depending on how broad your user acceptance testing is and your deployment window, typically this stage is quick; typically between three to six weeks here. I think between 14-20 weeks is probably a good range to think about for the core project. But obviously that doesn’t take into account things like selling people on the migration ahead of time, as well as all kinds of post-launch support. 

Andrew Mishalove: In order to do it well, you have to follow up on your seven best practices and Heather’s guidelines on the “before, during and after.” I think we [Dell Boomi] gave ourselves that time, with our experience and working with the right teams at 7Summits and Salesforce, and having those support systems in place. The last thing you want to do is have a dud experience for your end users and then have to rebuild their confidence and redo it. So take the steps to do it right, and do it right the first time. 

What considerations should be made about migrating the existing community as is? Did any of you take this as an opportunity to do a redesign or introduce new capabilities as a part of the migration?

AM: We looked at this as an opportunity to re-evaluate our community, which was a standalone solution that wasn’t at the forefront of our business or a core tool to help us meet business and customer objectives. With the opportunity to migrate onto Salesforce, we had the chance to get a 360 degree view of the customer and have a single data set where we could look at data and benchmarks and get a sense through Salesforce’s other tools where our customers were engaging with us and what was important to them. The platform available within Salesforce had a lot more features that better aligned with our business objectives, from case deflection to case management to knowledge content. It had all the great features that we loved about Jive in terms of engagement, blogging and documents, but enabled other capabilities as well. The user experience and user interface was really critical, and we took the opportunity to rethink that and get rid of old content that wasn’t being used. We re-thought the structure of the site and did a lot of stakeholder and end user interviews to put together a great experience. The latest iteration of the community that we just went live with really took that to the next level in terms of thinking about what was going to be meaningful to our users.

Heather Ausmus: I agree with Andrew, I think moving into Salesforce let us take the approach of integrating as seamlessly as possible and keeping it simple to start with. We let our users get used to it and learn the new platform, and then used the data we collected from our users to build a plan on how to expand it from there.

How do you handle new capability requests in the planning and execution window?

SG: We try to accommodate that in multiple places during the project. We want to pull a lot of different roles and the right people in the room early on, so the goal would be whenever possible, to have them understand the platform and what’s possible so they can weigh in with new feature requests that can actually be built into the actual plan. If we can get those requests in early before we do any development, great. Once we get into the development of the program, people tend to get a little more excited and a little more interested. They’ve seen design comps and sprint reviews, and inevitably new feature requests are going to come in. We try to run our projects through an agile methodology, so if you need to pull in a net new feature because it’s critical, we can do that. We can play into how it impacts timelines and budgets and other features, and if we want to reprioritize during the middle of the build we can take the opportunity to do so. And then if the priority of that feature doesn’t supersede some of the things that we’re working on, the last opportunity relates back to the fact that “launch is just the beginning.” Being able to have a consistent roadmap of items and new features that are coming out continuously keeps internal and external stakeholders engaged and interested in coming back to the community down the road.

AM: That’s a great point that Shannon makes, the launch is just the beginning. With any product that you roll out, we love to take input from our consumers. We try to align our ideas with our business challenges and how new features and functionality can help us provide solutions to those challenges. We have our own ideation board, which our customers have in the new community. People get the chance to vote and explain ideas and what business challenges they’ll help overcome. Those then get consideration for inclusion in the roadmap for how to enhance the community down the road. In the interim, to Shannon’s point, this is just the beginning, and it allows you to empower your users to continue to provide feedback and input.

Panelist Responses to Unanswered Questions Raised by Webinar Viewers

Have you seen any surprises that come up in previous projects, pleasant or unpleasant, that we can learn from?

I’ve seen a lot of surprises. I think no matter how much you plan, every migration is a little bit different. Even if it’s from platforms you’ve migrated before, they always throw a curveball at you. I think data cleanliness and organization, the merging of that data, and who understands both data models has regularly been a surprise. It’s a challenge to find folks who understand all of those pieces. Versioning can also be a really fun one. If you’re in the middle of a project, you might have a timeline based on when a contract is ending. So having to align that with new versions of platforms being sent out can be really complicated and is always a fun challenge to overcome. I’d say another would be just making sure the customers have a great relationship with the vendor. We’ve gotten pretty far in the project when people say things like, “Wait we didn’t buy enough licenses, nobody told me we needed more.“ While they were surprises at the time, these things helped us in the long run. We’ve got a really long list of the challenges that have come up, and a migration bootcamp that we put our internal resources through so they don’t make those mistakes twice.

How much do you think bringing end users into a project makes a difference in a successful migration? Have you seen that be a key differentiator between something going well and going badly?

I think it can certainly have an impact. I like calling it a “safety net” when you bring them in, but  it needs to be done in a controlled manner. We found that if you throw a half baked solution or idea in front of those users, you’re going to panic them. So it needs to be a fairly complete thought or solution that has gone through multiple rounds of revisions in your business, and you need to understand those stakeholders so you can tell a cohesive story about why you made those decisions. And then they can help be that safety net to catch those last couple things that we didn’t think about that they know from using the day-to-day functionality. I think it’s critical but it has to be done in a thoughtful manner otherwise it can be really disruptive.

What’s the most important piece of advice you’d give to someone about to embark on a migration project, and why is it the most important?

I’d say check and double check. The process is going to be challenging and difficult, but the good news is that we have options to go back, fix things, and update things later if mistakes are made. Another big one is don’t make any assumptions about how you think something is going to function, or that everything is going to come over wonderfully because you checked five discussions out of the 100,000 that we’re moving. Every single one has a lot of nuances to it, so make sure you really pay attention to the details, confirm the mapping is what you expected, and do some really good testing early. That will save you a lot of trouble later on. 

Other Migration Questions Answered by Shannon Gburzynski at TheCR Connect

For people thinking about doing a migration, what are the first things they should think about?

I think there are a couple things that are critical to think about. The first is to really make sure you’ve truly aligned on all of your business objectives. It’s really important to understand the value of community to your organization, which will help you with the processes and steps that come later. The second thing is picking the right platform, which means not just thinking about feature sets, but also factoring in support models and extensibility. We want to make sure we’re picking a platform that doesn’t just have the most checkboxes next to a list of features; we want to be picking features that are relevant to us based on the important objectives for your organization. You also need to make sure there’s a good support model in place. Can you type in a question on Google and get an answer, or do you always have to go to that company and wait for someone to get back to you? Do you have to go to a vendor to get support to build on top of the platform, or do you already have resources in house who understand that technology? Finally, I think the last piece would be coming up with an effective roadmap. You want to make sure that whatever platform you’re choosing is going to be around in the long term, because you don’t want to go through the whole process again. You should make sure they have a well thought out and well-funded roadmap, and have methods for you to extend into other systems. So picking a platform that allows you to integrate easily into other systems will ensure long term success. When you align on objectives and figure out the right platform for you, you’ll be off to the races.

When you put a team together, what kind of skills and roles are necessary for a customer’s migration team? 

In terms of skills and roles, I would bucket them in two places. The first is a really strong product owner, and the second is a group of experts who can support them. For product owners, you need somebody who can be a definitive voice in the room and make some hard decisions, but who can also think strategically above and beyond what some of the other folks are considering day-to-day. I think as we’ve gone through migration projects, one of the biggest challenges we see is that the folks involved in the day-to-day aspects of the community want to pick up everything and simply put the exact same thing that they already have it in the new environment. If you go that route, you’re going to be very frustrated and you’re probably going to do a lot of customizations or have a lackluster UX. The product owner needs to think strategically not about what you had before, but what you are going to have in the future and how you can proactively move all of the great content and features you had on the legacy platform onto the new one. That being said, you don’t want them making decisions in a vacuum. We want those decisions to be really informed. You definitely want somebody like a content expert who understands the taxonomy and hierarchy of the information in your existing community. They can really think about how the content is going to show up in your new environment. Because those organization features are going to be different from one platform to the next, you need them to weigh in. You also want to hear from the people that are managing the community on a day-to-day basis and have direct interactions with your users. We want to know everything we can from them about what’s working and what’s not so we can support your end users’ needs. Lastly we need to have IT in the room. We absolutely want to make sure we’re on the right track when it comes to the long-term road map for not just the communities, but for the tech staff as an organization in its entirety. We’ll need their help at some point, so getting their buy in early helps make everyone successful later. 

Regardless of size and timeline, what are the typical phases you go through in projects?

7Summits’ typical approach has seven steps, but for brevity I’ll shrink it down. We start with an assessment and planning phase, which is where we do a ton of analysis of the current platform. The most critical piece is really figuring out how we’re going to map features and functions. If we have a blog in the legacy platform, what will it look like in the new one? It’s not always 1-to-1 mapping; we might be moving discussions from one space into blog posts in the new community. We can sort of mix that up, and it really depends on the purpose of the content and why we’re moving it. We’ll figure that out, in addition to technical and visual design, in the first phase. Then our second phase is development and build. Here, we’re building the container of the community so we can start migrating the content. We like to do a lot of mini/micro migrations to ensure things go smoothly. We might pull in five discussions at a time, and then hand that off to business stakeholders to make sure they’re doing research and analysis. This lets us confirm that everything’s coming over as expected and that they’re comfortable with any potential trade-offs in features. Then we move into launch and support. On the launch side, we’ll probably turn your old legacy platform into “read only” mode, move your stuff over onto the new platform, and then do some checking to make sure everything is working as expected before we go and shut down the old one. On the support side, because you’re choosing a new platform, we usually have folks available for a couple weeks after that just to help you figure out the nuances of the new platform that you didn’t think about in the planning phase. We also do a bunch of analysis and research on the migration itself. We’ll pull reports to see if we missed anything, and if so, why? Then we figure out those solutions as necessary.

What should people be thinking about specifically when it comes to change management? How do you communicate that to your end users and to your internal teams as well?

I think one of the things that we’ve seen become one of the biggest challenges on the change management side is assumptions. Really understanding the features on the new platform is going to be super critical to enabling a great change management plan. Most community platforms have similar features: I can post a discussion, I can create a doc, I can post a blog. A lot of times folks are coming from one platform to another, and they make a lot of assumptions about how things work. They’re used to a discussion thread working one way in a legacy platform, so they just assume it’s going to work the same in the new one. If we don’t get in there and make sure folks are doing testing and analysis and seeing live demos of the system early, we get to the end of the process and they’re surprised because they made wrong assumptions about how things work. On the change management side, you need to make sure everyone who’s in charge of the project truly understands the shift in features from one platform to the next. The second piece is we always make sure we incorporate feedback from end users as often as possible. We go through the full define and design phase in the beginning and do a ton of visual comps and wireframing. We take the opportunity to not only talk to the project team but also to end users when it’s appropriate. This lets us get some live feedback before we do even a single line of development or configuration so we can make changes really early. This is also a great opportunity to do things like invite old users back, create a marketing campaign with all new features and details, make sure you’ve got FAQs, and use other guides to ensure your success.

See other community insights from Shannon Gburzynski!

Read More!