How to NOT mess up your SaaS Migration

I’ve often said that one of the biggest benefits to being a Product Manager for B2B SaaS products is that your customers generally stay with you for at least 3 years, if not 5 or more. That “stickiness” is inherent for a business tool because large companies don’t want to invest in change management every few months or even every year. Why? Because migrating between systems can be a huge time suck for IT teams and the other individuals who use the tools. It’s rare the the ROI for switching makes sense.

But, when the business case for switching SaaS providers is strong, a migration will happen. It probably won’t be fun for anyone involved. That’s why there are companies who are migration specialists or system implementers who get paid hundreds of thousands of dollars to do the work for enterprises. It’s a tactical job that few people want to do.

I’m currently helping with a migration for a B2B SaaS product that manages closed communities (think internal Facebook sort of thing). There are a few things that have surfaced that I thought were worth sharing with a larger audience.

Like any product / project, stakeholder management is key. It is integral to identify your stakeholders, what their goals are and to prioritize the migration according to delivering maximum value within a short time frame. Additionally, sending our regular status updates about progress will put them at ease that work is being done.
The time-resource-scope triangle applies. You can’t do “all the things” with limited resources on a tight time frame (as is common with migrations because you don’t want to pay for two systems for too long). Prioritization will make or break the success of the migration and delivering the most important functionality on time is often enough to make those stakeholders happy. As long as they know when the “nice to haves” are coming.
Not everything will be migrated. This one can be hard to grasp, but chances are there is a lot of bad data/content in your existing system that you don’t want to clog up your new one with. Think of it like moving apartments, do you really want to bring that piece of art you hate or the shoes you never wear? They’ll only add clutter in your new space, and the same applies to the old stuff you’re thinking of copying out of fear of losing “historical data”.
Something will need to reorganized. Keeping with the apartment move analogy, your new space has a different floorplan that your current one, which means your desk may move from your bedroom to the living room or that plant may end up in the kitchen. Understand the same thing about the new system you’re implementing. The data structure, user interface, and functionality are different (it’s why you are switching) and it’s worth investing some time in thinking about how your data/content should be bucketed in light of the new opportunity to rethink workflows and processes.

What else do you think is important to keep in mind when migrating from one tool to the other? Are any of the things I mentioned above not true when it’s on premise software?