Migrating your teams to a new tool

In startup land, you’ll find that often the tool of choice is the one that the first person was most familiar with. It makes a lot of sense to go with the familiar. You’re building a business and a product and you can’t stop to learn every new thing. That's why it makes sense to pick a technology that you’re familiar with. And why it makes sense to work with people you’ve worked with before. But over time, if you’re lucky, the team will grow and those tools stop making sense. You’ll need to migrate to a new tool for the team to scale. It sounds easier than it is.

First, make sure you’re doing it for the right reasons. At a new company, I tend to want to replace everything with something better (or at least I think is better) as soon as possible. I have to fight the urge and wait. I want to understand why we chose that tool and whether there is a significant benefit in migrating. It’s not enough for the new tool to be better. It has to be better for everyone and it has to be better right away. Otherwise you should delay the migration.

Start by writing out the goal of the migration and what specific problem this is trying to solve. Convince yourself first that this is the right thing to do. Migrating to a tool that isn’t better is a sure way to lose credibility fast.

Once you’ve convinced yourself, find the power users of this tool and try to convince them. Give them a little demo and see what features they think are the most important. Does the new tool have those features? Are there other features they might find as or more useful? Is the tool faster? More responsive? They are going to ask for things you find trivial or not-important and it’s your job here to not push back but listen. It’s impossible for you to put yourself in their position and understand why something is important for their workflow. It is ok to ask a lot of questions and try to understand. If you get significant push-back then this new tool might not be right for the team. But they also might be scared of change. It’s hard to differentiate sometimes but you’ll need to figure out a way to understand the difference.

If the power users do come around then you move on to any decision makers that need to be involved. At this point, you should be able to state the goals and share that your power users are onboard. You want to come with the outline of a migration plan in place. They are going to have doubts and need to sit with it for a little while. There are lots of other issues they might need to consider that you aren't aware of. In the past I’ve failed at this and was impatient for an answer in the very first meeting with my manager. You want them to sit with this and come around to be an advocate for this change. You don’t want them reluctantly agreeing to keep you happy.

Next comes the roadshow to the team. You want everyone who can to see the tool, try it out and even create an account in advance. You want them to have an opportunity to play with it at their leisure. You’re going to be answering the same question to multiple teams so gather your patience. Be positive and kind. Realize that some folks are going to be nervous about any kind of change. Share how this will make their own workflow easier. You’ll also want to figure out a key talking point for each team around extra features they might benefit from. Suggest material for them to learn more. Keep letting them know that you will be around to answer questions and help. I always stress that this is an experiment and that if enough people don’t like it we can always go back to the old tool. In all likelihood, if you’ve done your due diligence right this won’t happen. But they need to know it’s a real possibility because you’re fallible and could have made a huge mistake.

As you sell, you should be working on the migration plan. I prefer one-day cut-overs but sometimes it’s best to start with a small group and expand outwards. A lot of this depends on what kind of tool. If it’s something that multiple teams work on together like a wiki it might be harder to have two tools at the same time. If it’s more of a siloed tool like a video calling system then it might be ok to have it start small and expand outwards. The migration plan should include the timeline and a plan of what needs to be migrated. It should also include any decisions needed in advance. It should set guidance on how to migrate and who owns each part. I like to keep the "circle of pain" small and within a leadership role. Maybe you only need your team-lead to own the migration for the team. That person will bear the pain of the migration itself so no one else needs to. Since they are part of leadership, they should expect to bear some pain in their role.

Ask the vendor for guidance. They might recommend some blog posts or open-source tools that will help you move data. I’ve even seen some vendors do the migration themselves manually. They will be keen on getting folks onto their platform. Remember, they’re not doing you a favor most of the time. In all likelihood you’re paying for this service. Even if the vendor doesn’t have a tool, you might be able to find advice on the interwebs. You’re not picking a brand new tool (please don't be the first) so expect others to have tried this migration before. Their might be strategies to deal with the same issues you’re expecting to see.

The day comes and you should expect to spend it helping folks resolve their issues. Spend some time with each team that needs it. Expect some hiccups and troubleshooting. It might even be good to let the vendor know you are migrating that day and to be on-call for support. Make sure to keep the old tool around for a while. You don’t want to lose any information. To save money, you can downgrade the account to less users and slowly start to minimize the people who can access the old tool. That will help you know it’s longer being used. If it is being used, you want to know what use-case they still need it for. Let everyone knows the date you’ll sunset the old tool in advance. They need to be comfortable that you’re not going to take it away from them. Sometimes you won’t be able to ever get rid of the old tool because it has too much legacy information that is valuable.

Remember to keep selling the tool after the migration is over. You’ve given the team the right to not like it and move back to the old one. You want to get over the hump and keep the excitement until it becomes natural and habit. That usually happens pretty quickly. Teams tend to adapt to the new in startup land. My last advice is to run a small retro. What did you learn that you hadn’t thought of? Who was most helpful and what did they do to help? Who made this more difficult? Who had good push-back and who was frustrating without good reason? Who was cheerleading the effort, who was nervous and who was indifferent? An what could you have done differently to make this smoother. When this migration succeeds, you'll have built credibility and likely have another migration at some point in the future. Learn the right lessons to make the next one easier. And then share them with me so mine will be easier next time as well!