Migrating your legacy community to a new platform can be a stressful process with a lot of moving parts. But a proper migration leads to major benefits, such as cost savings, enhancing UX and eliminating silos, that make the transition well worth it.
7Summits Director of Community Enablement Shannon Gburzynski has been in the community space for more than 10 years, managing and overseeing most of the company’s migration projects. Speaking as a part of a panel at TheCR Connect in Boston, Shannon shared her advice for making community migrations as seamless as possible and ensuring long-term success after switching platforms.
Read below to see the insights she shared at the panel about community migration, and how companies can maximize business value and ensure long-term, post-migration success.
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.
What does a typical project look like? When you’re trying to scope a project for a customer, what are the factors that you take into account when you’re doing the planning? How do you find out about those?
When we’re scoping a migration we use a questionnaire, and hone in on a couple of topics to see what’s going to impact a particular migration. The first is timeline. If you call me up and say the contract for my legacy platform ends in 30 days, that project is going to be really different than if you call and tell me your contract ends in a year. The process and how much we can do is really going to depend on how much time we have to do it, so that’s what we ask first. The second is data cleanliness. If we have to do a lot of work to clean up the data before we move it, that’s going to take a lot of thought and manpower to make that data as clean as possible. And the last piece is data integration. We do most of our migration onto the Salesforce platform, which means that folks are frequently moving from a legacy community platform that was on its own into a system of record with their service and sales data. We don’t just want to duplicate the users that were in the community and were already listed in their Salesforce CRM. Instead, we want to make sure we’re tying those records together. That process can sometimes be easy, but it can also be really complicated. In terms of scoping a project, those are the three we hone in on immediately to determine how complex or simple a migration will be.
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.
Do you find that most customers are trying to migrate a community as is and make the process as seamless as possible, or do a lot take the opportunity to do a complete redesign? Which of those projects do you prefer and why?
From our perspective, I’d always recommend a bit of a refresh. We’re going through a large, complicated project and tackling something really difficult. I think it’s a perfect opportunity to spend a bit of time thinking about whether you would have made any decisions differently if you started the process from the beginning. If you’re going to already move everything over, let’s move it over the right way and into the hierarchy and structure that you want it to be going forward. That’s not to say we have to completely change everything about your environment, but we definitely encourage folks to think about how we’re going to update things. I think a good example is we frequently take the chance to combine multiple platforms into one. Companies may have a portal for cases, a public knowledge base, and also a community platform, and want to put all of those into a central experience. That’s a great opportunity that allows us to create a nice cohesive experience for our users. We’re going to have to do a refresh to accommodate all of those use cases and audiences into a new community experience that makes sense for your users. So I’d definitely recommend a refresh when you have the chance.
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.
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.
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.
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.
All posts in Advice & Thought Leadership