The Real Key to a Successful Data Migration Strategy

When it comes to data migration, we have all put our blood, sweat, and tears into these efforts. Despite our best efforts, we’ve also seen them flounder, lag, or even fail. What we at MentorMate have learned is that the users do the implementation. Not us. And a data migration strategy that keeps the users top of mind has a much higher success rate than one that doesn’t.

The primary driver for why we say that is that no implementation is complete or successful until the users use it. They make a choice and have a lot of power that an executive decree deadline can’t overcome. Have you ever heard “the current solution is business-critical. We can’t put that at any risk right now?”  We all have — revenue and profit beat change. If you’ve ever brute-forced your way through that, you have the scars and gray hair to prove it. We do too. 

At the same time, we all have this innate desire to improve everything, everywhere, all the time. It is what drives success within strong technology teams. We can leverage that desire in additional ways that pull our users through it rather than push them. There are creative approaches that can get the desired adoption, which is the blog’s focus.

Data Migration Strategy: Start with accountability

As usual, nothing brings accountability like a thoughtful set of metrics that provide visibility, so what’s important enough to measure? Is it adoption by our user base, speed to decommission other systems, business opportunities realized, costs saved by insights?  Incorporate measures of business value too. Importantly, make sure the metrics don’t cause unintended behavior. We’ve all seen sprint teams’ points inflate due to a metric that just counts points.

Yeah, but what does that actually mean?

For this exercise, let’s assume you’ve chosen the platform and are nearing rollout.

The strategies here directly address rollout challenges. They capitalize on getting the most out of the systems you build. Many of these techniques greatly benefit from a fresh perspective. Namely, consider a new platform as a new product trying to break its way into a market. We think differently if we view our user base as potential customers, not assuming they will buy. The ideas, methods, and lifecycle evolve.

So this is a new product?

Yep. At its core, you’re introducing a new product (e.g., NewData) to a market that has not seen or used it before. The go-to-market strategy for a new product or service provides excellent context for achieving the improvement itch we so desperately want to scratch. Look at it from a user’s perspective. 

“This new product looks super cool. It solves many problems I’ve been complaining about forever [excitement]. But now I need to convert the massive amount of queries and reports I’ve been making for years [fear]. I don’t think I can meet the arbitrary deadline [uncertainty].”

Given that you’ve been living and breathing the new platform for months, it’s easy to lose sight of this user perspective. With empathy and recognition of what users are going through, the adoption trajectory becomes an exciting challenge to adapt and innovate. 

Here is where the product management playbook gives us a pattern. Start by looking at your users’ motivations, and needs (both visible and latent). You need to be able to answer the “What’s in it for me?” question. Importantly, look at what new problems the migration might create and existing challenges that will persist. 

Are the customers dying to get better performance, more data, and new tools? Absolutely. It’s very easy to sell that story. Are they excited about having to learn a new system, convert their queries/reports, and cross-check the results? Absolutely not. 

So let’s attack that unintended consequence.

What if you could pull the users through rather than force them into it? What if you play an active role by figuratively walking a mile in their shoes? Start by considering users as potential customers to whom you must sell the NewData product. What questions will they have? What would lower their level of concern or turn them into a lifelong customer?

That perspective leads to a customer-focused approach. Here are some data migration strategies we’ve used to cut the ball and chain of a legacy platform and make friends along the way.

Data Migration Strategy: Build a Fan Base

Rather than just converting large swaths of people/departments, start by finding the hotshots. Often these are the highest utilizers. The experts that everyone knows to go to for answers. These people are the initial targets. Goal? Create the fanboys. 

Gurus like being gurus. It’s empowering; they have respect and get to help others. So make them gurus on the new platform with the same status and accolades. They become cheerleaders trusted by the customer base.

We know that involving people early is critical to nearly any technology project. It is doubly true with this particular breed of customer, and the time for requirements has passed. Here are a few patterns that get better adoption from the gurus, leading to critical mass.

• Negotiate dedicated time from their management. Pay for it if you need to. Just make sure you get it. This rollout is not a “side of the desk” task.
• Dedicate your own people to pair with the gurus. Make their migration successful at any cost. Be hands-on. Days or weeks at a time.
• Use their wildest queries/reports to test out the new platform. The goal is to have the guru tell their colleagues this: “Look, if it can handle MY crazy query, it can certainly do yours. Let me show you.”
• Get their input on tools that would help others and maybe expose some of the secrets used behind the scenes. What will their acolytes need? For example, a tool that compares old results to new results of queries and isolates discrepancies.
• Importantly: Explicitly give them a job. “I need you to help drum up support and reduce concern. We will work with you on that.”

Data Migration Strategy: Crossing the Chasm

OK, the gurus are onboard and shouting praise from the mountain tops. Why are you not seeing an immediate acceleration?

Geoffrey Moore wrote a fantastic book about business and products called Crossing the Chasm. He asserts that every new product, service, etc. goes through a natural plateau after the early adopter spike has leveled off. The reason is that more prominent and risk-averse customer groups want to see a “real” group succeed, not just a hotshot with the latest iPhone. They can’t count on having a team of superheroes.

BTW, this plateau will tempt you to just set a deadline and force people to move. Be patient, build a bridge across that chasm, and help them cross it.

• Pick a small set of these later adopters. Give them white-glove service.
• Embed one of your own teams within the business area. Sit side by side and do the work together. The business team gets an assist, and you learn where theory and practice collide. Side benefit: your team learns a lot more about the business for the next project and builds tighter relationships.
• Minimize the work to migrate. 
  • Re-create some of the most used views to mimic the old system. This tactic reduces the customer conversion effort so you can decommission OldData on time. 
  • Include tools to compare the old data to the new data will help query/report creators save a lot of time. Add “known differences.” These will include errors in the old data. See? The NewData is better!
• Conversion Sessions. Have customers bring some real data needs. Convert them in front of a live studio audience. People can see how easy it is and how much better the performance and functionality are.
• Sponsor lunches, office hours, and other Q&A options. Even a “stump the expert” challenge where you could win a $50 gift card can bring some fun and invite conversation. Be creative.
• Create a SWAT team that can parachute in and gets off-track areas in the business teams back on track.
• Turn this group into a success story and share it with the other user bases.
• Lather, rinse, and repeat.

Implementing a data migration strategy sounds like a lot of extra work. Or is it?

We all know the side effects of a system that won’t go away: huge costs, people don’t want to work on old tech, and all the tuning tricks have been done. It is what it is. Not to mention security risks as it ages out of support.

The upfront costs of the product approach are well worth absorbing. Too many legacy databases persist because teams can’t move off of them. They are just too business-critical, and the customers can’t make the move. When these zombie data platforms that just won’t die go on, costing tens or even hundreds of millions, the ROI in the business case evaporates quickly. 

Of course, there are always a few stragglers regarding adoption. That’s where you’ll still need that executive decree, adoption deadline, and some brute force. However, the steps above should significantly reduce the number of stragglers — and scars and gray hairs you incur.