two-men-moving-boxes-from-van

Data Talks Episode 20: Navigating Data Technology Migrations

With Preparation and Communication, Migrations Needn’t Be Scary

Host: George L'Heureux, Principal Consultant, Data Strategy
Guest: Sita Nathan, Senior Solution Design Consultant

Whether switching vendors or upgrading with an existing vendor, data technology migrations pose a risk to even the most seasoned organizations. There are changes to data, changes to processes, and even changes to the user experience that need to be considered. Failing to properly think through the transition for any of these can be problematic.

In this episode of Data Talks, Sita Nathan, a Dun & Bradstreet Senior Solution Design Consultant, gets in-depth with recommendations on how to approach a migration, who to involve, how much planning time is required – even how long to run systems in parallel. Having a plan before embarking on a migration can help avoid the pitfalls and make the experience easier on everyone involved.

 

 

Read full transcript

George L’Heureux:
Hello, everyone. This is Data Talks, presented by Dun & Bradstreet. I'm your host George L'Heureux. I'm a Principal Consultant for Data Strategy here in the Advisory Services team at Dun & Bradstreet. In Advisory Services, our team is dedicated to helping our clients to maximize the value of their relationship with Dun & Bradstreet through expert advice and consultation. On Data Talks, I chat every episode with one of the expert advisors at Dun & Bradstreet about a topic that can help consumers of our data and services to get more value. Today's guest expert is Sita Nathan, a Senior Solution Design Consultant at Dun & Bradstreet. Now Sita, how long have you been with the company?

Sita Nathan:
Approximately 14 years.

George L’Heureux:
Could you tell me a little bit about what it is that you do in your current role as a Solution Design Consultant?

Sita Nathan:
Sure. A solution design consultant supports both the pre- and the post-sales engagements. We are close partnership with both our sales teams as well as our clients, where we provide them with best practices, leveraging a consultative approach in order to address their needs or their requirements that they have. Our focus primarily being on defining the solutions that optimally solve client problems as well as being able to enhance the sales process using a consultative technical expertise on the D&B integrative products and offerings.

George L’Heureux:
Thanks so much for that explanation, Sita. Today's topic is really an important one for us and it's one that just about every organization is going to face at some point or another, and that is a technology migration. And so let's start really with the basics. Why are these such a big deal? What types of challenges are our customers going to face when they go to do a migration?

Sita Nathan:
When everybody talks about migration, everyone gets a lot nervous about it because everyone has a different view of or a perspective about migrations, right? Today, there are three critical perspectives that one needs to think about: Data, technology and the user, because users are the people who get primarily impacted when we do these migrations. When we talk about the user, there are multiple things that one needs to be thoughtful about and to understand what are some of the things that changes that would impact their day to day life. This becomes a really critical, important play, which we really do not take into consideration and we need to bring it very upfront in the process as we go through this.

George L’Heureux:
Let's make sure that we do that. Let's take a little bit of a deep dive in each of those perspectives, the data, the technology, and as you point out the user. For each of them, what are some of the things that we need to be considering?

Sita Nathan:
Yeah. So let's start with, I like to call them the three legs of the stool, right? The data part. To understand the data that is being impacted by or will be impacted for the client, this is a real critical partnership that has to happen between the client as well as the provider in order for us to be able to get together and assess the needs of them. Understanding what are they getting today and what they will be getting tomorrow. What are the differences in the data? What are some of the rules they have to build in as they go through the process? A technology perspective. A technology is usually many clients are now migrating from an older technology to more of the modern technology, which is like a REST-based API.

With this shift in technology, there are critical aspects that one needs to think about like the resources and how to implement this because the older technologies have different type of resource type of criterias required versus the newer technologies. The user interface, this is where one needs to think about how this new user interface. Do you want to keep the same interface or do you want to change it? There will be naming convention differences because of the way the industry has moved so we need to say many clients want to move towards the best practices in there.

How the placement of these output data is going to be? What are some of the changes, because there may be updates to the models that may have happened? That could cause changes within what the data the user is going to see. We need to bring them early into this journey and help these users to be able to understand not just the data, but also the technology that we are moving towards. These three really play a big deal as we move towards migration.

George L’Heureux:
So something that you just mentioned about bringing the users on the journey earlier. When you're thinking about so many different aspects, these three legs of the stool like you're talking about, when is the right time to start having these sorts of discussions?

Sita Nathan:
This is a very... This topic becomes very controversial and it also depends. If this is being driven by the provider due to a platform change, then you might need as much of a advanced notice like a year, okay? Because everybody needs to plan it out, make sure that they are part of this, the changes are part of a major release because this will require budgeting, resource planning and all the different criterias that go with any technology improvements that happen. We need to work with the partner as well as the vendor to ensure that everybody understands these changes and give enough notification for them.

If it's a customer is making the change, then they may be lesser time because some of these things may already have been taken into consideration, right? Like they would've already got the resources, the funding. They would have a high level architecture plan. They would know where this is going to fit within their release schedule. It could vary anywhere between eight to 12 weeks or even longer, but it all is driven by a combination of the client as well as the partner and who is driving this migration.

George L’Heureux:
That seems like a big difference, right? The difference between say maybe a quarter's worth of time and a year's worth of time. It makes me believe that maybe the actual migration to the new technology really isn't the biggest part of the equation, isn't the biggest driver. Would you say that that's correct?

Sita Nathan:
Yes. I would say yes. Integrating an API, for example, is not the real issue, right? The bigger part of this is understanding the content, and that is very critical. Understanding what the new rules are, getting enough context and understanding to ensure that the data that is being delivered into this new system becomes actionable and becomes something that the user can be able to understand and drive towards their end goal that they're trying to achieve. That is the critical piece of it.

George L’Heureux:
It seems like all of this planning is really designed to try and avoid getting tripped up, stumbling over some unexpected difference that exist between the old system and the new one that didn't get detected earlier. What types of changes might these be? What might a user see that's different and that you need to be on the lookout for?

Sita Nathan:
There could be some that is as small as a difference in saying an indicator, right? Today, we may be giving a flag that says yes or no. Tomorrow, that same flag would've been changed to true or false. We assume that this is a very minor change. It could be, but you have to think about not just the system that you're migrating, but also the downstream system, because it could have a big impact in there. Another one is also talking about the sales data, because this I've seen a lot, right? Many clients, you need to firstly understand the use case and say, "What is that sales data? Is it actual that they're getting today or is it something... What is the use case? What is the purpose?" If it's a marketing use case, they could have been getting estimated or modeled, right?

Because the sources that we have been pulling from a migration perspective may have changed. Understanding those kinds of subtlety is very important. And the third one that I'm seeing also is the small business indicator. What use case is this for? How are the clients leveraging this? Is this for a supplier use case where you need the data from a supplier database, right? Because that way, it's a certified small business indicator versus a small business indicator, which is used from a marketing perspective. All these may seem like small changes, but it's really not. It causes a lot of churn in the system so you need to be aware of it, make the user aware of this and sometimes this is more painstaking if you don't do some of the due diligence processes.

George L’Heureux:
Sita, can you share with me some of the best practices that you've observed or even used yourself when performing a technology migration or some sort of integration project? What are those?

Sita Nathan:
A technology migration in general is driven by the technology teams, okay? While an integration migration can start from a business and bring the technology teams along the ride, right? They’re definitely separate migration efforts from a testing efforts. The first thing is always include business users in testing. That's why the beta testing that we call once it's developed is very important. Make sure that you gather all the documentation, whether it's an API documentation or how you can create a user documentation.

The next thing is all the three teams have to work together in partnership. The technology, the business and the users. Each one will have a different role to play and will be brought in different points of the project. But it is very important that you listen to all three of them and make sure that you define what that documentation is required and provide them as early as possible. The clients also will have this as something to be left behind after the migration is done, right?

Finally, the last one is having a project plan. This project plan should be twofold. One is a high level summary plan and the second one is a detailed plan to ensure that we are capturing all the critical components that need to make this into a successful migration.

George L’Heureux:
Digging a little bit deeper, are there any big differences between migrating from one vendor to another versus say migrating from one platform to another within the same vendor? Do you approach those differently?

Sita Nathan:
Absolutely. When you migrate from one vendor to another vendor, there's a lot of differences. One could be from a technology perspective of the migration, of how that is. What tech stacks each of the vendors have. The second one is the data differences. The third one is how, especially from a D&B perspective, how we do entity identification. Our entity identification has a method of how we do that, right? Whereas, other vendors have a different methodology. Having all these different types of components, you will see there is a variation and it definitely causes a lot of discussion that we need to work through during this process.

George L’Heureux:
Any migration is going to be a collaborative effort as you've already alluded to. But in the end, who's ultimately responsible when you've got a client and vendor and even maybe a separate technology team all working together like this?

Sita Nathan:
At the end of the day, the client is the point of contact. They are responsible. But the vendor needs to be very consultative and make sure the client understands and provides the client with enough documentation so that they can be able to drive that migration, okay? The vendor as such needs to say what are the constraints and what are the assumptions that we are working on from the vendor's perspective. The client also needs to be very articulate to say, "What is this migration use case about and what are the goals and objectives they're trying to achieve?" Having this three-way partnership between the business, the vendor and the technology team is very critical in the component because sometimes the technology team is in-house. Sometimes it's a third party vendor. But all three of them working together is the critical part when you're doing a migration.

George L’Heureux:
Finally, I think one thing that we've all seen and done and that we know is pretty good practice is to run things in parallel. Run your old technology stack and your new technology stack in parallel for a while. But how long should we be doing that? What do you recommend?

Sita Nathan:
This will vary anywhere from six to 12 months, right? It all depends on the project and the resources a client have. If it's a smaller project, I would say it could be done within six months. But if it's larger project, which involves just not one component of migration, because they may have opened up the hood, say it's an MDM project, they've opened up the hood, but there is a small piece of migration that's part of it, right? Then it could take a longer time. But in general, I think everybody needs to be aware it's not just the migration piece of it, but the post migration. Once everything is deployed, then run this for the next two, three months so that you are very comfortable in the thought that any issues that come up post migration can be resolved while you're not disrupting the current processes that users are working through.

George L’Heureux:
Sita, as we get set to wrap up here, what's one thing that you would want someone who's watching this or listening to this today to walk away remembering, to have learned?

Sita Nathan:
Yeah, don't be afraid of migrations. It's something that everybody needs to go through this journey in order it to be able to get more information and insight and be able to come up to with the better technologies that are available. Because all these are something that, yes, it is challenging, but at the end of the day, you can overcome it by working together between the client, the vendor and the technology to team working together as a team, we can be able to drive it. Will there be issues? Absolutely. But we can all work together to solve it. See what options are there and then have a successful migration.

George L’Heureux:
Our guest expert today has been Sita Nathan, a Senior Solution Design Consultant at Dun & Bradstreet, and this has been Data Talks. If you've enjoyed today's discussion and we hope you have, please let a friend or a colleague know about it. If you'd like more information about what we discussed on today's episode, please visit www.dnb.com or reach out to your company's Dun & Bradstreet specialist today. I'm George L'Heureux. Thanks for joining us. Until next time.