Whether you read our post on the four signs that it’s time to move support platforms or you’ve been considering a move for some time, you probably already know that platform migrations can be difficult. But with the right preparation, you can minimize the stress.
I recently talked with two support leaders who have migrated from one customer support platform to another:
Denise moved to a new support platform for two different products (SmugMug and Flickr) with 69 users in total. Laura moved to a platform with 125 full-time agents, 300+ light agents, and years’ of historical records. So, not small moves in either case.
I asked them about their platform decisions, how the migration went, and what lessons they learned during the process.
By now, you know I’m a big fan of planning, so this first piece of advice from the two support leaders obviously resonated with me. The common thread in their searches for a new platform and their subsequent migrations is that good planning is what made things work. They suggest that you start by figuring out what you truly need and want and then search for platforms that can meet those requirements.
Laura said this about starting her search: “I did a basic matrix and ranked about five platforms I’ve used in the past with the needs we have.” For the actual migration, she said, “We had a consultant help us find a vendor to use to map out what tickets should be migrated and where. There were weekly meetings to discuss status and challenges.“
Denise also had a well-planned process. In her case, quite a few Hero team members (their support title) contributed to the list of features needed. From there, she “grouped all the features that had been added and got the team to prioritize the features. That is how we came up with our final wishlist for the top features we wanted to see on our platform. With that final list, I went shopping.”
Taking the time to plan is essential. You can’t “wing it” when you’re making a big move like this.
It’s important to consider everyone who will be affected by the move to a new platform — especially those who use it for their day-to-day work — and to give them an opportunity to offer their thoughts.
To keep things simple, Laura included just a handful of people in the decision process, comprising herself, the Director of Customer Experience, Director of Core Business Operations, and Director of Product Operations. Keeping the decision team small makes a lot of sense for smaller teams and when the directors work closely with support. In cases like this, the directors likely have a good understanding of the day-to-day requirements of the agents, and can make sure their needs are considered.
Denise, on the other hand, had a considerably larger search team. “The demos and reviews included all the support team managers for both SmugMug and Flickr, and three or four support team members from each team. We had a total of 18 people on the search team.” In contrast, the decision team only had the Directors of Support for SmugMug and Flickr, and Denise on it.
While it felt like they had too many people involved, Denise isn’t sure if she should have had a smaller team either. “There were multiple interests involved and they all needed to be represented.”
By limiting the number of final decision-makers to three people, Denise found a way to give everyone a voice but without making it a huge group decision. She did say that next time she’d narrow down the list of platforms herself, rather than have the whole search team look at a long list of potential software. That would have saved time – remember that 18 people on a one-hour demo is 18 hours of work time lost.
Laura suggested that if you have a large group helping with the search, you make sure their roles are clearly defined. Are they there to represent a regular support rep, a lead, or an operations person? That way, even if someone is familiar with multiple roles, they’re the voice of a specific position.
Laura suggests designating specific tasks to specific people and holding them accountable. If a large team wants to be involved, make sure they are put in charge of a specific point of view.
While it’s good to include as many people as possible, don’t slip into making decisions by committee.
When you’re managing a team, it’s easy to become so focused on what they need that you forget to step back and look at the bigger picture. Remember that improving the customer service experience and helping your customers is your primary goal.
One valuable thing Laura did was talk with customers. She held interviews with current clients to understand the shortcomings of their platform. It helped her learn what improvements the clients expected to see if they were to move to a new one.
This was especially important since her company has a customer portal that customers use to connect with her teams. These customer perspectives helped guide her team’s search and affected how they migrated to a new platform. Laura recommends to anyone approaching a migration is to take your customer feedback as seriously as that of your internal support team.
In the past, I’ve made the mistake of focusing more on my team’s needs than our customers’. While we ended up with a platform we all loved, customers found the move jarring — and it showed in our CSAT and NPS scores. So, I agree with Laura. Never forget that your end goal is to offer a great experience for your customers.
The right vendor can help ease the process of migrating data to your new platform. I’d suggest reaching out to people in your network to learn from their experiences with any vendors you’re considering.
Laura and Denise worked with third party vendors to move their historical data to the new platform. Unfortunately, they both ran into issues. While plenty of migrations go well every day and these are outliers, Laura’s and Denise’s experiences do offer some insights into how to save yourself some pain.
Denise hit a speedbump toward the end of the process when she realized her team and the vendor had different definitions of what data was supposed to be moved. This caused a significant delay when everyone had to step back to the review process to ensure they had the right data. And the migration plan had to be shifted.
Laura’s vendor mapped the data to be moved first, ensuring they had an accurate list upfront. However, when it came time to migrate the data, the vendor ran into an error and then disappeared from the scene!
Fortunately, because Laura’s team had done an excellent job of planning, their migration was able to continue on schedule. The Director of Product Ops worked with the person who manages their current Jira and Jira service desk implementation to outline the following:
That preparation meant they could pivot to using their own team to migrate the data. “Our JIRA expert on staff worked night and day to write the proper script to move the tickets [into the new platform] via API. It took about a week but she was able to pull it off!“
While using a vendor can give you confidence, especially for very large migrations, being able to perform the work with your internal team can give you more control.
While Laura managed to keep her migration on schedule thanks to a lot of prep work, Denise’s schedule slipped. Her vendor made it clear they couldn’t meet the previously agreed timeline and she had to negotiate a short extension with the former support platform so they could continue to support their customers while they got their migration back on track.
When you’re deciding on a schedule for the migration, in large part, the amount of time it takes will come down to how much data you have and how much history you’re migrating to the new platform.
Laura’s timeline for the full migration was only a few days (with a few weeks of planning before that) while Denise’s ended up taking three months. In my own experience, migrations have ranged from less than a week (leaving most of our history behind and for a team of two) to six months (to move a decade of history for a team of 200). Both took longer than I’d anticipated for a variety of reasons. Whether you miss something during your preparation or someone is out sick, be aware that delays will happen.
I recommend giving yourself some buffer time, especially if you’re ending the service on your original platform right after migrating. Also, ensure you have some overlap between the two platforms in case you discover that information is missing or just run into an interruption.
Migrations always experience unexpected hurdles. But you can do a lot to control them. Good planning is key — the more time you spend upfront, the more you can reduce your actual migration time and minimize the risk of affecting your customer service.
Building in a buffer of extra time is also critical for a stress-free migration. Moving to a new platform is much like a house renovation. You should always expect it to cost more and take longer than you expect, so it’s best to account for this in your planning.
Thanks again to Laura and Denise for talking with us! I hope you’ve learned something from their advice.
As always, if there are specific topics you want to learn more about, comment on LinkedIn. We’d love to hear from you!
Start testing and comparing how software could help your team in seconds.
Oh and did we mention it’s free? Because it is.
